System and method for providing preferred network access for multilink WLAN entities

Abstract

A method for configuring a service in a communication network includes defining a service type by a service provider, and then associating the service type with an Enhanced Distributed Channel Access (EDCA) / Preferred Access parameter set in an Access Point (AP) infrastructure by the service provider of the service type. A WLAN entity is then provisioned with the service type. In some cases, the WLAN entity is a multi-link device (MLD), and the service type is associated with a set of links of the WLAN entity.

Description

Technical Field

[0001] The present invention relates to the field of wireless communication, and more particularly, to methods and systems for facilitating preferential access to wireless network infrastructure for services that support national security and emergency preparedness (NSEP).

Background Art

[0002] Wireless communication is used by almost all mobile computing devices, including cellular phones, tablets, laptop computers, consumer electronics devices, Internet of Things (IoT) devices, and many fixed computing devices, and the IEEE802.11 standard family (also known as WLAN) is commonly used to connect these devices to each other, access the Internet, and communicate otherwise.

[0003] The Extremely High Throughput (EHT) Task Group (TG) "be" of IEEE802.11 has recently initiated standardization activities within the IEEE802.11 WLAN project, and the results of this TG are expected to be included in the upcoming IEEE802.11be standard. One of the new features of IEEE802.11be is the creation of multi-link devices (MLDs). An MLD refers to a wireless local area network (WLAN) entity or device that has multiple wireless links for communicating with other MLD entities. A typical use case for multi-link operation (MLO) is an access point (AP) that connects to a non-AP station (STA), such as a WLAN terminal, computer, or cellular phone, using at least two wireless links, for example, in the 2.4 GHz and 5 GHz WLAN bands, where traffic is coordinated between the links and one security association is maintained across the two links.

[0004] The IEEE 802.11be standard also includes a new feature called NSEP (National Security and Emergency Readiness) Priority Access, sometimes also known as Emergency Readiness Communications Services (EPCS). NSEP Priority Access grants wireless devices preferential channel access to network communication resources compared to other network devices when traffic related to priority services is transmitted or received. Currently, NSEP Priority Access is granted to devices on the network by the network operator via the AP infrastructure for all services tagged as having NSEP Priority Access. A set of Extended Distributed Channel Access (EDCA) parameters is used to configure NSEP Priority Access. Examples of NSEP Priority Service types include emergency voice services, real-time sensor feeds, video camera feeds, and incident response systems. Currently, when priority access is enabled, all of these services are enabled for a device, and all of these priority services are configured using the same parameters.

[0005] This approach has several drawbacks. Currently, NSEP preferred access is established regardless of the specific service it is supposed to serve, even if only one service is used. Different NSEP services can benefit from service-specific network traffic characteristics, but it is currently not possible to customize the EDCA parameters for each service. Furthermore, when NSEP preferred access is established between an AP MLD and a non-AP MLD, it applies to all setup links in the MLD, even through the service, but it cannot be suitable for all of these links, only some of them. NSEP preferred access cannot be enabled only on a specific subset of MLD links, nor can it be prohibited on a specific subset of links among all setup links negotiated between the AP MLD and the non-AP MLD when they establish a connection. [Overview of the Initiative] [Means for solving the problem]

[0006] Therefore, there is a need to enable and configure NSEP-preferential access for MLD entities that avoids or mitigates one or more shortcomings of the conventional technology.

[0007] This background information is provided to clarify information that the applicant believes may be relevant to the present invention. It is not necessarily intended, nor should it be interpreted, as an acknowledgment that any of the aforementioned information constitutes prior art to the present invention.

[0008] Objectives of the present invention are to provide methods and systems that enable a pair of devices, such as a non-AP STA and AP, or a non-AP MLD and MLD, to provide NSEP capabilities by managing their multiple radio resources and mapping them to the requirements of NSEP access. The embodiments enable a pair of devices to map different radio resources to different types of NSEP services simultaneously, if necessary. The embodiments enable a system to authorize different services to different connected devices.

[0009] The embodiments enumerate different NSEP service types and associate each service type with a specific NSEP service. In the AP infrastructure, each NSEP service type may be associated with a corresponding parameter set, or with either a preferred link set or a prohibited link set. Furthermore, in the Network Authentication, Authorization, and Billing (AAA) infrastructure, one or more NSEP service types may be assigned to an AAA policy, which may be used to define eligible NSEP preferred access service types for its associated non-AP STA or non-AP MLD. An AP MLD may assign and map links to the required NSEP services, and more than one link may be used to map to a single NSEP service. Also, more than one NSEP services may be mapped to a single link.

[0010] The embodiments may also be used for non-MLD (Single Link Device) to configure NSEP services. Each NSEP service type may be associated with a corresponding set of parameters used to configure services between APs and non-AP STAs.

[0011] The embodiment allows the mechanism to define separate services using their respective parameters and specific link specifications. A mechanism is provided for simultaneously modifying parameters during service.

[0012] According to embodiments of the present invention, a method for configuring services in a communication network is provided. The method includes defining a service type by a service provider and associating the service type with an Expansion Distributed Channel Access (EDCA) / Preferred Access parameter set in the access point (AP) infrastructure by the service provider of the service type. Next, a wireless local area network (WLAN) entity is provisioned using the service type.

[0013] According to various embodiments, the WLAN entity is a multilink device (MLD), and the service type is associated with the set of links of the WLAN entity.

[0014] According to various embodiments, the set of links includes a subset of the links used for the service type.

[0015] According to various embodiments, the set of links includes a subset of links that are prohibited from being used for a particular service type.

[0016] According to various embodiments, the association between service types and EDCA / priority access parameter sets is based on the traffic characteristics of the service type.

[0017] In various embodiments, the provisioning of parameter sets in the AP infrastructure is performed using the Authentication, Authorization, and Billing (AAA) protocol.

[0018] According to embodiments of the present invention, a method for configuring a service in a communication network is provided. The method includes a WLAN entity transmitting an NSEP preferred access frame, the frame including the service type of the service.

[0019] According to various embodiments, the frame is either an NSEP Preferred Access Request or an NSEP Preferred Access Response frame.

[0020] According to various embodiments, an NSEP priority access response frame is sent to modify the parameters of a previously established NSEP service operation.

[0021] According to various embodiments, the WLAN entity is an access point (AP), and the frame further includes EDCA or a priority access parameter set used for the service type.

[0022] According to various embodiments, the AP is an AP belonging to an AP multi-link device (MLD), and the frame further includes a set of links of the service type.

[0023] According to various embodiments, the WLAN entity is a non-AP STA belonging to a non-AP multi-link device (MLD), and the request frame further includes a set of links of the service type.

