doc.:ieee 802.11 02/107r0 submission robert hancock/stephen mccann, siemens/rmr january 2002 slide 1...

doc.:IEEE 802.11 02/107r0

Submission Robert Hancock/Stephen McCann, Siemens/RMR

January 2002

WLANs for Public Access:Activities in ETSI BRAN

Author:Robert Hancock/Stephen McCann

Siemens/Roke Manor Research, [email protected]

doc.:IEEE 802.11 02/107r0


January 2002

Overview

• Who am I

• Goals: Scope of ‘Public Access’– What are we trying to achieve (and what not)

• ETSI TR: Interworking options & architectures– Loose & tight coupling, flavours and implications …

• ETSI TS: Reference architecture and R1 issues– Functions, interfaces, and protocols

– Open points relating to security

• Future Activities– Integrating mobility and QoS support

– Integrating other standards

• Conclusions (sort of)

This presentation can be converted to standard format & provided to IEEE if desired (and administratively possible…)

doc.:IEEE 802.11 02/107r0


January 2002

Who am I?

• I work for Siemens (Roke Manor Research), based in Romsey, U.K.

• I work in networks (not radios) research and standardisation– IETF, ETSI, various other activities

• I don’t (can’t) represent ETSI or any working group within it, nor does this presentation

• However, this is an attempt to be a non-partisan overview of what is going on– In any case, I will have to defend it at the next 3GIWG meeting

(next week)

doc.:IEEE 802.11 02/107r0


January 2002

Goals, Scope, and Organisation

doc.:IEEE 802.11 02/107r0


January 2002

Goals, Scope and Organisation of Work

Actually the hardest set of questions

• What does ‘public access’ mean?

• How is it possible?– [Too many ways]

• Who is involved?– I.e. what is the scope of any particular standards activity?

• When do we want it?

• What attributes should a standard have?

doc.:IEEE 802.11 02/107r0


January 2002

Public Access in General

• ‘User-centred’ view: data access in public places in similar manner to office / home environment, and the same [organisational] way we use cellphones today– Use the same data equipment in any place– Utilise the same type of data services in any place– High data rates at reasonable prices, simple provider relationships– BUT with the security and charging capabilities of a public network

• No restrictions [at this stage] on approach

N

doc.:IEEE 802.11 02/107r0


January 2002

Possible Approaches• We want access to some sort of ‘public network’• Loosely, classify against two extremes:

– Re-use WLAN radio layer within existing public network– Deploy public network services on WLAN network

• The ‘tight’ approaches are more specific, complex, functional– (And disruptive to existing standards)

• The ‘loose’ approaches don’t rule out operators falling into the more specific categories

• Large number of options causes problems in organisation

Also, alternative directions for other mobile standards (CDMA etc.)

tighter

R'99 UMTS UMTS 3G 2/3GAny operatorwith an HLR

Anyoperator

looser

doc.:IEEE 802.11 02/107r0


January 2002

Who is involved?

• ETSI owns Hiperlan/2

• MMAC owns HiSWANa– Agreement on joint working towards common standard

• 3GPP owns UMTS– SA group 1 started service scenario analysis

– Various liaison statements exchanged up to now

• IETF owns several key network standards ‘in the middle’– EAP, Diameter, COPS, maybe Mobile IP etc.

• IEEE, WECA, 3GPP2 …

• Overlaps are likely and need to be managed

doc.:IEEE 802.11 02/107r0


January 2002

Organisation of Work in ETSI

ETSI (European TelecommunicationsStandards Institute)

Project BRAN (BroadbandRadio Access Networks)

Hiperlan/2 area

3G InterworkingTR WI (closed)

3G InterworkingTS WI

• Technical Report 101 957 published August 2001– “Requirements and Architectures

for Interworking between HIPERLAN/2 and 3rd Generation Cellular systems”

– Major cosmetic update expected

• Technical standard in development– 2 phased approach, R1 and R2

– Both due to complete in 2002

doc.:IEEE 802.11 02/107r0


January 2002

When do we want it?• There are short and long-term targets

• ETSI BRAN 3GIWG is aiming at a minimal interoperable standard for the ‘access network boundary’ to be stable in Q1/2002– Will allow attachment and charging, not much else

– Many, many more details to come…

• Further phases for mobility, QoS ‘end 2002’ [tbd!]

