HK1180868A - An access point and a station and a method for use in the access point and the station - Google Patents

Abstract

The invention provides an access point and a station and a method for using in the access point and the station, the access point comprising: a receiver configured to receive, from a station (STA) an association message that includes a basic service set identity (BSSID); and a processor configured to determine whether the BSSID received in the association message is associated with a security credential, and grant the STA access to the AP based on the security credential, wherein the access is limited to emergency calls.

Description

Access point and station and method for use in access point and station

The application is a divisional application of an invention patent application with the application date of 26.02/2007 and the application number of 200780007567.X, and the name of "supporting emergency calls on a wireless local area network".

Technical Field

The present invention relates generally to Wireless Local Area Networks (WLANs), and more particularly to supporting emergency calls in WLANs.

Background

Traditionally, existing 802 technologies (802.11 WLAN, 802.15 Wireless Personal Area Network (WPAN), etc.) do not have to support emergency calls as do cellular technologies. The support provided for emergency calls for cellular technology is generally generated by regulatory requirements imposed on the technology and is thus widely implemented in most of the wireless cellular networks and handsets deployed today. The support provided for emergency calls involves many aspects across all communication layers, particularly signaling support and management (managed) procedures, but these procedures do not exist for 802.11 and 802.15 technologies. With the advent of voice over internet protocol (VoIP) in WLANs and the increasing use of WLANs on a daily basis, it is necessary to support emergency calls in WLANs.

Even the provision of "fixed" VoIP telephony services for the residential market provides very limited support for emergency calls. Dispatchers at Public Safety Answering Points (PSAPs) cannot always track digital location information, call backs are not always feasible, and address registration may also be required when purchasing a device. When moving the VoIP phone to a new location, the emergency call will still be sent based on the registered address location. This registered address may in principle change, but there may be at least a few days or weeks of delay in updating the information on the PSAP. Furthermore, some users may not have to update their registration information in a timely manner, if possible.

This situation will worsen as VoIP phones using WLAN enable more mobility. A WLAN-based VoIP phone can work from any location and it is expected that users will seamlessly roam between these locations, e.g., from office to home to public hotspots, etc.

There are some 802.11 specific problems that currently exist, including radio access, Access Point (AP) location, caller location, and emergency call admission. For radio access, there is currently no priority for emergency calls in the 802.11 standard, and there is currently no means to distinguish emergency calls from regular calls of the WLAN access network. For example, currently in a non-proprietary manner, even if the AP identity is easily determined, the location of the AP or STA is not known to the network. Furthermore, the location of the calling party is currently not mappable in a non-proprietary way.

In terms of admission, closely managed WLANs may prevent emergency callers from establishing an emergency call if they are not authorized to enter the network. The normal connection procedure between the STA and the AP requires the STA to send an association request followed by a negotiation with the AP before associating the STA with the AP. If the STA cannot indicate that it is making an emergency call, it must go through the entire association process to determine if it is authorized. As an example of such a challenge, if the STA does not have the correct password or authentication credentials to access the system (if the AP is configured to require a password or authentication credentials, which is possible, for example, for private hotspots or enterprise/office WLANs), the AP will immediately deny the STA's association request. However, even if the STA has the correct password or authentication credentials, the AP will still deny network access based on the maximum capacity of voice users configured for it. In this case, the correct decision for the AP should be to admit this new emergency call (at the highest priority) and to drop another existing voice call. Since the AP currently lacks means for such differentiation in the first place, this feature cannot be implemented by means of the WLAN techniques of the prior art. In contrast to cellular system operation, any one device, even a device without a SIM card, may perform an emergency call in cellular system operation.

Disclosure of Invention

The present invention provides an Access Point (AP), comprising: a receiver configured to receive an association message including a Basic Service Set Identification (BSSID) from a Station (STA); and a processor configured to determine whether the BSSID received in the association message is associated with a security credential and authorize access by the STA to the AP based on the security credential, wherein the access is limited to emergency calls.

The present invention also provides a Station (STA) comprising: a transmitter configured to transmit an association message comprising a Basic Service Set Identification (BSSID), wherein the BSSID is associated with a security certificate; and a receiver configured to receive access to the AP, wherein the access is limited to emergency calls.

The present invention also provides a method for use within an Access Point (AP), the method comprising: receiving an association message including a Basic Service Set Identification (BSSID) from a Station (STA); determining whether the BSSID received in the association message is associated with a security certificate; and authorizing access by the STA to the AP based on the security credentials, wherein the access is limited to emergency calls.

The present invention also provides a method for use within a Station (STA), the method comprising: transmitting an association message comprising a Basic Service Set Identification (BSSID), wherein the BSSID is associated with a security certificate; and receiving access to the AP, wherein the access is limited to emergency calls.

The present invention proposes various system operating features for enabling emergency call processing support via 802.11 and 802.15 technologies. Some of these proposals relate to a new L2 signalling message or information element for indicating an emergency call to the AP. And new procedures and control mechanisms for emergency situations are proposed herein. In addition, procedures for dual mode (WLAN and second generation (2G) or third generation (3G) cellular technologies) implementations are also addressed. Since emergency call requirements are often combined with regulatory requirements for location reporting of emergency calling party locations, means and signaling procedures are proposed herein for allowing requesting and reporting of geographical locations in WLAN networks. The location information may be combined with the emergency call or may be performed independently.

One benefit of having a STA capable of identifying emergency calls is that it can install simple logic on the AP that allows the AP to distinguish STAs that should be treated normally (i.e. that should follow the normal association procedure) and STAs that should be admitted in all circumstances (i.e. that will bypass all security requirements to admit emergency calls) regardless of the network configuration.