[0024] According to various embodiments, the set of links includes a subset of links used for the service type.

[0025] According to various embodiments, the set of links includes a subset of links prohibited from being used for the service type.

[0026] According to various embodiments, the link complies with a network policy received from a subscription service provider network.

[0027] According to various embodiments, the transmission of the NSEP priority access request frame is transmitted in response to the MAC layer receiving a request primitive from the SME layer of the WLAN entity.

[0028] According to an embodiment of the present invention, a method for configuring a priority access service in a communication network is provided. The method includes encoding, by a WLAN entity, a service type of a priority service as an enumeration, inserting, by the WLAN entity, the service type into a frame, and transmitting, by the WLAN entity, the frame.

[0029] According to various embodiments, a priority access service is established between two peer MLDs, and the method further includes encoding, by a WLAN entity, link information of a link associated with a priority service as a plurality of octets, the plurality of octets indicating whether the link can be used for the priority service or is prohibited from being used for the priority service. Also, the WLAN entity inserts the link information into a frame.

[0030] According to various embodiments, the frame is an NSEP priority access request frame or an NSEP priority access response frame.

[0031] According to various embodiments, the frame is transmitted by a STA or an MLD, and the frame further includes a set of EDCA or priority access parameters based on the traffic characteristics of the priority service.

[0032] Embodiments provide the technical advantage of enabling devices and networks to apply differentiated parameters associated with priority access that are adjusted according to each type of service. Multiple services can be enabled simultaneously with respect to NSEP priority access and can be managed independently of each other by an access network operator.

[0033] Embodiments provide the technical advantage of adding a service type, a set of EDCA or priority access parameters, and recommended or prohibited links to an NSEP priority access primitive.

[0034] The embodiment provides the technical advantages of enabling association between NSEP preferred access service types and users or devices, enabling communication of that service type information when a user or device successfully authenticates with the network, and enabling the network AP infrastructure to authorize users or devices with respect to a set of NSEP services. When a user or device requests to establish NSEP preferred access to a particular service, the WLAN infrastructure can determine whether the user or device is authorized to provide that service.

[0035] The embodiment offers the technical advantage of adding service types and recommended or prohibited links to the NSEP preferred access primitive.

[0036] The embodiment provides the technical advantage of adding EDCA or priority access parameter sets and recommended or prohibited links to NSEP priority access request and NSEP priority access response frames with respect to the corresponding service type.

[0037] The embodiment offers the technical advantage of enabling the use of a specific EDCA or preferred access parameter set for communication of traffic associated with a negotiated NSEP service type. Furthermore, this enables the use of a specific set of links for communication between AP MLDs and non-AP MLDs for traffic associated with a negotiated NSEP service type.

[0038] The embodiment offers the technical advantage of enabling the use of spontaneous NSEP priority response frames or equivalent frames to update parameters associated with a particular NSEP service type during the lifetime of an established service.

[0039] Embodiments are described above in conjunction with embodiments of the invention in which they can be implemented. Those skilled in the art will recognize that embodiments may be implemented in conjunction with the embodiments described, but may also be implemented with other embodiments of that embodiment. Where embodiments are mutually exclusive or otherwise incompatible with one another, this will be obvious to those skilled in the art. Some embodiments may be described in relation to one embodiment, but may be applicable to other embodiments, as will be obvious to those skilled in the art.

[0040] Further features and advantages of the present invention will become apparent from the following detailed description in conjunction with the accompanying drawings. [Brief explanation of the drawing]

[0041] [Figure 1a] A multilink device (MLD) architecture according to one embodiment is shown. [Figure 1b] An architecture having AP and associated non-AP STA according to one embodiment is shown. [Figure 2] A typical network topology for a priority access service according to one embodiment is shown. [Figure 3] This describes the association between a preferred service type, a parameter set, a set of links, and an application, according to one embodiment. [Figure 4] This document illustrates a message flow for non-AP authentication and network policy enforcement according to one embodiment. [Figure 5] A primitive and a frame that may be used to carry out the method described herein, having their respective parameters (depending on the WLAN entity from which the primitive or frame is invoked), are shown according to one embodiment. [Figure 6] This example illustrates how information related to the service type and link may be added to a frame according to one embodiment. [Figure 7]This document shows primitives and frames that can be used for priority service access and service establishment according to one embodiment. [Figure 8] This describes a message flow that may be used to update preferred service parameters corresponding to an existing service type, according to one embodiment. [Figure 9] An electronic device that may be used to carry out the method described herein according to one embodiment is shown. [Modes for carrying out the invention]

[0042] Please note that similar features are identified by the same reference number in the attached drawings.

[0043] Embodiments of this disclosure relate to methods and systems that enable WLAN entities, such as non-access point (AP) stations (STAs) or APs, to provide national security and emergency preparedness (NSEP) capabilities by managing their radio resources and mapping them to NSEP access requirements. Embodiments enable WLAN entities to map radio resources to different types of NSEP services simultaneously as needed. Embodiments enable a system to authorize different services to different connected clients.

[0044] The embodiments enumerate different NSEP service types and associate each service type with a specific NSEP service. In an AP infrastructure, each NSEP service type may be associated with a corresponding Expansion Distributed Channel Access (EDCA) parameter set, or, in the case of NSEP preferred access service types established between multilink device (MLD) entities (AP MLDs and non-AP MLDs), the service type may be applied to a subset of setup links as either a preferred link set or a prohibited link set. Furthermore, in a network authentication, authorization, and billing (AAA) infrastructure, one or more NSEP service types may be assigned to an AAA policy, which can be used to define eligible NSEP preferred access service types for its associated non-AP STA or non-AP MLD. An AP MLD or non-AP MLD may assign and map a subset of setup links to the required NSEP services, with one or more links being used to map to a single NSEP service type. Also, one or more NSEP services may be mapped to a single setup link between an AP MLD and a non-AP MLD.

[0045] The embodiment allows the mechanism to define separate services using each parameter, such as EDCA or priority access parameters, and specific link designations. A mechanism is provided for simultaneously modifying parameters during the lifetime of established services.

[0046] While embodiments may be described in relation to NSEP priority access services, other priority service types, or different classes or priorities of service types, may be defined, configured, and adjusted using the methods and systems described herein.

[0047] As used herein, a station (STA) is a logical entity that is a single addressable instance of the media access control (MAC) and physical layer (PHY) interfaces to a wireless medium (WM). An access point (AP) is an entity that includes at least one logical station (STA) and provides access to distribution system services via the wireless medium (WM) to the associated STA. The AP has STA and distribution system access capabilities. A non-access point (non-AP) station (STA) is an STA that is not contained within an access point (AP).