• 3GPP SA1 will generate feasibility report 06/2002– No further timeplan available

• Basic IETF standards already available, extensions will be needed (takes time to reach RFC)

doc.:IEEE 802.11 02/107r0


January 2002

Design Goals

• What sort of standard is wanted?• Functional requirements can be met in many different ways – need

design goals to choose between optionsCaveat: never formally discussed or agreed

• Try for standard protocols or simple adaptations of them• Minimise the impact of the standard on the user traffic• Minimise the number of optional custom features in the normative part

– adapt the ‘core’ network just once• Don’t constrain the implementation at the network edge• Allow adaptation to the particular scenario in mind (if several off the

shelf options work, allow all of them)• Don’t tie the standard to any one core/home network type or user

traffic types (one AN may support many providers)

doc.:IEEE 802.11 02/107r0


January 2002

ETSI Technical Report(Published: August 2001)

Loose and Tight Coupling

Status and Conclusions

doc.:IEEE 802.11 02/107r0


January 2002

TR Structure & Content

• Ultra-high-level requirements statement

• Two basic approaches, considered mainly independently– Each has its own independently derived requirements

– Strong overlap in overall system requirements, but totally different function splits

– Main emphasis on IP services

• ‘Loose coupling’ approach (IETF AAA focus)

• ‘Tight coupling’ approach (UMTS RAN focus)

• Hybrid approaches also possible

doc.:IEEE 802.11 02/107r0


January 2002

The Loose Coupling Approach

• Defines a ‘control plane only’ convergence layer

• Handles primarily AAA issues– Could authenticate using SIM or based on NAI (issue of

Hiperlan/2 security – changes needed)

– Focus is on security and roaming support

– Intra-network mobility and QoS are handled in ‘user plane’ convergence layer (whichever you like)

Control

R-DLC

IP/Ethernet/1394

Loose Coupling IWF

User

R-PHY

R-DLC

IP/Ethernet/1394

R-PHY

doc.:IEEE 802.11 02/107r0


January 2002

The Loose Coupling Architecture

• The only new interface defined is AP-AAAL

• Semantics are defined for Hiperlan/2 control plane authentication messages– Option of a new intermediate layer

HIPERLAN/2

APRouter

AAAL

AuthenticationInformation Core Network

AAAH

Diameter/RADIUS is used tocommunicate with the AAAH

in the core network.

User traffic

MT

Internet

(U)SIM CentricIWU

NAI CentricIWU

NAI Centric scenarioMT does not have (U)SIM card functionality therefore theIWU is used to inter-operate with the core network AAAH.

(U)SIM Centric scenarioMT has (U)SIM card functionality therefore the IWU will beused to inter-operate with the core network AAAH or HLR.

User traffic

MAP

In the simplest case theNAI Centric IWU may

not exist.

Diameter/RADHLR

doc.:IEEE 802.11 02/107r0


January 2002

Loose Coupling: Implications

• Applicable to many different public core networks• Separate local routing of user traffic into ‘content network’

has major implications for function split– Access network has a stronger interest in AAA aspects– More control flows between access and core networks– Direct traffic feed (e.g. over GTP for UMTS) deep into mobile core still

theoretically possible

• Access network and core network may be owned/operated by different organisations– Implications for user identifier formats and privacy– Roaming is a key issue – may be many hot spot network operators,

few service providers

doc.:IEEE 802.11 02/107r0


January 2002

The Tight Coupling Approach

• Investigation restricted to UMTS (mainly R’99/R4)

• Hiperlan/2 becomes a ‘peer’ RAN to UTRAN– Similar status to GERAN for GSM/GPRS

– Re-use many UMTS functions as is (e.g. idle mode?)

• Covers the complete security/mobility/QoS problem, using UTRA-like internal model

• Retains UMTS Iu interface, mainly unmodified

• Whole family of new Hiperlan/2 related interfaces– Iurhl2, Iubhl2 – network internal

– Uuhl2 – extensions or changes to ETSI BRAN W.1 (air interface protocols) (mainly in RLC layer)

doc.:IEEE 802.11 02/107r0


January 2002

The Tight Coupling Architecture

• Similar interface methodology to UTRAN

• Can extend to very seamless UTRA-H/L2 handover (dual mode terminals)

IWU RNC IWU

GGSN

SGSN SGSN SGSN