Several methods are provided for communicating emergency call capability information between a station and an Access Point (AP) in a wireless local area network. These methods include: the AP advertises its emergency call capabilities, and the station advertises its emergency call capabilities. The AP may advertise its emergency call capability in a beacon frame, a probe response frame, a reassociation response frame, or a revalidation response frame. The station may then announce its emergency call capability in an association request frame, a reassociation request frame, an authentication request frame, or a revalidation request frame.

One method for supporting an emergency call in a WLAN begins with a STA initiating an emergency call on the WLAN. The emergency call is received by the AP on the WLAN and is admitted without requiring the STA to perform an authentication procedure. The STA is provided with settings related to the emergency call to allow the STA to access the WLAN.

One method for supporting an emergency call in a WLAN begins with a station initiating an emergency call on the WLAN. The emergency call is received by the AP on the WLAN and is admitted without requiring the STA to perform an authentication procedure. In addition, the emergency call will be routed to an emergency call center.

One method for supporting emergency calls in a WLAN begins by providing an emergency BSS ID to the STA, where the emergency BSS ID is used only for emergency calls. Any emergency call initiated by a STA will use this emergency BSS identifier.

One method for supporting an emergency call in a WLAN begins with a STA initiating an emergency call on the WLAN. The emergency call is received by the AP on the WLAN. The STA will be determined whether it has sufficient capability to complete the emergency call. If the STA does not have sufficient capability to complete the emergency call, the components of the infrastructure network act as a proxy for the STA to complete the emergency call.

Drawings

The invention will be understood in more detail from the following description of preferred embodiments, given by way of example and understood in conjunction with the accompanying drawings, in which:

FIG. 1 is a diagram of a standard Medium Access Control (MAC) frame;

fig. 2A is a diagram of a MAC frame with a bit flag to indicate an emergency call;

fig. 2B is a diagram of a MAC frame with an Information Element (IE) for indicating an emergency call;

FIG. 3 is an illustration of a standard ready-to-send (RTS) frame;

fig. 4A is a diagram of an RTS frame with a bit flag to indicate an emergency call;

fig. 4B is an illustration of an RTS frame with an IE for indicating an emergency call;

fig. 5 is a flow chart of a method of using an RTS frame as shown in fig. 4A or 4B;

fig. 6 is a flow chart of a method of completing an emergency call by switching radio technologies;

fig. 7 is a diagram of an SOS beacon frame for indicating an emergency call;

FIG. 8 is a flow chart of a method for transmitting and using SOS frames as shown in FIG. 7; and

fig. 9 is a flow chart of a method for determining whether to apply a proxy function.

Detailed Description

In the following, the term "station" (STA) includes, but is not limited to, a wireless transmit/receive unit (WTRU), user equipment, a fixed or mobile subscriber unit, a pager, or any other device capable of operating in a wireless environment. The term "access point" (AP) as referred to below includes, but is not limited to, a base station, a node B, a site controller, or any other interfacing device capable of operating in a wireless environment.

The present invention is applicable to all WLANs, Personal Area Networks (PANs), and Metropolitan Area Networks (MANs), and more particularly to 802.11-based WLANs, 802.15-based wireless PANs, 802.16/20-based wireless MANs, and equivalents thereof. In one implementation, the present invention is applicable to WTRUs implementing a combination of these access technologies, including WLAN, PAN, MAN, and cellular multi-mode WTRUs.

The following is a description of the present invention for handling emergency support in sections. However, this is done for ease of illustration only and is not meant to be a limitation of the invention.

I. Signaling/support related air interface and procedure

Emergency call indication in MAC frames and MAC signaling messages

A standard MAC frame 100 is shown in fig. 1. The MAC frame 100 includes a frame control field 102, a duration/ID field 104, one or more address fields 106 a-106 d, a sequence control field 108, a quality of service (QoS) control field 110, a frame body 112, and a Frame Check Sequence (FCS) field 114. As shown, the QoS control field 110 is divided into a plurality of subfields.

The priority of the emergency call may be indicated in the MAC frame by a bit flag, an emergency call message type IE, an emergency call message field part on an existing or new IE, or an emergency call code implemented using a reserved (currently unused) value in an existing IE or MAC frame field. The indicator enables the AP to know that it must admit the emergency call. For similar purposes, the QoS priority or requirement is indicated by means of a QoS classification, e.g. diffserv (differentiated services). Any existing MAC frame type (control, management or data) may be modified to include an emergency call indicator. The emergency call indicator may be added anywhere in the MAC frame, header or body using any of the mechanisms described.

As shown in FIG. 2A, MAC frame 200 includes fields 202-214, which are the same as fields 102-114 described above in connection with FIG. 1. In one embodiment, a simple bit flag 220 is used to indicate to the receiver that this is an emergency call. As shown in fig. 2A, one possible location of the bit flag 220 is in the reserved bit (bit 7) of the QoS control field 210. One of ordinary skill in the art will note that the bit flag 220 may be placed in any current reserved location in any existing header or frame body field of the MAC frame.

As shown in fig. 2B, the MAC frame 250 includes a frame control field 252, a length field 254, and an emergency call IE256 for indicating an emergency call. The emergency call IE256 may include, but is not limited to, an emergency call flag 260, a reason code field 262, a capability information field 264, a location information field 266, a voice codec application field 268, and an additional field 270. The emergency call IE256 may be added in any MAC frame. In addition, the information contained in the emergency call IE256 may be added to the existing IE type.