[0048] As used herein, a multilink device (MLD) is an AP device or non-AP STA device that supports multiple radios operating simultaneously on multiple channels. An AP MLD is a multilink device that has access to the distribution system and includes at least one AP to which it belongs, which is used as access to the WM. A non-AP MLD is a multilink device that does not have access to the distribution system and includes at least one non-AP STA to which it belongs, which is used as access to the WM. The associated MLD peers establish connectivity across multiple radio peers called a setup link. In the infrastructure network, frame exchange takes place over a single link between a non-AP STA belonging to a non-AP MLD and an AP belonging to an AP MLD.

[0049] Referring to Figure 1a, a typical use case for multilink operation (MLO) involves a non-AP MLD106 (such as a WLAN terminal) connecting to AP MLD105 using two radio links in the 2.4GHz and 5GHz WLAN bands. Each individual radio link is called a link, and each link between AP MLD105 and non-AP MLD106 is maintained by APs belonging to AP MLD and non-AP STAs belonging to non-AP MLD for each of the different radio channels on which these links operate. Non-AP MLD106 includes a 2.4GHz non-AP STA110 and a 5GHz non-AP STA114. AP MLD105 includes AP108 on 2.4GHz and AP112 on 5GHz.

[0050] The IEEE 802.11 standard defines a WLAN entity as consisting of the following layers: the Station Management Entity (SME) layer, the Media Access Control (MAC) layer, and the Physical (PHY) layer. This standard includes internal interfaces between these components to describe the interactions of these layers and the behavior of WLAN entities. Communication through these internal interfaces is defined by primitives. Communication between the SME and MAC layers, and between the MAC and PHY layers, on the same entity is internal to the device, while communication between MAC / PHY peers takes place over the wireless medium.

[0051] Each non-AP STA110 and 114 includes a Media Access Control (MAC) layer and a Physical Hypothetical (PHY) layer. Radio antennas for sending and receiving wireless signals are not shown. The 2.4GHz AP108 and 5GHz AP112 belong to AP MLD105, and they exchange frames, respectively, with their corresponding 2.4GHz non-AP STA110 and 5GHz non-AP STA114, which belong to non-AP MLD106, via a setup link. The AP MLD interfaces to LAN104 for communication with wired gateway 102, which connects to other networks such as the Internet. The MAC layer of each MLD interacts to coordinate MAC layer operation in the STA to which it belongs. The MAC layer of the STA to which it belongs interacts with its respective PHY.

[0052] In embodiments, the operation of an MLD may differ from the operation of two logical STAs within the same physical entity (e.g., two non-AP STAs within the same handset) (multiband clients). Within an MLD, traffic may be coordinated between two links, and a single security association may be maintained across them. This offers advantages over the concept of a virtual STA. For example, the MLD in this document may be a single antenna device or a multi-antenna device with two or more antennas. The number of antennas included in the MLD is not limited by embodiment. In embodiments, an MLD may allow services of the same access type to be transmitted over different links, or even allow the same data packets to be transmitted over different or multiple links. Alternatively, data frames corresponding to the same access category may be transmitted over specific links. Data frames corresponding to different access categories may also be transmitted over different links. For example, data frames corresponding to video services may use either link 1 or link 2, while data frames corresponding to voice services may always use link 1 depending on the environment and other conditions.

[0053] In the case of MLO, proposed as part of IEEE 802.11be, preferred access, such as NSEP preferred access, can be established between AP MLD105 and associated non-AP MLD106. The preferred access protocol can grant a device preferential channel access to network communication resources compared to other network devices when frames related to preferred services are exchanged.

[0054] In this embodiment, each AP belonging to AP MLD105 can also be associated with a legacy non-AP STA. For example, an AP belonging to AP MLD105 operating on a 2.4GHz wireless link can also behave as a legacy AP serving a legacy 802.11 non-AP STA.

[0055] The IEEE 802.11 standard defines a WLAN entity as consisting of the following layers: the Station Management Entity (SME) layer, the Media Access Control (MAC) layer, and the Physical (PHY) layer. This standard includes internal interfaces between these components to describe the interactions of these layers and the behavior of WLAN entities. Communication through these internal interfaces is defined by primitives. Communication between the SME and MAC layers on the same entity, and between the MAC and PHY layers, is internal to the device, while communication between MAC / PHY peers takes place over the wireless medium. Layers such as the MAC layer in Figure 1a can be logically and physically separated between entities. For example, the MAC layer of a non-AP MLD106 is separated into a higher MAC for the non-AP MLD itself and a lower MAC for the 2.4GHz non-AP STA110. The upper MAC layer, which operates for all frames exchanged with non-AP MLDs (regardless of the link on which they are transmitted or received), is located with the SME layer, while the lower MAC layer, which operates for frames exchanged with peer non-AP STAs on a specific link, is located with the PHY layer.

[0056] Figure 1b shows an embodiment that includes a non-MLD WLAN entity with only one link. The non-AP STA106 is associated with AP105 using a single wireless link.

[0057] Figure 2 shows a diagram of the network topology 200 used to facilitate the preferred access described herein. A non-AP MLD 106 is associated with an AP (105a, 105b, or 105c) in the access network operated by a WLAN operator. The network access infrastructure 204 is connected to a subscription service provider network (SSPN) 208, which provides access to service providers 206, including or having access to an Authentication, Authorization, and Billing (AAA) server 218 and a policy server 216. A non-AP STA 106 may be associated with an AP (105a, 105b, or 105c) in the access network. The access network communicates with the AAA server 218 by an authentication protocol such as RADIUS, DIAMETER, or other similar protocol during the authentication procedure for the non-AP STA. The AAA server 218 authenticates the non-AP STA 106 and may obtain a policy for the non-AP STA 106 from the policy server 206 by a protocol such as Lightweight Directory Access Protocol (LDAP) or other similar protocol. Next, the authentication result may be returned to the access network along with any policy. If the authentication procedure is successful, the non-AP STA106 establishes a network connection, and the access network applies the network policy to the non-AP STA106.

[0058] As referred to herein, WLAN entity 106 may be either a non-AP MLD shown in Figure 1a or a non-AP STA shown in Figure 1b. Similarly, WLAN entity 105 (including 105a, 105b, and 105c) may be either an AP MLD shown in Figure 1a or an AP shown in Figure 1b.

