May 2006April 2006doc.: IEEE 802.11-06/0616r0doc.: IEEE 802.11-06/0542r1
IEEE P802.11
Wireless LANs
Date: 2006-05-054-04
Author(s):
Name / Company / Address / Phone / email
Stephen McCannEleanor Hepworth / Siemens Roke Manor Research (A Siemens Company) / Roke Manor, Old Salisbury Lane, Romsey, Hampshire, SO51 0ZN, UK / +44 1794 833341146 /
Abstract
The following document provides a quick introduction to the problem referred to as emergency call supportnetwork selection, and explains the motivation behind addressing this problem specifically within IEEE 802.11u, and desirable properties of the solution.
Contents
Introduction
Higher Layer Support
Key Components
Assumptions
System aspects for supporting Emergency Services
Solution Space
Scenarios
Unauthentication Access
Authentication Access
References
Introduction...... 3
Base Case...... 3
More Complex Scenario...... 4
Solution Aspects...... 4
Solution Options...... 4
References...... 5
Introduction
The following document provides a quick introduction to the problem referred to as emergency call supportnetwork selection, and explains the motivation behind addressing this problem specifically within IEEE 802.11u, and desirable properties of the solution.
Background
With the proliferation of VoWLAN capabilities and improvement in WLAN mobility IEEE 802.11 networks are being increasingly used to support Voice calls. Various devices with WiFi capability are now supporting Voice calls and these devices are also required to support Emerency Services, e.g. e911 in North Amreica and e112 in Europe.
Supporting emergency services requires a multi-layer solution with support at various layers. Apart from MAC level access and support for transfer of data between STA and AP with appropriate QoS there is a need to setup the call, conduct call control and management, and use an appropriate standardized audio codec.
Current IEEE 802.11 solutions provide no special handling for emergency services. Currently there are no mechanisms for a user to determine whether an access point can provide any support for emergency services. In order to use a public access point a user must go through the standard authentication process (e.g. EAP-based or UAM) before being able to use the access point for emergency calls. This requires user credentials to be available, and slows down the process of joining the network. Once the user has access to the network, there is no mechanism to prioritise their emergency traffic over that of other users.
Location information may also be required as part of an emergency services solution. However, this is outside the scope of IEEE 802.11u. It is believed that IEEE 802.11k together with IEEE 802.11v are working on this.
There is a need to support these emergency services both when the user has a relationship with the IEEE 802.11 network (credentials to access the network) and also when it does not have any relationship with the IEEE 802.11 network. In the latter case the STA must be able to access the network in unauthenticated state and make an emergency service call. (As a use case consider the example when a user arrives in a new country and needs to make an emergency call where it has no relationship with current network. However all IEEE 802.11 networks (such as enterprise and private networks at home) may not be required to support these emergency services.
Higher Layer Support
It is essential to distinguish between IEEE 802.11 emergency services, and support of higher layer emergency services. By “IEEE 802.11 emergency services” we refer to the direct support in IEEE 802.11 of such services, independently of what solutions are adopted at higher protocol layers.
Within North America, if the user dials “911” in a VoIP application (e.g. SIP based), the VoIP application may simply setup a SIP call, in which case it is transparent to IEEE 802.11. This would result in the establishment of a higher layer emergency service. In other cases, the terminal may react by dropping the connections for the VoIP application, and use the IEEE 802.11 emergency calls solution.
Figure 1: Public Access Architecture
Figure 1 : Enterprise Architecture
Key Components
Three key components of an IEEE 802.11u emergency services solution are:
1)Network selection – determining whether the network provides support for emergency services. There needs to be an indication from the network about it’s ability to support Emergency services. There needs to be an indication for availability of location services (TGk/v), availability of appropriate QoS services (TGe/v), availability of network access in different states (TGu) and availability of a high level entity to manage overall call process (broadcast of appropriate SSPN).
2)Network join – the STA needs to be able to join the network without any user credentials. Network access: The user should be able to access the network and make an emergency call both when it has credentials to access the network (State 3) and also when it does not have credentials to access the network (State 1). In both cases the user should preferably use a common mechanism to initiate the emergency call. It would be preferable if this can be a common access mechanism across different 802 networks such as 802.11, 802.16, etc. as well.
3)Admission control and traffic conditioning – the emergency services traffic needs to be admitted to the network as a high priority, and given appropriate QoS treatment. In addition, the AP needs to limit the use of the emergency service network access to emergency service traffic. The network should provide a mechanism for appropriate QoS capabilities to initiate the e911 call. However for unauthenticated users there needs to be some implementation of rate control to limit the impact of rogue users making crank e911 calls. The possibility of DoS (Denial of Service) attack already exists when supporting emergency services for unauthenticated users and not much can be done about it at the 802.11 level. Other higher layers in the system need to recognize this and take appropriate steps.
4)Fast BSS transition solutions as developed by TGr should contine to apply for all cases under which user makres an e911 call. Solutions developed to support e911 Emergency calling should not impact mechanisms developed by TGr.
Assumptions
A number of assumptions have been made:
1)It is assumed that there is a high layer standardized protocol (or protocol suite) for making emergency calls or using any other emergency services.
2)Any authentication or encryption of the emergency services can occur at the higher layer rather than at the MAC layer.
3)Maintenance of an existing connection is not required when the STA needs to make use of the emergency services. A pre-existing association with the AP could be discarded prior to the emergency call. Typically, in today’s networks supporting emergency services, there is no need and no interest in maintaining the current services and connections, since the priority is on the establishment of emergency services.
4)The access point separates the backhaul of emergency services traffic from other traffic. This may be in the form of a separate physical link, dedicated VLAN, tunnelling protocol, etc.
5)When using the emergency communications access only emergency services can be accessed.
System aspects for supporting Emergency Services
Different signaling systems such as SIP, H.323, etc. can be deployed for supporting emergency calls. Clients can also use different codecs such as G.711, AMR, Skype-like, etc. The access network like IEEE 802.11 by itself cannot ensure that all factors are compatible for the emergency call to actually take place. The client device needs to register with a call manager (SIP agent or some other signaling endpoint) for the call to be placed successfully. The call manager may also verify that an appropriate emergency call is being placed so that appropriate level of resources can be granted to the emergency call.
Base Case
A simple example scenario is illustrated below. A service provider (SSPN1) has deployed a public access WLAN network (PAWLAN) that is open for use by subscribed customers. SSPN1 also has a number of roaming agreements in place that allow subscribers to other service providers (SSPN2-SSPN4) to use the network as well.
Figure 1. Basic Scenario
The issue that needs to be addressed is how to advertise to users that a suitable roaming agreement is in place so that they know that thay are able to use the services provided by this PAWLAN.
Up to now this problem has been addressed by advertising SSPN “point of presence” via the SSID in the beacon and probe response messages, for example the SSID is set to “T-Mobile”. This has lead to the use of virtual APs in many network configurations where different network services are advertised using non-standard semantics applied to the SSID. This approach also relies on users to interpret the information provided in the SSID to select the network that looks like a best fit for the service they would like. In other words manual inspection and interpretation of the SSID is required - automatic SSID selection is not really an option.
The advantage of the above approach is that users select the network based on some hints as to what service the network will provide before initiating an authentication exchange. However, given that it is expected that each service provider operating a PAWLAN hotspot is likely to have tens of roaming partners, the use of current virtual AP implementations cannot wholly solve this problem in a scaleable manner.
Another aspect to this issue is whether users have multiple credentials that they are selecting between (e.g. a subscription to operators X and Y). The network selection mechanism needs to be designed to ensure that users do not need to try every set of credentials against every AP, or that if they do, they can do so quickly.
In addition, the roaming agreement between the Infrastructure SSPN and the other SSPNs may also include policy information that effects the way the traffic is treated in the Hotspot, a very basic example of this is to ensure that user data is being tunnelled to the SSPN core network infrastructure. These aspects of the problem are considered by the SSPN Interface and User Plane clusters.
More Complex Scenario
In addition to the scenario above, it is also likely that networks offering a variety of network services (from private network access to restricted local services, through to public access) will be available at the same location. This overlap can already be seen in current network deployments (for example within a hotel), and the number of PAWLAN hotspots is still on the increase. In effect, you have multiple instances of the base case located in the same area.
Figure 2 outlines the complexity of this scenario, with 3 hotspots being visible to the user:
Hotspot 1 is a private network which offers no PAWLAN services
Hotspot 2 is a public access network, with direct roaming agreements with 15 other service providers, and supports interworking services as defined by 3GPP.
Hotspot 3 is a public access network operated by a service provider who is a member of a particular roaming consortia, but does not offer interworking services.
The user has a subscription with an SSPN that is accessible via hotspots 2 and 3, but selects hotspot 2 as this provides access to the appropriate interworking services.
Figure 2: Selecting between multiple hotspots
This scenario introduces a couple of additional aspects that need to be considered. The first is how to discourage users from attaching to a network that is not offering a public access service, whilst the second is about providing some way to distinguish between public access networks that offer slightly different interworking services (basically an indication of which type of interworking services are available). There has also been some consideration of whether charging information could be usefully made available, but this is not really felt to be feasible.
Solution Space
As discussed in [1], as the earlier various pieces of network selection information are made available, the more optimal the user device behaviour can be made, although with obvious trade-offs about including information in different stages of the user associating and authenticating with the network.
Ideally, however, the goal is to support automated selection of the network based on pre-configured user information that will be suitable for user laptops, PDAs and phones. It is essential that user interaction should be minimised, if the WiFi market intends to grow, whilst the range of hotspot services diversifies. In addition, this process should be relatiavely fast to support fast connection and use of available network services as well as minimising the amount of battery power required.
Automated network selection could be based on all sorts of information about the network, and it can be made arbitrarily complex. However, since the major goal of IEEE 802.11u is actually just to ensure that the user will actually be granted access to the network, the information that is required to be provided (and hence standardisaed) has been limited to:
Indication of roamed partners
Indication of interworking services
Solution SpaceOptions
As in a cellular network, it is proposed that a user can make use of the emergency call service either by using existing credentials, or by using an explicit unauthenticated access mechanism.
One of the security challenges is that the unauthenticated user should not be able to interfere with broadcast traffic of other users, but does need to have broadcast support (for DHCP, ARP, etc).
Scenarios
The solutions described below primarily address the public access hotpot situation. However, consideration has to be made for both enterprise and home scenarios, where emergency call provision may not be required. This may result in an optional standard for the public access hotspot.
There are also some corner case scenarios, such as:
- Public access hotspots, which provide local intranet services only (e.g. airport timetables and departure information), until authentication and payment is received from the user , whereupon full internet use is authorised.
- Enterprise networks which support voice services, but are not connected to a fully blown AAA backend infrastructure. In addition, some operators may not want to tie their emergency call authentication exchange to AAA infrastructure that may be outside of their control - whilst AAA infrastructure has to be reliable, it currently doesn't have strict high availability requirements on it
Unauthentication Access
For the unauthenticated access mechanism there are several candidate techniques:
- Virtual AP (here referred to as “VAP solution”)
One solution to the support of unauthenticated users is for the emergency service to be provided on a separate virtual AP. This means that the emergency user broadcast traffic is separated from that of normal users (and the unauthenticated user does not need their group key). In particular, the solution should ensure that unauthenticated emergency users cannot interfere with the broadcast traffic (such as DHCP, ARP) of other authenticated users.
- Signalling in Association messages (here referred to as “direct signalling solution”)
An alternative to the virtual AP solution is to explicitly signal in the association exchange (direct signalling solution) that the association is being made for the emergency calls service. No authentication (and no 4-way handshake) is performed. The broadcast traffic must then be separately managed for the emergency service user (which is sent unauthenticated in the clear) and the authenticated users (which share a group key).
3.New Ethertype for Emergency Services
The IEEE 802.1x port access entity shall allow data frames using this new Emergency services ethertype to pass through it’s uncontrolled port. Since the uncontrolled port is always open, frames of the emergency call service shall always pass through this port, irrespective of authentication or whether keys are in place or not. Further this mechanism is now scalable across different networks since the same ethertype can be used across different networks.
Authentication Access
Since this scenario implies that the user is already authenticated, a layer 3 session will already be in place, so that end-to-end emergency call services can be provided. Hence it is not required for any standardisation to be put in place within IEEE 802.11 and therefore this scenario can be regarded as out of scope.
In the options below, it is assumed that the PAWLAN network has some means to discover, or be configured with, the appropriate roaming agreement information. There is also a discussion of options provided in [2].
There are a number of options as to how this type of functionality can be supported:
Virtual APs - where they can be used either to:
oAdvertise all operator identities, with one SSID for each. As discussed above, this does not currently have the necessary scaling properties (e.g. typical APs can only support 8 SSIDs)
oProvides access to a walled garden for service discovery, where the user device can attach to an open AP associated with the PAWLAN and use higher layer protocols to discover the required information before disassociating and reassociating with the network proper. This could be potentially quite difficult to deploy in a consistent fashion across many networks and operators.
Discovery pre-authentication – where information can be discovered:
oPre-association: either from beacons/probes or via some other mechanism (data or action frames). This has desirable characteristics in that the information is made available from the start and in (what would be) a standardised manner to the user device upon which automated network selection techniques can be built. It is also possible to determine network characteristics for the different networks in parallel. This will only be suitable if the information exchanged is limited in size and requires a small number of frame exchanges.
oPost-association: similar to the previous case, except PHY features will have been set up correctly during association (so faster data rates and power save modes are available). User devices may end up doing a round robin sequence of associating and disassociating with networks in turn before finding a suitable network, which may take more time.
oEAP [3]: where roaming information is included in part of the EAP exchange at the request of the client. This has similar properties to the post-association approach, except that it also requires the STA to initiate an EAP exchange with the network before the information is discovered.
References
[1] 11-064-0280r01021r0
[2]11-06-0288r0
[3] 11-06-0290r0draft-ietf-eap-netsel-problem-03.txt
[3] draft-adrangi-eap-network-discovery-14
Submissionpage 1Stephen McCann (Roke Manor Research)Eleanor Hepworth.