The emergency call flag 260 may be a simple indicator (e.g., a bit flag) that identifies the call as an emergency call. The reason code field 262 indicates the reason for the emergency call (e.g., fire, medical emergency, etc.). The capability information field 264 includes the capabilities of the STA initiating the emergency call and is used to help complete the emergency call as quickly as possible. The location information field 266 contains the location of the STA that initiated the emergency call. The voice codec application field 268 identifies the voice codec used by the STA and may be used in situations where there is incompatibility between the STA and the AP attempting to handle the emergency call. Additional information that may be included in the emergency call IE (as field 270) is a timestamp and WTRU and/or operator service capability information.

Existing MAC frames according to 802.11e have call priority. In the transmission specification information field, a Transmission Specification (TSPEC) IE contains three bit priority subfields. The principles of the present invention may also be implemented in the TSPEC IE as well, if values for emergency calls are defined. In cellular systems, a similar mechanism (signalling frame) is used to send call parameters to the network and a reserved field is included to identify emergency calls. As is known in the art, the TSPEC IE is used in ADDTS (add traffic stream) frames. Thus, the modified TSPEC IE described herein may be used in ADDTS frames. Also, a new IE containing the same information may be used in the ADDTS frame to indicate an emergency call.

Although the above description has a particular description of an 802.11-based MAC frame, the concept of extending a MAC frame can also be applied to any type of MAC frame. For example, a MAC frame of Ethertype (Ethertype) may also be modified similarly. For example, such MAC frames are used in EAPOL (extensible authentication protocol over LAN) frames, which are exchanged in WPA (WiFi secure access) -enabled networks for security reasons. Further, since Ethertype is indicated by a bit in the header, a new Ethertype can be defined by extending this concept.

B. Virtual BSS ID for emergency calls

In a virtual BSS setup, a single physical AP is configured to operate as more than one BSS (i.e., virtual BSSs), each with its own ID. A BSS ID may be reserved to be used for emergency calls only. Since each MAC frame transmitted in the WLAN contains a BSS ID, an emergency call will use the emergency BSS ID when attempting to transmit the emergency call.

The STA may receive an emergency BSS ID from the AP on the downlink. For example, the emergency BSS ID may be sent by the AP in a response frame (e.g., a probe response, an association response, or a reassociation response). It should be noted that the emergency BSS ID may be provided to the STA in various other methods.

AP or STA advertising its emergency call capability

The AP will advertise its ability and willingness to support emergency calls. For example, the AP may announce that it is enabled for emergency calls and may provide parameters to the STAs to complete the emergency calls by associating with the AP. The advertisement may also include an indication of whether the emergency call capability in the AP is currently active. Such announcements are likely to be used in public hotspots where it is reasonably expected that there are many different types of users.

The AP capability IE may be used in a beacon frame or a probe frame for the AP to indicate its emergency call capability. There is a two byte capability field in the current beacon frame and all bits in this field are used. An extensible capability IE is added at the end of the frame to indicate all new AP capabilities. The above-mentioned bit flag may be added to the extensible capability IE to indicate the emergency call capability of the AP. Further, an emergency call capability indication of the AP may also be added to the reassociation or revalidation frame.

Alternatively, the STA may announce its capability to support emergency calls. This information may include, for example, what type of speech coding the STA is implementing. The STA may add its emergency call capability information to an association request frame, a re-association request frame, an authentication request frame, or a re-authentication request frame. This information can be conveyed either using the new IE or by adding one or more bit flags in the existing IE. One benefit to STAs from announcing their emergency call capabilities is: if the STA must initiate an emergency call, the AP may save this information to more quickly handle the emergency call.

If the STA provides the AP with its emergency call capability, the AP can also know whether its home WLAN can support emergency calls. Not every WLAN has the capability to connect to an emergency call center. For example, the WLAN may be configured as a data collection network (e.g., a factory telemetry network) and may not have an internet connection that allows the STA to connect to an emergency call center. In this case, the AP should inform the STA that the WLAN cannot support the emergency call, so the STA can attempt to locate another WLAN. A similar mechanism may be used in situations where the internet connection of the WLAN is temporarily unavailable for some reason.

D. Location information

In addition to conveying emergency call setup reasons, location information may also be attached in these new MAC frames 200, 250 (e.g., in location information field 266). For example, the AP or STA may use a Basic Service Set (BSS) ID, an AP or STA MAC address, a statically or dynamically assigned IP address, or a Global Positioning System (GPS) system from the AP or STA for implementing such functionality, and forward this information to the emergency call center. It should be noted that the location information may also be transmitted separately from the emergency call information.