[0059] In embodiments, priority access may be negotiated between a non-AP STA106 and the associated AP105 (any of 105a, 105b, or 105c) under specific circumstances, for example, when an event is detected by a non-AP STA106, AP105, or SSPN208. The event prompts the exchange of messages between the non-AP STA106 and the associated AP105 to establish network access. During the message exchange, the access network transmits a set of wireless medium access parameters that enable the non-AP STA106 to obtain priority access to the wireless medium (i.e., the channel). In embodiments, the parameter set may be an Extended Distributed Channel Access (EDCA) parameter set corresponding to an Emergency Readiness Communications Service (EPCS) service type, or a similar parameter set required to configure and manage communication channels and links for priority access. Examples of priority service types include emergency voice services, real-time sensor feeds, video camera feeds, and incident response systems.

[0060] Different types of devices may be permitted for different types of services. For example, a mobile phone may be used for an emergency voice service but not for a temperature sensor service. Therefore, a mobile phone is permitted for emergency voice, and a temperature sensor is permitted for temperature measurement. Different NSEP services can be characterized by different network traffic characteristics. A set of parameters may be associated with a particular service to prioritize its traffic.

[0061] Referring to Figure 3, the embodiment includes different service types 302 that can utilize priority access. Different priority services 302 may be defined and configured in an access network or an SSPN network 208. In an access network, each service type 302 is associated with a parameter set 304 and with a set of links 308 that may include valid links, preferred links, prohibited links, or any combination of valid links, preferred links, or prohibited links with respect to connections established between peer MLDs.

[0062] In SSPN208, the policy server 216 associates service type 302 with the device identity. When the device authenticates with the network, the policy server 216 may provide, via the AAA server 218, a list of services that the device is allowed to use for preferred access, such as NSEP preferred access. The list of services is returned to the access network. When NSEP preferred access is established, a set of recommended or prohibited links regarding the service type, associated (EDCA) parameter set, and services established between peer MLDs is communicated from AP MLD105 to non-AP MLD106 during the establishment of preferred access for the specified service type.

[0063] The service provider 206 may define and enumerate different priority service types 302 used for NSEP priority access in the access network 214. As an example, service types 302 may be enumerated to represent emergency voice, sensor communications, real-time video streaming, real-time messaging, and real-time audio communications or announcements. In the access network, each service type 302 that may be defined by the SSPN 208 is associated with a corresponding EDCA or priority access parameter set 304 that may be based on the traffic characteristics of the service. For example, the EDCA or priority access parameter set 304 may grant priority access to the wireless medium for voice traffic. In non-AP STA 106, each service defined by the SSPN 208 may be provisioned and, in multifunction devices, may be associated with an application or multiple applications running on the device. With respect to MLO, in AP MLD, each service type 302 defined by the SSPN 208 may be mapped to either a set of links used by the AP MLD for that service, or a set of prohibited links not used by the AP MLD for that service. Non-AP MLDs can also be provisioned by a preferred set of links for a given service type 302. A peer MLD can support multiple services simultaneously and map different service types 302 to different setup links depending on the radio resource requirements of the services.

[0064] The enumeration and provisioning of service types 302 offers the technical advantage of enabling devices and networks to apply differentiated EDCA or preferred access parameter sets 304 associated with preferred access, which can be tailored to the service type 302. Multiple services can be designated and enabled simultaneously with respect to preferred access by the operator of SSPN 208, and the operator of the access network 214 can map these service types to their respective infrastructure networks independently of each other.

[0065] In this embodiment, the policy server 216 may assign one or more service types 302 to an AAA policy. An AAA policy, which may include a set of service types 302, may be associated with a set of devices (or one or more users). Once a device successfully authenticates with the network, this policy assignment may be distributed to the AP or AP MLD for use with the device. The policy is stored in the policy server 216 and may be communicated to the AP 105 using an AAA protocol such as RADIUS or DIAMETER. A list of permitted service types may be sent from the AAA server 216 to the AP or AP MLD 105 for use with a non-AP STA or non-AP STA 106, using attributes such as RADIUS attributes. After successful authentication, the non-AP STA 106 may be granted preferential access to those service types. This policy defines the preferred access service types that are permitted for the associated non-AP STA or non-AP MLD 106. The policy allows the access network to enable preferred access to a device when the device is triggered and enabled.

[0066] Figure 4 shows one embodiment of the message flow relating to a non-AP STA106 performing authentication and association with AP105, and communication of service type 302 as part of a network policy for the successfully authenticated non-AP STA106. In step 402, the non-AP STA106 selects a network and successfully associates with and authenticates with AP105 using the IEEE 802.11 authentication and association procedure for the network. In step 404, the non-AP STA106 also performs authentication with the AAA server 218 using a protocol such as Extensible Authentication Protocol (EAP) or a similar protocol. In step 406, after successful authentication, the AAA server 218 in SSPN208 may query the policy server 216 for a network policy associated with the non-AP STA106's user or device identity, for example, using an LDAP policy query. In step 410, after receiving the policy information in step 408, the AAA server 218 may communicate the policy information corresponding to the non-AP STA106 to AP105 in a message indicating successful authentication using a protocol such as RADIUS. If the RADIUS protocol is used, this policy information may be communicated in a RADIUS ACCESS ACCEPT message. After successful authentication, AP105 and non-AP STA106 are permitted to request preferential access to their respective services. The preferred access service type may be stored locally to verify permission if the non-AP STA later requests preferential access. In steps 412 and 414, the Extensible Authentication Protocol (EAP) over LAN (EAPoL) protocol may be used to complete the configuration of communication between AP105 and non-AP STA106, and in step 416, data communication may be initiated between these STA peers.

[0067] Associating a preferred access service type 302 with a user or device, and communicating that service type information when the user or device successfully authenticates with the network, provides the technical advantage of enabling AP105 to authorize that device to use a set of services. If a user or device requests to establish preferred access to a particular service, AP105 can determine whether the user or device is authorized to use that service.

[0068] Referring to Figure 5, the embodiment includes primitives that can be incorporated and used in IEEE 802.11 and other networking protocols to implement the preferred access method described herein. While the primitives given in this embodiment refer to the NSEP protocol, it will be understood by those skilled in the art that these concepts and teachings can be adapted for use in other networking protocols. The primitives can be used between the SME layer and MAC layer within a non-AP STA106 or AP105.

[0069] Embodiments may also modify the NSEP Priority Access Frame, including the NSEP Priority Access Request Frame 504 and the NSEP Priority Access Response Frame 510, to implement the Priority Access Method described herein.

[0070] In this embodiment, primitives are exchanged between the SME layer and the MAC layer of a WLAN entity. The MLME-NSEP Priority Access Enable.request 502 primitive is sent from the SME layer to the MAC layer. The MLME-NSEP Priority Access Enable.indication 506 primitive is sent from the MAC layer to the SME layer. The MLME-NSEP Priority Access Enable.response 508 primitive is sent from the SME layer to the MAC layer. The MLME-NSEP Priority Access Enable.confirm 512 primitive is sent from the MAC layer to the SME layer.