dual mode mobile

AP AP AP AP NODE B

NODE B

Iu Iuhl2

Iurhl2/utr Iurhl2

Iub Iubhl2 Iubhl2

Uu Uuhl2

doc.:IEEE 802.11 02/107r0


January 2002

Tight Coupling: Implications

• Strong dependencies on what mobile network considered– Even on UMTS release number (R4, R5, whatever)

• Strong dependencies on WLAN technology

• Simpler AN functionality – CN does much more of the work

• Significantly greater impact on WLAN and non-WLAN standards (apparently)– Re-engineering of one to fit into the assumptions of the other

doc.:IEEE 802.11 02/107r0


January 2002

Summary of TR Scope of TS

• Two basic approaches exist and understood

• Working assumption is to concentrate on loose coupling for R1– Decisions made should not rule out tight coupling later

• Architectural work continues looking for unified methods with very different protocol structure– Not clear if this is possible and ‘to what’ tight coupling should be

considered

– Not clear if/how to handle multiple WLAN technologies and multiple core network architectures

– Updates to TR certain in any case

doc.:IEEE 802.11 02/107r0


January 2002

ETSI BRAN TS Development for Release 1(work in progress)

Reference Architecture

Functions, Protocols and Interfaces

Open Issues in AAA

doc.:IEEE 802.11 02/107r0


January 2002

Reference Architecture - Topology

• The main focus is the W.2 interface– W.1 already defined by BRAN, changes requested

• Goal to minimise customisation at home network– Aim for standard protocols, standard transport at W.n

• The ‘transit’ network is transparent to user data, but may need interworking for control plane data into the home network

• Shows user access to IP services, other options possible

• There may be several home networks and several visited networks (all of different types)

Internet

Home Network

HIPERLAN/2Network

'Transit' Network

AP

AP

MT

W1 W2

Visited Network

Wn

doc.:IEEE 802.11 02/107r0


January 2002

Reference Architecture - Protocols

• Shows scope of existing (Radio L1/2) and new work– Most, possibly all changes/additions outside radio L1/2

• Some implications in MT (mobile terminal)• “Call control” is transparent and not considered (just an app.)

• Note the nearly independent:

– user part (CL-dependent protocol stack)

– Control part (located in home network)

• Could share the same route through part of the transit network

User Traffic /Call Control

H/2 ControlInterfaces for

discussion

LME

MT AP/AP Control

Radio L1/L2 Function

APControl

Part

HomeNetwork

HNControl

Part

W1 W2

LME

CL1 32

DLC

PHYPHY

User PlaneNetwork

Stack

DLC

CL1 32

Application

RLC RLC

Authenticator

Wn


SIMUICC

credentials User PlaneNetwork

Stack

User PlaneNetwork

Stack

Remote Network

Application

User PlaneNetwork

Stack

Inter-working

doc.:IEEE 802.11 02/107r0


January 2002

Reference Architecture – Interfaces – I

WnW1 W2Lh

Ihp

ManagementAgent

ErLr

CN Control Part

EmLm

ElLl

LocationTarget

Function

AP Control Part

NetworkHandover

Support Function

Ipa

Ihs

Iha

EaLa

Epa

EsLs

Lp

Attendant

ResourceMonitor

LocationServer Function

PolicyEnforcement

Epl

Epn

Epu

NetworkManager

User&NetworkPolicy Decision

Network MobilityFunction

AP/AP Control

M+Q

CL


RLC

Net

wor

k S

tack

s

M+Q

CL

User CredentialStorage

MT

Authenticator


RLC

Application

Ms

Netw

ork Stacks

M+Q

M+Q

AccountingFunction

Eal

LocalAuthenticator

LocationProvisionFunction

Esl

User DataForwarding Function

Logical Control Flow

User Data Flow

Interface

Eps

doc.:IEEE 802.11 02/107r0


January 2002

Reference Architecture – Interfaces – II• Methodology is to define protocols at interfaces

• Three basic types shown– Internal: implementation dependent (very wide variety of implementation

approaches possible)

– M/Lx: will partly be defined normatively by TS, aim to base on standard protocols

– Ex: to be used unaltered informatively by TS, to explain integration into core networks• Informative appendices will explain how to map the Lx of ETSI to an Ex of

another body (e.g. 3GPP)