Other means for locating emergency STAs include, but are not limited to: the identification of the STA initiating the emergency call by the caller ID, the use of a callback number, and the use of a known address by the emergency call center to help locate the STA (e.g., using the MAC address of the STA's current point of attachment, such as the AP or network ID, or the geographic coordinates of the AP).

For example, the WLAN may use a MAC signaling mechanism in which the AP may request a position fix from the STA. The STA will report its location back to the AP. One possible implementation includes the use of assisted GPS (a-GPS) coordinates, which are currently widely used in cellular handsets. A variety of positioning methods may be supported for different access networks including, but not limited to, uplink time difference of arrival (U-TDOA), enhanced observed time difference (E-OTD), idle period downlink observed time difference of arrival (IPDL-OTDOA), a-GPS, universal geographic coordinates (such as those defined in IEEE standard 802.11k or IETF RFC 3825), and methods that use WLAN AP location, cell site or sector information, and timing advance or round trip time measurements. Although the above examples for communicating location information are specifically mentioned herein, it should be noted by those skilled in the art that any format for communicating geographic coordinates may be used.

The emergency call function may be performed independently of (complementary to) the location reporting function. By way of illustration, here may: (1) attaching location information to emergency call signaling frames when the STA actually issues an emergency call, and (2) signaling location updates as a stand-alone function in the absence of an emergency call. One example of the latter is STA location which is continuously advertised or updated to the AP, either periodically (e.g., every few seconds) polled as part of the AP's background operation, or unsolicited regular locations reported to the AP by the STA. Since the AP already has a reasonable new estimate of the STA's location when the STA issues an emergency call, it is preferable to maintain the location information on the AP so that the STA will not be required to explicitly piggyback its location in the emergency call request.

For example, using such independent STA location information reporting may allow for location-dependent services to be implemented in a WLAN while addressing regulatory requirements.

Also, the location information may also be provided to location services (LCS) applications that exist within an interworking WLAN (I-WLAN), Public Land Mobile Network (PLMN), or STA. Furthermore, the serving cell identity or the serving AP identity of the initiator may also be provided to the LCS client.

E. Extended presence RTS/CTS frame exchange mechanism and procedure

A standard RTS frame 300 is shown in fig. 3. The RTS frame 300 includes a frame control field 302, a duration field 304, a Receiver Address (RA) field 306, a Transmitter Address (TA) field 308, and an FCS field 310.

An STA wishing to transmit an emergency call transmits an extended RTS frame 400 containing a special signaling flag as shown in fig. 4A or an extended RTS frame 450 containing a new IE as shown in fig. 4B.

Fig. 4A shows an RTS frame 400. Fields 402-410 of RTS frame 400 are the same as fields 302-310 of RTS frame 300 described above in connection with FIG. 3. Frame control field 402 has several subfields including a protocol version subfield 412, a type subfield 414, a subtype subfield 416, an arrival Distribution System (DS) subfield 418, a source DS subfield 420, a more fragments subfield 422, a retry subfield 424, a power management subfield 426, a more data subfield 428, a Wired Equivalent Privacy (WEP) subfield 430, and a sequence subfield 432.

A signaling flag may be added in any reserved bits of the RTS frame 400. Possible locations for the reserved bit include a protocol version subfield 412, a type subfield 414, and a subtype field 416. It should be noted that one skilled in the art may place the signaling flag in any reserved bit of the RTS frame 400.

Fig. 4B shows an extended RTS frame 450 and includes, among other things, a frame control field 452, a duration field 454, an RA field 456, a TA field 458, a usage IE460, and an FCS field 462. The usage IE460 may be similar in content to the emergency call IE256 described above. All STAs that receive the extended RTS emergency call IE256 must then stop transmission attempts for a predetermined amount of time to idle the wireless medium and provide transmission opportunities for STAs that are in an emergency condition.

In one embodiment, upon receiving the extended RTS frame, the receiving STA enters a modified back-off process to provide a higher probability of successful medium access for the emergency call initiating STA. Two embodiments of modified rollback processing may be implemented: (1) shorten the back-off time of the STA initiating the emergency call compared to other STAs, or (2) lengthen the back-off time of non-emergency STAs. In either embodiment, the end result is that emergency STAs have shorter back-off times than non-emergency STAs.

A method 500 of using an RTS frame 400 or 450 is shown in fig. 5. The purpose of the method 500 is to leave the transmission medium in an idle state in order to allow the STA to transmit an emergency call. The method begins with the STA initiating an emergency call by sending an RTS frame 400 or 450 (step 502). The AP receives the RTS frame (step 504) and responds to the STA with a standard CTS frame (step 506). The type of backoff to be used by the AP is determined (step 508). There are two types of back-off, and both types of back-off allow an emergency call initiating STA to access the medium before all other STAs wait for transmission.

If the backoff type is that the emergency STA (i.e., the emergency call-originating STA) has a short backoff time, the emergency STA waits for a relatively shortened backoff time (step 510) and then transmits the emergency call (step 512). All other STAs attempting to access the medium will then wait for a standard backoff time (step 514) and can then perform transmission (step 516). The method then terminates (step 518).

If the back-off type is such that all other STAs have a longer back-off time (step 508), the STA in the emergency situation waits for a standard back-off time (step 520) and then transmits the emergency call (step 522). While all other STAs wait for a longer backoff time (step 524) before being able to transmit (step 516). The method then terminates (step 518).

Typically, when a STA enters a backoff procedure, the STA will attempt to transmit in one of a series of N slots. If there is a transmission collision, the STA will back off again and will raise the value of N to a predetermined maximum value of N. A STA must wait M slots before it can attempt to transmit. This basic procedure provides equal opportunity for any STA to win medium access. In 802.11e, to enforce QoS, there are two methods for ensuring that a particular station has a greater chance to win medium access. The first approach is to reduce the value of M, thereby providing a shorter latency for the STA. The second approach is to use a smaller value of N, which increases the chances that the STA will be able to transmit in a particular slot.

There are several possible means in the method 500 for the STA to know the backoff value to use. The first approach is to use the hard-coded values of M and N in conjunction with the emergency call so that these hard-coded values for M and N can be used by STAs in an emergency. The second approach is to explicitly signal the values of M and N from the AP to the STA in an emergency. Typically, the AP transmits these parameters to the STAs through the use of broadcast or dedicated management frames in normal system operation. The STAs read the parameters associated with the emergency call that are used when the STAs need to establish the emergency call. An example of this is: as part of the beacon or probe response management frame, the SAP sends other BSS configuration values to all STAs in its BSS. The process of adding the M and N parameters associated with the emergency call is a natural extension to these processes. For example, today, each access class (back-off value, window, etc.) to be used by all STAs in a BSS has 802.11e QoS related configuration parameters that are signaled by the AP using a similar mechanism.

A third approach is to combine the first and second approaches such that the STA has hard-coded default values of M and N and would normally use the default values, and if the STA is in an emergency, the AP signals new values of M and N to override the hard-coded default values. Furthermore, additional means for delivering appropriate back-off times to STAs in emergency situations and all other STAs attempting to access the medium may also be appreciated by those skilled in the art.

F. For dual mode WLAN STAs (e.g., 3G and WLAN) to host a handoff (mandatedswich-over) to another radio technology

In an emergency situation, the dual mode WLAN STA will first attempt an emergency call over the cellular network instead of the WLAN. In principle, this is a "hard coding" procedure performed exclusively in the STA. A method 600 for implementing this process is shown in fig. 6.

The method 600 begins with a user initiating an emergency call on a STA (step 602). A determination is made as to whether the STA is capable of operating on the cellular network or WLAN (step 604). If the STA is operating on (i.e., currently connected to) the cellular network, the STA remains on the cellular network for the emergency call (step 606). If the STA is capable of operating on the cellular network but is not currently connected to the cellular network, the STA establishes a connection with the cellular network (step 608) and makes an emergency call over the cellular network (step 606). If the STA is operating on the WLAN, the STA will switch to the cellular network for an emergency call (step 610).

After the emergency call is initiated, a determination is made as to whether the emergency call has passed through the cellular network (step 612). If the emergency call passes through the cellular network, the method 600 terminates (step 614). If the emergency call does not pass through the cellular network, the STA switches to the WLAN to initiate the call (step 616) and the method terminates (step 614).

If an emergency call needs to be issued by a dual mode WLAN-cellular handset, then the preferred procedure is to have the handset fall back onto the cellular modem (i.e., establish the emergency call over the cellular radio link) because emergency call support is not necessarily available on the WLAN or its reliability on the WLAN may be low.

An alternative to the method 600 includes: (1) determining a preferred, mandated or recommended radio technology order (e.g., WLAN or cellular) for handover when attempting to send an emergency call; (2) the system operator configures emergency call activity on a SIM card or similar device for the dual mode handset; (3) in an emergency, the VoIP call is held on the cellular network or moved to a conventional circuit switched voice channel; (4) the system operator signals the preferred local order of the radio technologies via the wireless interface; or (5) the user manually configures policy settings.

G. Bypassing authentication and security measures when attempting emergency calls

A procedure is hosted where the AP must allow any 802.xx STAs that attempt to establish an emergency call in the WLAN. This process includes bypassing authentication similar to 802.1x and other security measures of the network segment. This process can be triggered either by using the extended RTS/CTS method 500 (as shown in fig. 5) or by a bit flag, IE, header, reserved information field, or bit/sequence value in the MAC frame (as shown in fig. 2A and 2B).

In the current WLAN implementation, the authentication state of each STA is tracked by means of a state machine and will be referred to as a 1x port filtering process. Only if authenticated, the STA will allow transmission over the WLAN, otherwise it will be intercepted by the port filter. However, a problem arises from an authentication point of view, since the STA initiating the emergency call must be admitted to the WLAN. To overcome this verification problem, the port filter may be adjusted to easily determine when the STA is sending the emergency call and allow the emergency call to proceed. For example, the indication may be provided by incorporating a new ethertype as described above, or by modifying an existing ethertype.

Access control in WLANs is inherently security dependent. In accordance with current standards, there is no way to bypass access control in the AP because all STAs must perform authentication processing to associate with the AP. For the AP, the AP should admit the emergency call even if the STA does not have the proper credentials to associate with the AP. For an AP, it may have two options when identifying an emergency call; and emergency call identification should be performed on L2. The first option is to bypass AP security completely and prepare the call if authentication is required. The second option is to admit calls with different security settings. For example, an emergency call may be provided with a specific emergency related access or security key.

If the AP grants access to the emergency call by bypassing AP security, care should be taken to prevent calls that impersonate the emergency call (e.g., through fraudulent signaling information) from abusing this security-bypassing process. One solution to this problem includes semi-statically routing all emergency calls, thereby automatically routing emergency calls to an emergency call center without providing general access to the WLAN. By using semi-static routing for emergency calls, even spoofed emergency calls are routed to the emergency call center.

WTRU behaviour (behavior)/procedure in emergency

WLAN to help find callers by sending SOS beacon signals

Here a procedure is hosted in the STA or configured by the network, wherein once the emergency call is ended (or even during the emergency call) the STA and/or the involved AP start sending SOS type signaling frames 700 as shown in fig. 7 in regular intervals.

SOS signaling frame 700 is a modified version of the probe request frame. The SOS signaling frame 700 includes a frame control field 702, a duration field 704, a Destination Address (DA) field 706, a Source Address (SA) field 708, a BSSID field 710, a sequence control field 712, an SSID IE714, a supported rates IE716, and an emergency call IE 718. The emergency call IE718 may be the same as the emergency call IE256 described above in connection with fig. 2B. It should be noted that supported rate IE716 is optional and can be removed from SOS signaling frame 700 without affecting its functionality.

In one embodiment, an SOS signaling frame may be defined as a probe request frame transmitted with a short interframe space (SIFS) priority or a priority interframe space (PIFS) in order to secure access to the medium. The SOS signal frame contains new emergency call related elements in the emergency call IE, such as 911ID (e.g., caller ID), device details (e.g., International Mobile Equipment Identity (IMEI)), network join, username, and emergency reason code. The reason code may be obtained by the device by prompting the user to identify the cause of the emergency call (e.g., "if it is a fire alarm press 1", etc.). The reason code provides some capability to handle emergency situations if there is no way to terminate the call in progress.

SOS signal frames may be scheduled for transmission every approximately 10 milliseconds to facilitate location recording and tracking. The AP needs to record any SOS signal frame reception with time stamps and signal details. Signal strength details include signal strength, signal quality, antenna orientation and gain, and caller details such as IMEI, username (if available), and other 802.11 device information that may be used for identification and capability purposes. The AP receiving the SOS signal frames also needs to report the event to an emergency network node responsible for emergency response, radio resource coordination, location, and tracking of calling devices.

This process is an efficient sounding mechanism in which SOS signaling frames will be sent and may be received by emergency personnel upon arrival at the calling party. A similar device is an emergency beacon in the aircraft black box. For this purpose, a new MAC frame may be introduced, and in addition, a new IE (e.g., as the emergency call IE 256) may also extend an existing MAC frame, e.g., a probe request frame, to meet this purpose.

A method 800 of using SOS signaling frames is shown in fig. 8. The user initiates an emergency call from the STA (step 802). The STA starts transmitting SOS frames (step 804). Depending on the intended implementation, the SOS frame may be sent as probe information or may be used to establish a direct connection with emergency personnel (step 806).

If the SOS frame is transmitted as the probe information, a transmission period is set and it is determined whether the end of the transmission period is reached (step 810). If the transmission period has not ended, the STA continues to transmit SOS frames (step 812) and the method returns to step 810. If the end of the transmission period has been reached (step 810), the STA stops transmitting SOS frames (step 814) and the method terminates (step 816).

If an SOS frame is used to establish a direct connection with the emergency personnel (step 806), a determination is made as to whether the emergency personnel is within range of the STA (step 820). If the emergency personnel are not within range of the STA, the STA continues to transmit SOS frames (step 822) and the method continues to step 820. If the emergency personnel are within range of the STA (step 820), the STA stops transmitting SOS frames and a direct connection is established between the caller and the emergency personnel (step 816).

In a first alternative (steps 810-814), the SOS frames transmitted by the STAs may be triggered by signaling from the AP or a higher layer protocol such as Session Initiation Protocol (SIP) once the emergency call ends. The duration/frequency of the SOS frame is obtained in this trigger signal. By sending SOS frames after the emergency call is over, unnecessary SOS frames may be prevented from being transmitted if there is an error in the emergency call or if emergency personnel do not have to respond to the call.

In a second alternative (steps 820-824), a direct VoIP connection is established between the emergency worker and the calling party when the emergency worker and the calling party are within range of each other. Other STAs that hear the SOS frame may process the SOS frame similar to the extended RTS frame described above in connection with fig. 4A, 4B, and 5 (i.e., the other STAs do not attempt to access the medium, and thus the emergency call can better use the bandwidth).

B. Network (e.g., AP) handles emergency calls by performing callback functions

In the call back situation, once the emergency call is established, the WLAN will remain actively connected to the user initiating the emergency call for a certain period of time after the emergency call ends. This functionality may be transparent to the user.

Functionality in infrastructure

A. Proxy functionality

A method 900 for determining whether an AP needs to act as a STA proxy is shown in fig. 9. The STA makes an emergency call (step 902) and the AP receives the emergency call (step 904). A determination is made as to whether the STA has the capability to complete the emergency call based on the network used to transmit the call (step 906). The AP checks whether the STA has all the functions required to support the call (e.g., SIP/h.323 protocol termination, vocoder, etc.). This information may be indicated as part of a MAC frame (e.g., MAC frames 200, 250) or it may be part of subscriber information in the network that the AP may access.

If the STA has all the capabilities required, the STA will proceed with the call normally (step 908). The AP may add location information to the call as needed and this includes the location of the STA and/or the location of the AP (e.g., network ID, MAC address of the AP, etc.) (step 910). The method then terminates (step 912).

If the STA does not have all the capabilities needed to complete the call (step 906), the AP acts as a proxy for the STA, thereby providing any necessary functionality (step 914). The AP adds location information to the call as needed (step 910) and the method terminates (step 912).

If the AP determines that the STA does not have all the capabilities needed to completely complete the emergency call in the current environment, the AP acts as a proxy for the STA (step 914). For example, if the STA does not support the SIP protocol, the AP may act as a SIP proxy for the STA. As another example, if the STA supports SIP but the network only supports h.323, the AP may interwork SIP from the STA with h.323 messages for the rest of the network. In the extreme case, the STA does not even have a vocoder, then the AP can download a thin (thin) vocoder client to the STA and interwork it with the more standard vocoder of the rest of the network. It should be noted that the AP does not have to provide all proxy functionality for the STA; these functions may be provided by other components in the infrastructure network, such as a dedicated gateway node. This provides greater flexibility for the WLAN to handle emergency calls in the event of a WLAN internet connection disruption if the proxy function is moved out of the AP.

Another approach is AP spoofing (i.e., reading content and/or type information, even if not allowed by an authority) about the content of IP packets used for signaling or normal traffic by STAs and their counterparts in the network. For example, SIP signaling protocol messages over IP are commonly used today for call processing. This SIP signaling contains useful information such as capability information and destination address for the AP to perform its role as a proxy. In addition to the previously described methods, the AP may do its role more efficiently if it extracts such information from spoofing about the STA's far end destination's higher layer (i.e., above L2 MAC) message content. Those skilled in the art will appreciate that SIP is one example of a management protocol for IP-based calls, and that other equivalent protocols exist and are widely used in the industry. Thus, this method is not limited to SIP.

B. Establishing a link between an AP and an emergency call center

Once the AP becomes aware of the STA making the emergency call, the AP must establish a link with the emergency call center in order to properly route the call from the STA. There are several possible delivery mechanisms for emergency calls to reach the call center from the AP. For example, the AP may communicate with a gateway, thereby linking the AP to the call center.

The concept of an emergency network node may be extended to include an emergency response operations center with human-in-the-loop capability. The emergency network node may be an Extended Service Set (ESS) or a network suitable for infrastructure applications. For example, in a university campus, the designated emergency network node may be the campus police department. As another example, in a manufacturing plant, the emergency network node would be a security office. The emergency network node may include an operator that receives VoIP calls, records call information, screens calls, and then initiates an emergency call over the Public Switched Telephone Network (PSTN) to alert the appropriate authorities.

The concept of an emergency network node can be further extended to include an automatic node with a direct line to the PSTN. The automation node will act as a voice circuit bridge to place calls and connect wireless callers to the PSTN emergency center.

The method for connecting to an emergency network node may be extended to include the ability to route and process calls without authentication, authorization or security features. This allows a direct unencrypted or channelized connection between the wireless caller and the emergency network node.

The functionality of the emergency network node may be extended to include call processing, call handover and roaming coordination. This feature pre-authorizes resources in neighboring APs (APs adjacent to the AP serving the wireless call) so that the caller can roam without losing wireless connection and without re-establishing a new emergency call when moving past the AP boundary, thereby eliminating duplicate calls for the same emergency. In one embodiment, a MAC frame containing the emergency IE as described above may be used, whereby after completing the handover, the new AP may continue the emergency call without interruption.

Interworking network

Network interworking, which involves how network-side components interact, is also very important in emergency call handling, especially in cases where emergency calls must be completed across different network types. One solution to this problem is to indicate the emergency call capability of a new subscriber when it enters the system. This new user information is used to update a centralized database so that if the user initiates an emergency call, the information is easily used and the latency otherwise required because the information must be exchanged across networks to complete the call is reduced. As with the location information, the emergency call capability information may be automatically updated in the background so that the updated information is constantly provided.

Examples

1. A method for supporting emergency calls in a wireless local area network, the method comprising the steps of: an Access Point (AP) advertises its emergency call capabilities.

2. The method of embodiment 1 wherein the step of advertising includes providing an indicator that the AP is capable of receiving the emergency call; and providing parameters to enable a station initiating an emergency call to configure itself to deliver the emergency call to the AP.

3. The method of embodiment 1 wherein the advertising step includes periodically transmitting the emergency call capability of the AP using beacon frames.

4. The method of embodiment 3 wherein the beacon frame includes an extensible capability information element containing the emergency call capability of the AP.

5. The method of embodiment 1, wherein the step of advertising comprises: the probe response frame is used to convey the emergency call capability of the AP.

6. The method of embodiment 1, wherein the step of advertising comprises: the association response frame is used to convey the emergency call capability of the AP.

7. The method of embodiment 1, wherein the step of advertising comprises: the reassociation response frame is used to convey the emergency call capability of the AP.

8. The method of embodiment 1, wherein the step of advertising comprises: the authentication response frame is used to convey the emergency call capability of the AP.

9. The method of embodiment 1, wherein the step of advertising comprises: the re-authentication response frame is used to convey the emergency call capability of the AP.

10. A method for supporting emergency calls in a Wireless Local Area Network (WLAN) according to any of the preceding embodiments, the method comprising the steps of: a station announces an emergency call capability of the station to an Access Point (AP).

11. The method of embodiment 10, wherein the announcing step comprises: the information element is used to convey the emergency call capability of the station.

12. The method of embodiment 10, wherein the announcing step comprises: the emergency call capability of the station is conveyed by adding a bit flag in an existing information element.

13. The method of embodiment 10, wherein the announcing step comprises: an association request frame is used to convey the station's emergency call capabilities.

14. The method of embodiment 10 wherein the announcing step includes transmitting the station's emergency call capabilities using a reassociation request frame.

15. The method of embodiment 10 wherein the announcing step includes transmitting the emergency call capability of the station using an authentication request frame.

16. The method of embodiment 10 wherein the announcing step includes transmitting the emergency call capability of the station using a re-authentication request frame.

17. The method of embodiment 10, further comprising the steps of: emergency call capability of a station is maintained at a location on the WLAN accessible to any device.

18. The method of embodiment 17 wherein the saving step allows network interworking between the WLAN and other network types to support emergency calls.

19. A method for supporting emergency calls in a Wireless Local Area Network (WLAN) according to any of the preceding embodiments, the method comprising the steps of: initiating an emergency call by a station on the WLAN; receiving, by an Access Point (AP) on a WLAN, an emergency call; granting, by an AP, an emergency call without requiring a station initiating the emergency call to perform an authentication procedure required by the AP to grant other calls; and providing emergency call related settings to the station to allow the station to access the WLAN.

20. The method as in embodiment 19 wherein the emergency call related settings comprise an emergency call access code.

21. A method according to claim 19 or 20, wherein the emergency call related settings comprise an emergency call security key.

22. A method of supporting emergency calls in a Wireless Local Area Network (WLAN) according to any of the preceding embodiments, comprising the steps of: initiating an emergency call by a station on the WLAN; receiving, by an Access Point (AP) on a WLAN, the emergency call; admitting the emergency call by the AP without requiring the station initiating the emergency call to perform an authentication procedure required by the AP to admit other calls; and routing the emergency call to an emergency call center.

23. The method of embodiment 22, wherein the step of routing comprises performing semi-static routing to route all emergency calls to an emergency call center.

24. A method for supporting emergency calls in a Wireless Local Area Network (WLAN) according to any of the preceding embodiments, the method comprising the steps of: providing an emergency Basic Service Set (BSS) identifier to a station, the emergency BSS identifier being for emergency calls only; and initiating an emergency call by the station, wherein the emergency call includes an emergency BSS identifier.

25. The method of embodiment 24, wherein the providing step comprises: the station is provided with an emergency BSS identifier in a probe response frame.

26. The method of embodiment 24, wherein the providing step comprises: the station is provided with an emergency BSS identifier in an association response frame.

27. The method of embodiment 24, wherein the providing step comprises: the emergency BSS identifier is provided to the station in a reassociation response frame.

28. A method for supporting emergency calls in a Wireless Local Area Network (WLAN) according to any of the preceding embodiments, the method comprising the steps of: initiating an emergency call by a station on the WLAN; receiving, by an Access Point (AP) on a WLAN, the emergency call; determining whether the station has sufficient capability to complete the emergency call; and if the station does not have sufficient capability to complete the emergency call, causing a component in the infrastructure network to act as a proxy for the station.

29. The method of embodiment 28 wherein the component in the infrastructure network comprises a dedicated gateway node.

30. The method of embodiment 28 or 29, further comprising the step of: the infrastructure network component adds the location information to the emergency call.

31. The method of any of embodiments 28-30, further comprising: a component in the infrastructure network monitors traffic on the WLAN to make the component in the infrastructure network aware of capability information of the station on the WLAN so that the component in the infrastructure network can act as a proxy for the station.

The inventive concept can be extended beyond the specific embodiments described above. For example, the present invention may be extended to mesh networks and ad-hoc (ad-hoc) networks. The emergency call capability described herein may be implemented in any part of the network and is not limited to APs. These capabilities may be implemented in the STA, distributed via several APs, or in an access controller or call server, for example.

Alternatively, the invention can be extended to inter-machine application scenarios in addition to human users, in order to handle emergency situations using WLAN. One possibility is to use 802.11 in a home security system, i.e. to use WLAN instead of a hardwired telephone line (which can be cut). In this example, instead of a human user being used to make WLAN emergency calls, the home security system will automatically make an emergency call to the security call center upon the intrusion of a person. Alternatively, as described above, the home security system may start transmitting the emergency SOS frame.

Although the features and elements of the present invention are described in the preferred embodiments in particular combinations, each feature or element can be used alone (without the other features and elements of the preferred embodiments) or in various combinations with or without other features and elements of the present invention.

Claims (16)

1. An Access Point (AP), the AP comprising:

a receiver configured to receive an association message including a Basic Service Set Identification (BSSID) from a Station (STA); and

a processor configured to determine whether the BSSID received in the association message is associated with a security credential and authorize access by the STA to the AP based on the security credential, wherein the access is limited to emergency calls.

2. The AP of claim 1, further comprising:

a transmitter configured to transmit an indication of emergency call capability of the AP.

3. The AP of claim 1, further comprising:

a transmitter configured to transmit an indication of an emergency call capability of an active AP.

4. The AP of claim 3, wherein the transmitter is configured to transmit the indication in an extended AP capability Information Element (IE).

5. The AP of claim 3, wherein the transmitter is configured to transmit the indication in an extended AP capability Information Element (IE), wherein the AP capability IE is greater than two bits in length.

6. A Station (STA), comprising:

a transmitter configured to transmit an association message comprising a Basic Service Set Identification (BSSID), wherein the BSSID is associated with a security certificate; and

a receiver configured to receive access to an AP, wherein the access is limited to emergency calls.

7. The STA of claim 6, wherein the transmitter is further configured to transmit a request frame to request an emergency BSSID, and wherein the receiver is configured to receive a response frame indicating the emergency BSSID.

8. The STA of claim 7, wherein the request frame is a probe request frame, an association request frame, or a reassociation request frame.

9. A method for use within an Access Point (AP), the method comprising:

receiving an association message including a Basic Service Set Identification (BSSID) from a Station (STA);

determining whether the BSSID received in the association message is associated with a security certificate; and

authorizing access by the STA to the AP based on the security credentials, wherein the access is limited to emergency calls.

10. The method of claim 9, further comprising:

transmitting an indication of emergency call capability of the AP.

11. The method of claim 9, further comprising:

an indication is transmitted of the emergency call capability of the active AP.

12. The method of claim 11, wherein the indication is transmitted in an extended AP capability Information Element (IE).

13. The method of claim 11, wherein the indication is transmitted in an extended AP capability Information Element (IE), wherein the AP capability IE is greater than two bits in length.

14. A method for use within a Station (STA), the method comprising:

transmitting an association message comprising a Basic Service Set Identification (BSSID), wherein the BSSID is associated with a security certificate; and

receiving access to an AP, wherein the access is limited to emergency calls.

15. The method of claim 14, further comprising:

transmitting a request frame to request an emergency BSSID; and

receiving a response frame indicating the emergency BSSID.

16. The method of claim 15, wherein the request frame is a probe request frame, an association request frame, or a reassociation request frame.