[0071] In the embodiment, primitives and frames specify the service type to which they apply. Primitives and frames invoked by AP or AP MLD105 may specify EDCA or preferred access parameter sets. Primitives and frames used by or between AP MLD105 and non-AP MLD106 may specify a set of links used or not used by the service.

[0072] The SME layer of an STA may include the following parameters in the MLME-NSEP PRI ACCESS ENABLE.request primitive 502, which can initiate the establishment of an NSEP preferred access service with a specific peer STA. Primitive 502 includes information such as the service type (one of the enumerated service types defined by SSPN208). When invoked by an AP or AP MLD, primitive 502 may include the EDCA or preferred access parameter set used for the service type. When invoked by an AP MLD or non-AP MLD, primitive 502 may further include a set of links. The set of links may include a set of recommended links used for that service type, or a set of prohibited links for that service type if the initiating SME is in an MLD.

[0073] Upon receiving the MLME-NSEP PRI ACCESS ENABLE.request primitive 502, the MAC layer of the same WLAN entity initiates the transmission of an NSEP priority access request frame 504 to the MAC layer of its associated station. The frame 504 contains information such as the service type (one of the enumerated service types defined by SSPN 208). If the MAC layer is associated with an AP or AP MLD, the primitive 502 may include the EDCA parameter set used for the service type. If the MAC layer is associated with an AP MLD or a non-AP MLD, the primitive 502 may further include a set of links. The set of links may include a set of recommended links used for that service type, or a set of prohibited links for that service type if the initiating SME is in an MLD. In embodiments, the parameters of the NSEP priority access request frame 504 may be obtained from the MLME-NSEP PRI ACCESS ENABLE.request primitive 502 that triggered the transmission of the NSEP priority access request frame 504.

[0074] With respect to STA, the service type, the associated EDCA parameter set (if included), and the list of recommended or prohibited links (if included for MLD) may conform to the network policy communicated by SSPN208.

[0075] In this embodiment, the parameters of the NSEP Priority Access Request frame 504 may be obtained from the MLME-NSEP PRI ACCESS ENABLE.request primitive 502 that triggered the transmission of the NSEP Priority Access Request frame 504.

[0076] In response to receiving an NSEP Priority Access Request frame 504, the MLME-NSEP PRI ACCESS ENABLE.indication primitive 506 is generated by the receiving MAC layer and sent to its SME layer. If the SME layer is an AP or AP MLD, it may generate the MLME-NSEP PRI ACCESS ENABLE.response primitive 508, verifying that the requested NSEP service type and set of recommended or prohibited links (if included by the MLD) comply with the policy associated with the setup link between the device and peer MLD. Both primitives 506 and 508 contain information such as the service type (one of the enumerated service types defined by SSPN208), and primitive 508 may include the set of EDCA parameters used for the service type (if called by an AP or AP MLD), and the set of links (if the initiating entity is an MLD such as an AP MLD or a non-AP MLD). The set of links may include a set of recommended links used for that service type, or a set of prohibited links for that service type.

[0077] Upon receiving the MLME-NSEP PRI ACCESS ENABLE.response primitive 508, the MAC layer of the same WLAN entity initiates the transmission of an NSEP priority access response frame 510 to the MAC layer of the associated WLAN entity. Frame 510 contains information such as the service type (one of the enumerated service types defined by SSPN 208). If the request primitive was invoked by an AP or AP MLD, primitive 508 may include the EDCA parameter set used for the service type. If the WLAN entity is an AP MLD or a non-AP MLD, frame 510 may further include a set of links. The set of links may include a set of recommended links used for that service type, or a set of prohibited links for that service type if the initiating SME is in an MLD.

[0078] In response to receiving an NSEP Priority Access Response frame 510, the receiving MAC layer generates the MLME-NSEP PRI ACCESS ENABLE.confirm primitive 512 for transmission to its SME layer. The SME layer may verify that the requested NSEP service type and set of recommended or prohibited links (if included by the MLD) comply with the policy associated with the setup link between the device and the peer MLD. The primitive 512 includes information such as the service type (one of the enumerated service types defined by SSPN208), the set of EDCA parameters used for the service type (if invoked by a non-AP STA or non-AP MLD), and the set of links (if the initiating entity is an MLD such as an AP MLD or non-AP MLD). The set of links may include a set of recommended links used for that service type, or a set of prohibited links for that service type.

[0079] In the embodiment, the MLME-NSEP PRI ACCESS ENABLE.response primitive 508 causes the MAC layer to initiate the transmission of an NSEP priority access response frame 510 to the peer STA. If the SME is an AP or AP MLD, it configures its MAC layer with EDCA or a priority access parameter set; if the SME is an MLD, it configures its MAC layer with link information for NSEP priority access traffic corresponding to its service type (i.e., links to use or links to prohibit, if included by the MLD).

[0080] Upon receiving the MLME-NSEP PRI ACCESS ENABLE.confirm primitive 512, the SME layer may verify the NSEP service type and set of recommended or prohibited links (if included by the AP MLD) that conform to the request. The SME layer may configure its MAC layer with the EDCA parameter set and link information (i.e., links used or prohibited, if included by the MLD) for NSEP preferred access traffic corresponding to that service type.

[0081] In embodiments, adding service types and recommended or prohibited links (if included by MLD) to priority access primitives, such as those used in NSEP, offers several technical advantages. In addition to recommended and prohibited links, other types of links, such as required links or links with different priorities, may also be defined.

[0082] The embodiments may be used to add parameters to the NSEP Priority Access Request Frame 504 and the NSEP Priority Access Response Frame 510 in order to establish an NSEP Priority Access service between MLD peers. In particular, parameters relating to the service type and either a list of recommended or prohibited links may be included in the NSEP Priority Access Request Frame 504 and the NSEP Priority Access Response Frame 510.

[0083] The service type field is defined by a one-octet field 602 and may represent an enumerated NSEP service type defined by SSPN. For example, if the NSEP service types include emergency voice service, real-time sensor feed, video camera feed, and incident response system, the emergency voice service may be represented by service type=0, the real-time sensor feed by service type=1, the video camera feed by service type=2, and the real-time sensor feed by service type=3. One octet allows up to 256 different service types to be defined. In embodiments, a single service type is established at a time.

