doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 1 WLANs for Public Access: Activities in ETSI BRAN Author: Robert Hancock/Stephen McCann Siemens/Roke Manor Research, U.K

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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…)

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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)

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 4 Goals, Scope, and Organisation

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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?

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 6 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 /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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.)

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 9 Organisation of Work in ETSI Technical Report 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 /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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)

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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)

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 12 ETSI Technical Report (Published: August 2001) Loose and Tight Coupling Status and Conclusions

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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)

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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)

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 18 The Tight Coupling Architecture Similar interface methodology to UTRAN Can extend to very seamless UTRA-H/L2 handover (dual mode terminals)

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 21 ETSI BRAN TS Development for Release 1 (work in progress) Reference Architecture Functions, Protocols and Interfaces Open Issues in AAA

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 22 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)

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 23 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

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 24 Reference Architecture – Interfaces – I

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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)

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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!)

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 31 Future Developments Mobility and QoS Functions Other Standards

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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)

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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)

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 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)

doc.:IEEE /107r0 Submission Robert Hancock/Stephen McCann, Siemens/RMR January 2002 Slide 41 Integrating other WLAN Standards ETSI work comes in two parts 1.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