• Appendices contributed according to individual interests

doc.:IEEE 802.11 02/107r0


January 2002

Reference Architecture – Interfaces – III• Main interfaces as follows

– Ms – Reference point (only) at which user authentication data is transferred to communications layers

– Ls – Protocol for exchanging authentication data between access and home networks (required for R1)

– La – Protocol for reporting accounting data to home network (minimal version required for R1)

– Lp – Protocol for transferring policy information to access network (authorisation may be required for R1)

– Lm – Network management protocol (out of scope, may not even cross W.2)

– Lh – Protocol for context transfer at handoff (R2 only)

– Ll – Protocol for handling location information (R2)

– Lr – User plane protocols including mobility support (may depend on protocols above radio L1/2)

doc.:IEEE 802.11 02/107r0


January 2002

Security Issues: EAP

• Working assumption to use EAP– Replaces existing Hiperlan/2 protocols

– Provides derived requirements for Ms and Ls interfaces• Working assumption: Ls will be Diameter based, may require extended

application

• Method for transport of EAP over W.1 is open– Working assumption of extension to H/2 control plane

– Comparison with EAPOL – similar, not identical

• Support for SIM/USIM authentication required by 2G/3G operators– But also required that this is not the only mechanism

– AKA extension (i-d) for mapping 2G/3G messages to EAP

– Re-use of GPRS GMM/SM signalling also possible in this scenario

doc.:IEEE 802.11 02/107r0


January 2002

Security Issues: Key Distribution

• Hiperlan/2 uses Diffie-Hellman locally

• Key exchange must be authenticated to prevent active attacks

• Logically ‘similar’ to authenticated key distribution problem for symmetric encryption

• Not handled by core EAP/AAA unfortunately– EAP AKA is one possibility

– Pre-challenge to Hiperlan/2 service provider (user independent)

– EAP interleave

– draft-simon-radius-key-attr-00.txt (16/1/02!)

doc.:IEEE 802.11 02/107r0


January 2002

Security Issues: User Identifiers

• Roaming / multiple home network support requires structured user identifier

• User identity in EAP should be in NAI format

• Issue of disclosure of permanent identity over the air or to visited network– e.g. EAP AKA uses IMSI, regarded as ‘sensitive’

– Requirements are not clear at this stage

• Direct re-use of GSM/UMTS mechanisms appears not possible (under consideration)– Different deployment scenarios cause new problems

doc.:IEEE 802.11 02/107r0


January 2002

Accounting and Charging for R1

• System level requirements essential for R1:– Basic access/session (pay by subscription)– Access/session duration– Credit card access/session/ Not real time pre paid– Calendar and time related charging – Duration dependent charging– Flat rate– Volume of transferred packet traffic – Multiple rate charge

• Useful features– Rate of transferred packet traffic (Vol/sec). – Toll free (like a 0800 call)– Premium rate access/session – Real time Pre-paid

• Still undergoing analysis for impact on AN

doc.:IEEE 802.11 02/107r0


January 2002

Future Developments

Mobility and QoS Functions

Other Standards

doc.:IEEE 802.11 02/107r0


January 2002

Mobility Approaches

• Distinguish very carefully between:• Roaming – assumed handled by ‘security bit’

– Same applies to other ‘service mobility’ aspects, e.g. use of SIP or Dynamic DNS to build mobility on top of nomadic access

• Intra-hiperlan-handover – assumed handled by convergence layer– Loose coupling – left open (basically ‘easy’) or at least not

Hiperlan/2 specific– UMTS Tight coupling – there will be NBAP/RNSAP-like

protocols and much UMTS CN functions re-used– Use of MIP remains an option for ‘macro-mobility’ (but mainly

transparently)

• Hiperlan/2 – 3G handover – which is a nightmare

doc.:IEEE 802.11 02/107r0


January 2002

Inter-System Handover Issues

• Inter-system handover is a very hard problem– cf. corporate case– Weakly supported in loose coupling case

• Basically network reselection by terminal• Terminal has to accept that it will get a new IP address with

implications for session continuity

– Possible in tight coupling case but very hard• Iurhl2 very complex and interacts strongly with existing equipment• Main gain comes from joint management of the radio resource (but

main pain also)

– MobileIP is always a fall-back (and near-transparent)– Affects only multi-mode terminals anyway– Need in public environment needs to be examined