[0084] A set of recommended or prohibited links may be contained in an NSEP link element 604 which includes several fields. The Link Count field 606 may indicate the number of recommended or prohibited links, including a flag 608 indicating whether the link is prohibited or recommended. The Link ID Count field 610 may indicate the number of Link ID Information fields 610 in the NSEP link element 604. The Prohibited Links field 608 may be set to 1 to indicate that the link is prohibited for a particular NSEP preferred access service. The Prohibited Links field 608 may be set to 0 to indicate that the link is recommended for a particular NSEP preferred access service. The Link ID Information field 612 may contain the Link ID of the link specified in the NSEP link element 604.

[0085] In the embodiment, an AP belonging to the initiating AP MLD105, or an STA belonging to the initiating non-AP MLD106, may include a service type field 602 in the NSEP preferred access request frame 504 or NSEP preferred access response frame 510 that it generates. Any STA belonging to an MLD may include an NSEP link element 604 in the NSEP preferred access request frame 504 or NSEP preferred access response frame 510 that it generates. With respect to the MLO, the elements of the NSEP link element 604 may indicate either a list of recommended links for communication or a list of prohibited links for communication. In addition, an (non-MLD) AP or an AP belonging to an AP MLD may include an EDCA or preferred access parameter set element in the NSEP preferred access request frame 504 or NSEP preferred access response frame 510 that it generates. The values ​​included in the EDCA or preferred access parameter set element should conform to the service type for which NSEP preferred access is established.

[0086] To establish NSEP priority access services between MLD peers, there are technical advantages to adding the service type, the parameter set corresponding to that service type, and recommended or prohibited links to the NSEP priority access request frame 504 and the NSEP priority access response frame 510.

[0087] In the embodiment, once NSEP priority access is negotiated, for example, by using the method shown in Figure 4, the NSEP priority access service is applied to the established service type between the associated pair of AP105 and non-AP STA106, or between the associated pair of AP MLD and non-AP MLD.

[0088] Channel access rules for NSEP preferred access may be defined according to the EDCA or preferred access parameter set for the negotiated link set defined by the AP belonging to AP105 or AP MLD105 during service establishment, instead of other default parameters that may be communicated by the AP belonging to AP105 or AP MLD105 in the beacon and probe response frames that may be transmitted. The EDCA or preferred access parameters used are applicable to the traffic corresponding to the negotiated service type. For MLDs, the links on which frames are exchanged by both peer MLDs (i.e., AP MLD105 and non-AP MLD106) with respect to the established service type follow the links defined in the recommended link set, as recommended by the MLME-NSEP PRI ACCESS ENABLE.request 502 primitive and confirmed by the MLME-NSEP PRI ACCESS ENABLE.response 508 primitive, or exclude the links defined in the prohibited link set. Multiple different service types of preferred access can be negotiated independently and can operate simultaneously between non-AP STA106 and AP105 pairs.

[0089] Figure 7 shows an embodiment of a method for NSEP priority access negotiation and service establishment when initiated by AP MLD105. While Figure 7 shows the method being initiated by the AP or AP MLD side, it should be understood that the method can also be initiated by a non-AP STA or non-AP MLD side, and the primitives and frames used include parameters described with reference to Figure 5.

[0090] In step 710, an external event may trigger the SME layer 708 of APMLD105 to call the MLME NSEP PRI ACCESS ENABLE.request primitive 502 and send it to the MAC layer 706 of AP MLD105. In step 712, the MAC layer 706 initiates the transmission (by the AP105 to which it belongs) of an NSEP Priority Access Request frame 504, which includes the service type, a set of recommended or prohibited links (included for MLD), and an EDCA or priority access parameter set.

[0091] The NSEP Priority Access Request frame is received by the MAC layer 704 of the non-AP MLD 106 via the STA attached to the non-AP MLD, and in step 714, the MAC layer 704 may send the MLME NSEP PRI ACCESS ENABLE.indication primitive 506 to the SME layer 702. In step 716, the SME layer 702 responds with the MLME NSEP PRI ACCESS ENABLE.response primitive 508, and in step 718, this may trigger the transmission of an NSEP Priority Access Response frame 510 to the peer STA operating on the link from which the Request frame was sent. The NSEP Priority Access Response frame 510 may include a service type and a set of recommended or prohibited links in the frame 510. After successfully initiating the transmission of frame 510, the SME layer 708 of the non-AP MLD 106 may then configure a parameter set to the MAC layer 706 of the non-AP MLD 106 along with the link information. The MAC layer 706 of AP MLD105 receives the NSEP Priority Access Response frame 510 and, in step 720, sends the MLME NSEP PRI ACCESS ENABLE.confirm primitive 512 to the SME layer 708. The SME layer 708 of AP MLD105 may also configure a parameter set to the MAC layer 706 of AP MLD105 along with link information. In step 722, traffic associated with its service type may then be transmitted over the negotiated set of links using the negotiated parameter set.

[0092] In this embodiment, the NSEP priority access request frame 504 transmitted by the MAC layer of the WLAN entity may receive its parameters from the MLME NSEP PRI ACCESS ENABLE.request primitive 502 received from its SME. The MLME NSEP PRI ACCESS ENABLE.indication primitive 506 may be generated by the MAC layer of the WLAN entity using the parameters received in the NSEP priority access request frame 510 received by the WLAN entity. Furthermore, the NSEP priority response frame 510 is transmitted by the MAC layer of the WLAN entity using the parameters received in the MLME NSEP PRI ACCESS ENABLE.response primitive 508. The values ​​of the parameters in the MLME NSEP PRI ACCESS ENABLE.response primitive 508 are determined by the SME layer based on the parameters received in the MLME NSEP PRI ACCESS ENABLE.indication primitive 506. The MLME NSEP PRI ACCESS ENABLE.confirm primitive 512 is generated by the MAC layer of the WLAN entity using parameters received by the WLAN entity in the NSEP priority response frame 510.

[0093] The use of a specific EDCA or preferred access parameter set for communication between AP MLD105 and non-AP MLD106 for traffic associated with a negotiated NSEP service type provides a technical advantage because it enables the use of a specific set of links for communication between AP MLD105 and non-AP MLD106 for traffic associated with a negotiated NSEP service type.

[0094] In one embodiment, multiple priority services, such as NSEP services, can operate simultaneously. However, to optimize traffic flow when multiple services are operating, or to address any other conditions of the wireless network, the AP or AP MLD105 can update the priority service configuration to accommodate aggregation, deaggregation, or optimization of priority services. This can be done by transmitting spontaneous mode frames, such as NSEP priority access response frames 510, which indicate the service type.

[0095] Spontaneous updates can take the form of link mapping updates (by AP MLD105 or non-AP MLD106) or parameter set updates (when invoked only by AP or AP MLD105). Figure 8 shows an embodiment of AP MLD105 using a spontaneous mode, such as a spontaneous NSEP priority access response frame 510, to update parameters for a specific priority access service type. While Figure 8 shows the method being initiated by the AP or AP MLD side, it should be understood that the method can also be initiated by the non-AP STA or non-AP MLD side, and the primitives and frames used include parameters described with reference to Figure 5.

