WLANs for Public Access: Activities in ETSI BRAN

1. WLANs for Public Access:Activities in ETSI BRAN Author: Robert Hancock/Stephen McCann Siemens/Roke Manor Research, U.K robert.hancock@roke.co.uk

2. 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…)

3. 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)

4. Goals, Scope, and Organisation

5. 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?

6. N 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

7. 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.)

8. 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

9. Organisation of Work in ETSI • 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

10. 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)

11. Design Goals • What sort of standard is wanted? • Functional requirements can be met in many different ways – need design goals to choose between options Caveat: 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)

12. ETSI Technical Report(Published: August 2001) Loose and Tight Coupling Status and Conclusions

13. 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

14. 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)

15. 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

16. 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

17. 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)

18. The Tight Coupling Architecture • Similar interface methodology to UTRAN • Can extend to very seamless UTRA-H/L2 handover (dual mode terminals)

19. 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

20. 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

21. ETSI BRAN TS Development for Release 1(work in progress) Reference Architecture Functions, Protocols and Interfaces Open Issues in AAA

22. Reference Architecture - Topology • 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) • 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

23. Reference Architecture - Protocols • 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 • 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.)

24. Reference Architecture – Interfaces – I

25. 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

26. 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)

27. 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

28. 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!)

29. 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

30. 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

31. Future Developments Mobility and QoS Functions Other Standards

32. 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

33. 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

34. 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)

35. 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)

36. 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

37. 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

38. 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

39. 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

40. 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)

41. Integrating other WLAN Standards • ETSI work comes in two parts • Protocols/reference point specifications (L & M) • 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