Transcript - IEEE Mentor

January 2002
doc.:IEEE 802.11 02/107r0
WLANs for Public Access:
Activities in ETSI BRAN
Author:
Robert Hancock/Stephen McCann
Siemens/Roke Manor Research, U.K
[email protected]
Submission
Slide 1
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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)
Submission
Slide 2
This presentation can be
converted to standard format &
provided to IEEE if desired
(and administratively
possible…)
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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)
Submission
Slide 3
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
Goals, Scope, and Organisation
Submission
Slide 4
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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?
Submission
Slide 5
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
Public Access in General
N
• ‘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
Submission
Slide 6
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
R'99 UMTS
Also,
alternative
directions for
other mobile
standards
(CDMA etc.)
UMTS
3G
tighter
2/3G
Any operator
with an HLR
Any
operator
looser
• 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
Submission
Slide 7
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
Submission
Slide 8
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
Organisation of Work in ETSI
• Technical Report 101 957 published
August 2001
ETSI (European Telecommunications
Standards Institute)
Project BRAN (Broadband
Radio Access Networks)
– “Requirements and Architectures for
Interworking between
HIPERLAN/2 and 3rd Generation
Cellular systems”
– Major cosmetic update expected
• Technical standard in development
Hiperlan/2 area
3G Interw orking
TR WI (closed)
– 2 phased approach, R1 and R2
– Both due to complete in 2002
3G Interw orking
TS WI
Submission
Slide 9
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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)
Submission
Slide 10
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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)
Submission
Slide 11
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
ETSI Technical Report
(Published: August 2001)
Loose and Tight Coupling
Status and Conclusions
Submission
Slide 12
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
Submission
Slide 13
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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)
User
Control
Loose Coupling IWF
Submission
IP/Ethernet/1394
IP/Ethernet/1394
R-DLC
R-DLC
R-PHY
R-PHY
Slide 14
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
In the simplest case the
NAI Centric IWU may
not exist.
Diameter/RADIUS is used to
communicate with the AAAH
in the core network.
NAI Centric
IWU
AAAL
HLR
Authentication
Information
User traffic
Router
(U)SIM Centric
IWU
MAP
Core Network
AP
User traffic
MT
NAI Centric scenario
MT does not have (U)SIM card functionality therefore the
IWU is used to inter-operate with the core network AAAH.
(U)SIM Centric scenario
MT has (U)SIM card functionality therefore the IWU will be
used to inter-operate with the core network AAAH or HLR.
Internet
Submission
AAAH
Diameter/RAD
HIPERLAN/2
Slide 15
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
Submission
Slide 16
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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)
Submission
Slide 17
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
The Tight Coupling Architecture
GGSN
SGSN
SGSN
SGSN
Iuhl2
Iu
Iurhl2
AP
Iurhl2/utr
IWU
IWU
Iubhl2
Iubhl2
AP
AP
RNC
Iub
AP
NODE
B
Uuhl2
• Similar interface
methodology to
UTRAN
• Can extend to very
seamless UTRA-H/L2
handover (dual mode
terminals)
NODE
B
Uu
dual
mode
mobile
Submission
Slide 18
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
Submission
Slide 19
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
Submission
Slide 20
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
ETSI BRAN TS Development for Release 1
(work in progress)
Reference Architecture
Functions, Protocols and Interfaces
Open Issues in AAA
Submission
Slide 21
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
Reference Architecture - Topology
Home Network
•
AP
MT
•
HIPERLAN/2
Network
Internet
AP
'Transit' Network
W1
W2
•
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)
Wn
Visited Network
• 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
Submission
Slide 22
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
Reference Architecture - Protocols
SIM
UICC
credentials
MT
Application
AP/AP Control
User Plane
Network
Stack
Authenticator
Home
Network
AP
Control
Part
Radio L1/L2 Function
•
HN
Control
Part
Interworking
Note the nearly
independent:
–
Radio L1/L2 Function
Remote Netw ork
RLC
1
CL
2
RLC
3
L
M
E
DLC
PHY
1
DLC
PHY
CL
2
L
M
E
W1
User Traffic /
Call Control
–
Application
3
User Plane
Network
Stack
User Plane
Network
Stack
W2
H/2 Control
User Plane
Network
Stack
•
user part (CLdependent protocol
stack)
Control part (located
in home network)
Could share the same
route through part of
the transit network
Wn
Interfaces for
discussion
• 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.)
Submission
Slide 23
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
Reference Architecture – Interfaces – I
Lr
User Data
Forwarding Function
AP/AP Control
Er
Network Mobility
Function
AP Control Part
CN Control Part
Lm
Management
Agent
Network
Manager
Em
Location
Provision
Function
El
MT
User Credential
Storage
Network Stacks
M+Q
Ms
Location
Target
Function
Authenticator
Epl
M+Q
Lp
Policy
Enforcement
M+Q
M+Q
RLC
RLC
Epu
User&Network
Policy Decision
CL
Epa
La
Resource
Monitor
Iha
Radio L1/L2 Function
Eal
Epn
Ihp
Ipa
CL
Ll
Location
Server Function
Network Stacks
Application
Esl
Ea
Accounting
Function
Eps
Radio L1/L2 Function
Ls
Attendant
Local
Authenticator
Es
Logical Control Flow
Ihs
User Data Flow
Network
Handover
Support Function
Interface
Lh
W1
Submission
Slide 24
W2
Wn
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
Submission
Slide 25
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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)
Submission
Slide 26
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
Submission
Slide 27
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
–
–
–
–
Submission
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!)
Slide 28
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
Submission
Slide 29
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
Submission
Slide 30
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
Future Developments
Mobility and QoS Functions
Other Standards
Submission
Slide 31
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
Submission
Slide 32
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
Submission
Slide 33
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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)
Submission
Slide 34
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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)
Submission
Slide 35
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
Submission
Slide 36
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
Submission
Slide 37
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
Submission
Slide 38
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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
Submission
Slide 39
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
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)
Submission
Slide 40
Robert Hancock/Stephen McCann, Siemens/RMR
January 2002
doc.:IEEE 802.11 02/107r0
Integrating other WLAN Standards
•
ETSI work comes in two parts
1.
2.
•
‘Upper layer’ people (operators, OS makers) care mainly
about some parts of (1)
–
•
•
•
Protocols/reference point specifications (L & M)
Changes to radio layers or AP implementation to support them
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
Submission
Slide 41
Robert Hancock/Stephen McCann, Siemens/RMR