[0096] In step 802, the NSEP service is operational and has been previously configured and enabled using the methods described herein. An event triggers a change to the parameters associated with an existing preferred access service of a particular service type, and in step 804, the SME layer 708 of AP MLD105 may send the MLME NSEP PRI ACCESS ENABLE.response primitive 508 to the MAC layer 706 of AP MLD105. In step 806, the MAC layer 706 of the AP belonging to AP MLD105 sends a spontaneous response frame, such as the NSEP preferred access enable response frame 510, to the MAC layer 704 of the non-AP STA belonging to the non-AP MLD106. In step 808, the MAC layer sends MLME NSEP PRI ACCESS ENABLE.confirm 512 to the SME layer 702 of the non-AP MLD106. Both devices update their parameters associated with their service type and continue to exchange frames related to their NSEP preferred access service in step 810.

[0097] In the embodiment, a dedicated frame may be defined to signal a change to an NSEP preferred service access configuration. The new frame may be called an (NSEP) preferred access update frame, having the same or similar format as an NSEP preferred access response frame 510 when used in spontaneous mode.

[0098] In this embodiment, the spontaneous NSEP priority access response frame 510 is transmitted by the MAC layer of the WLAN entity using the parameters included in the reception of the MLME NSEP PRI ACCESS ENABLE.response primitive 508. The MLME NSEP PRI ACCESS ENABLE.confirm primitive 512 is generated by the MAC layer of the WLAN entity using the parameters received in the spontaneous NSEP priority access response frame 510.

[0099] The use of spontaneous NSEP priority access response frames or equivalent frames offers the technical advantage of updating parameters associated with specific priority service types during the lifetime of an established service.

[0100] Figure 9 is a schematic diagram of an electronic device 900 capable of performing any or all of the operations of the methods and features described herein, either explicitly or implicitly, according to different embodiments of the present invention. For example, such an electronic device with networking capabilities may be configured as AP105, non-AP STA106, AP MLD105, or non-AP MLD106, or any other networking device or server described herein.

[0101] As shown in the figure, the device includes a processor 910 such as a central processing unit (CPU) or a dedicated processor such as a graphics processing unit (GPU) or other such processor unit, memory 920, non-temporary mass storage 930, I / O interface 940, network interface 950, video adapter 970, and one or more transceivers 960, all of which are communicatively coupled via a bidirectional bus 925. The video adapter 970 may be connected to one or more displays 975, and the I / O interface 940 may be connected to one or more I / O devices 945 that can be used to implement a user interface. Depending on the particular embodiment, any or all of the illustrated elements, or only a subset of the elements, may be used. Furthermore, the device 900 may include multiple instances of certain elements such as multiple processors, memory, or transceivers. Also, elements of the hardware device may be directly coupled to other elements without a bidirectional bus. In addition to the processor and memory, or instead, other electronic devices such as integrated circuits may be used to perform the necessary logical operations.

[0102] Memory 920 may include any type of non-temporary memory, such as static random-access memory (SRAM), dynamic random-access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or any combination thereof. Mass storage element 930 may include any type of non-temporary storage device, such as a solid-state drive, hard disk drive, magnetic disk drive, optical disk drive, USB drive, or any computer program product configured to store data and machine-executable program code. According to a particular embodiment, memory 920 or mass storage 930 may record statements and instructions that can be executed by the processor 910 to perform any of the aforementioned method operations described above.

[0103] While specific embodiments of the Art are described herein for illustrative purposes, it will be recognized that various modifications can be made without departing from the scope of the Art. Accordingly, this specification and the drawings should be considered merely illustrative of the Invention as defined by the appended claims, and are intended to encompass all possible modifications, variations, combinations, or equivalents within the scope of the Invention. In particular, providing computer program products or program elements, or program storage or memory devices such as magnetic or optical wires, tapes, or disks, for storing machine-readable signals, for controlling the operation of a computer according to the methods of the Art, and / or for structuring some or all of its components according to the systems of the Art, falls within the scope of the Art.

[0104] The operations related to the methods described herein can be implemented, at least in part, as coded instructions within a computer program product. In other words, the computer program product is a computer-readable medium on which software code for performing the methods is recorded when the computer program product is loaded into memory and executed on the microprocessor of a wireless communication device.

[0105] Throughout the description of the embodiments described herein, the present invention may be implemented using hardware alone or using software and the necessary general-purpose hardware platform. Based on this understanding, the technical solutions of the present invention may be embodied in the form of a software product. The software product may be stored on a non-volatile or non-temporary storage medium which may be a compact disc read-only memory (CD-ROM), a USB flash disk, or a removable hard disk. The software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to perform the methods provided in embodiments of the present invention. For example, such execution may correspond to the simulation of the logic operations described herein. The software product may also include a number of instructions that enable a computer device to perform operations for configuring or programming a digital logic device in accordance with embodiments of the present invention.

[0106] According to one embodiment, a method for configuring services in a communication network is provided. This method includes defining a service type by a service provider and associating the service type with an Expansion Distributed Channel Access (EDCA) / Preferred Access parameter set in the access point (AP) infrastructure by the service provider of the service type. Next, the service type is associated with a WLAN entity.

[0107] In one embodiment, the WLAN entity is a multilink device (MLD), and the service type is associated with the set of links of the WLAN entity.

[0108] In one embodiment, the set of links includes a subset of links used for the service type.

[0109] In one embodiment, the set of links includes a subset of links that are prohibited from being used for a particular service type.

[0110] In one embodiment, the definition of a service type includes enumerating a plurality of service types, which include the service type.

[0111] In one embodiment, the association between the service type and the EDCA / priority access parameter set is based on the traffic characteristics of the service type.

[0112] In one embodiment, the service type is associated with a non-AP STA application.

[0113] According to one embodiment, a method for configuring a service in a communication network is provided. This method includes an authentication server assigning a service type to an authorization policy and associating the authorization policy with a non-AP station (STA) or non-AP MLD wireless local area network (WLAN) entity. In response to the WLAN entity authenticating to the communication network, a network policy for the service type is sent to the AP infrastructure.

[0114] In one embodiment, sending network policies to the AP infrastructure is performed using the Authentication, Authorization, and Billing (AAA) protocol.

[0115] According to one embodiment, a method for configuring a service in a communication network is provided. This method includes a WLAN entity transmitting an NSEP preferred access frame, the frame including the service type of the service.

[0116] In one embodiment, the frame is an NSEP priority access request frame.