doc.:IEEE 802.11 02/107r0


January 2002

Inter-System Handover [Backup I]

• Need to distinguish between ‘layers’ of mobility

• 1. User/personal – ‘I’ can attach to any network and use services and be contacted– Related to roaming, address allocation, registration, allocation of

personal identifiers (e.g. numbers, URLs)

• 2. Terminal/host – ‘my terminal’ sees the same service as it (physically) moves around (e.g. from one basestation to another)– Typically handled (in current cellular networks) by radio specific

procedures (within the RAN) with a possible layer of inter-RAN but still cellular specific procedures above them (e.g. GPRS)

doc.:IEEE 802.11 02/107r0


January 2002

Inter-System Handover [Backup II]

• How to maintain 1 while you are doing 2 between different networks (e.g. networks of different operators) – very hard to map user service down to specific access technology

• This is the nightmare of 2 slides back

• Mobile IP or other ‘higher layer’ solutions (SIP) are generally easiest – Low performance not too much of a problem

– Solutions are highly generic and make very few assumptions about access network (just that they provide IP access)

doc.:IEEE 802.11 02/107r0


January 2002

Inter-System Handover [Backup III]

• Mobile IP can do both in a so-so way– ‘home’ IP address can be permanently bound to a user (more

typically, still access a user via some human readable name, but this is permanently bound to an address)

– ‘foreign’ IP address can be rebound as you move from one basestation to another

– Significant performance problems with current MIP signalling (or, security problems as an alternative)

– Also, danger of assumption of ‘one size fits all’ approach to mobility

• Appropriate local mobility technique to use within the network may depend on access technology, but MIP can’t be adapted easily like this

doc.:IEEE 802.11 02/107r0


January 2002

Conclusion on Mobility

• Mobile IP may be part of the answer

• For Hiperlan/2, Mobile IP is not forced to be the complete answer– Probably vital to allow it as ‘upper layer solution’ e.g. for inter-system

mobility [and not break it for this purpose]

• Several options remain open– Hierarchical MIP/LMM for mobility within network

– Re-use of cellular techniques (adapted GPRS and adapted UTRAN signalling for example)

– Re-use datacoms L2 switching (for IP/Ethernet services)

– Access network specific IP ‘micro’ mobility protocol could be used• Currently left to IRTF to work out how to define the problem

• Market as well as standards bodies will make the final decision

doc.:IEEE 802.11 02/107r0


January 2002

Quality of Service

• If anything, can be even more complex than security and mobility

• Loose coupling approach leaves most options open (similar to current Internet)

• Tight coupling leverages UMTS QoS architecture (TBD if it can be applied directly to Hiperlan/2)

• Need to distinguish carefully:– What the operator wants to do

– What the user wants to do

– What the user’s applications are capable of doing

doc.:IEEE 802.11 02/107r0


January 2002

QoS Part II

• General problem in Internet QoS is that there is no consensus on how applications will signal their QoS requirements or how networks will attempt to satisfy them– Cf. IPv6 flow label discussion in IETF exposed radically divergent

views on how the future Internet will work in this area, NSIS working group equally confused

• WLAN systems don’t currently have much in the way of deployed/usable QoS – Even H/2 can only do this if the convergence layer allows it – only

really for 1394 at the moment

doc.:IEEE 802.11 02/107r0


January 2002

QoS Part III

• However, for WLAN systems to take their place alongside UMTS, QoS differentiation for multimedia services is probably at least a long term requirement

• This has major implications for validation of resource requests (non-repudiatable by user)

• Guarantee of service by the network to the user

• Security and integrity of L2 signalling (if that is the layer that resource requests are made at)

doc.:IEEE 802.11 02/107r0


January 2002

Integrating other WLAN Standards

• ETSI work comes in two parts1. Protocols/reference point specifications (L & M)

2. Changes to radio layers or AP implementation to support them

• ‘Upper layer’ people (operators, OS makers) care mainly about some parts of (1)

– Some are not relevant (Lm, Lh maybe)

• WLAN standards bodies care mainly about (2), which can be matched to (1)

• It is not clear that there is any WLAN standard to which this argument does not apply, but …

• Minimising overall pain would require planning

doc.:ieee 802.11 02/107r0 submission robert hancock/stephen mccann, siemens/rmr january 2002 slide 1...

Documents