[0117] In one embodiment, the frame is an NSEP priority access response frame.

[0118] In one embodiment, the NSEP Preferred Access Response frame is sent in response to a WLAN entity receiving an NSEP Preferred Access Request frame.

[0119] In one embodiment, an NSEP priority access response frame is sent to modify the parameters of a previously established NSEP service operation.

[0120] In one embodiment, the WLAN entity is an access point (AP), and the frame further includes an EDCA or preferred access parameter set used for the service type.

[0121] In one embodiment, AP is an AP belonging to an AP Multilink Device (MLD), and frame further includes a set of service-type links.

[0122] In one embodiment, the WLAN entity is a non-access point (AP) station (STA).

[0123] In one embodiment, a non-AP STA belongs to a non-AP multilink device (MLD), and the request frame further includes a set of service-type links.

[0124] In one embodiment, the set of links includes a subset of links used for the service type.

[0125] In one embodiment, the set of links includes a subset of links that are prohibited from being used for a particular service type.

[0126] In one embodiment, the link complies with the network policy received from the subscription service provider network.

[0127] In one embodiment, the transmission of the NSEP Priority Access Request frame is sent in response to the MAC layer receiving a request primitive from the SME layer of the WLAN entity.

[0128] According to one embodiment, a method for configuring a priority access service in a communication network is provided. This method includes encoding the service types of the priority service as an enumeration by a WLAN entity, inserting the service types into a frame by a WLAN entity, and transmitting the frame by a WLAN entity.

[0129] In a further embodiment, a preferred access service is established between two peer MLDs, and the method further includes a WLAN entity encoding the link information of the link associated with the preferred service as multiple octets, the multiple octets indicating whether the link may be used for the preferred service or is prohibited from being used for the preferred service. The WLAN entity also inserts the link information into a frame.

[0130] In one embodiment, the frame is an NSEP preferred access request frame or an NSEP preferred access response frame.

[0131] In one embodiment, the frame is transmitted by an access point (AP) or AP multilink device (MLD), and the frame further includes an EDCA or set of preferred access parameters based on the traffic characteristics of the preferred service.

[0132] In one embodiment, the frame is an NSEP preferred access response frame, which is transmitted in response to the receipt of an NSEP preferred access request frame.

[0133] In one embodiment, the frame is an NSEP priority access response frame, sent to correct a previously established NSEP service operation.

[0134] Although the present invention has been described with reference to its specific features and embodiments, it is evident that various modifications and combinations can be made with respect to them without departing from the invention. Accordingly, this specification and drawings should be considered merely illustrative of the invention as defined by the appended claims and are intended to encompass all possible modifications, variations, combinations, or equivalents that fall within the scope of the invention. [Explanation of symbols]

[0135] 102 Wired Gateway 104 LAN 105 APs, AP MLDs, WLAN Entities 105a AP 105b AP 105c AP 106 Non-AP MLD, WLAN Entity 108 AP 110 Non-AP STA 112 AP 114 Non-AP STA 200 Network Topologies 204 Network Access Infrastructure 206 Service Providers 208 SSPN 214 Access Network 216 Policy Server 218 AAA Servers 302 Service Type, Priority Service 304 Preferred Access Parameter Set Set of 308 links 502 Primitive 504 NSEP Preferred Access Request Frame 506 Primitive 508 Primitive 510 NSEP Priority Access Response Frame 512 Primitives 602 Service Type Field 604 NSEP link element 606 Link Count Field 608 Forbidden Link Field, Flag 610 Link ID Count field, Link ID Information field 612 Link ID Information Field 702 SME layer 704 MAC layer 706 MAC layer 708 SME layer 900 Electronic Devices 910 Processor 920 memory 925 Two-way bus 930 Non-temporary high-capacity storage, high-capacity storage element 940 I / O interfaces 945 I / O devices 950 Network Interfaces 960 Transceiver 970 Video Adapter 975 Display

Claims

1. A method for configuring a service in a communication network, A step of a wireless local area network (WLAN) entity transmitting an Emergency Readiness Communications Service (EPCS) priority access frame, wherein the frame includes a service type of the service, a set of Extended Distributed Channel Access (EDCA) parameters, and a set of links, the service type being associated with the set of EDCA parameters based on the traffic attributes of the service type, and the set of links including a subset of links used for the service type and a subset of links prohibited from being used for the service type. Methods that include...

2. The method according to claim 1, wherein the frame is an EPCS priority access response frame.

3. The method according to claim 2, wherein the EPCS priority access response frame is sent to modify parameters of previously established EPCS service operation.

4. The method according to any one of claims 1 to 3, wherein the WLAN entity is an access point (AP) or a non-AP station (STA).

5. The method according to any one of claims 1 to 3, wherein the WLAN entity is an AP belonging to an access point (AP) multilink device (MLD) or a non-AP station (STA) belonging to a non-AP MLD.

6. A method for configuring a priority access service in a communication network, The step of receiving an Emergency Readiness Communications Service (EPCS) Priority Access frame from a Wireless Local Area Network (WLAN) entity, wherein the frame includes a service type of the Priority Access Service, a set of Extended Distributed Channel Access (EDCA) parameters, and a set of links, wherein the service type is associated with the set of EDCA parameters based on the traffic attributes of the service type, and the set of links includes a subset of links used for the service type and a subset of links prohibited from being used for the service type. Methods that include...

7. The method according to claim 6, wherein the frame is an EPCS priority access response frame.

8. The method according to claim 7, wherein the EPCS priority access response frame is used to modify parameters of previously established EPCS service operation.

9. The method according to any one of claims 6 to 8, wherein the WLAN entity is an access point (AP) or a non-AP station (STA).

10. The method according to any one of claims 6 to 8, wherein the WLAN entity is an AP belonging to an access point (AP) multilink device (MLD) or a non-AP station (STA) belonging to a non-AP MLD.

11. A device comprising at least one processor and a memory storing instructions, wherein, when an instruction is executed by the at least one processor, the device causes the device to carry out the method according to any one of claims 1 to 3.

12. A device comprising at least one processor and a memory storing instructions, wherein, when an instruction is executed by the at least one processor, the device causes the device to carry out the method according to any one of claims 6 to 8.

13. A program including program instructions, wherein when the program instructions are executed on a computer, the computer becomes capable of carrying out the method according to any one of claims 1 to 3.

14. A program including program instructions, wherein when the program instructions are executed on a computer, the computer becomes capable of carrying out the method according to any one of claims 6 to 8.

15. A computer-readable storage medium storing program instructions, wherein when the program instructions are executed, the method according to any one of claims 1 to 3 or any one of claims 6 to 8 is performed.

Images