Transcript 00-03-0000-00-0000architecture_elements_r2

May. 2003
doc.: 802_Handoff_Architecture_Elements_r2
Architectural Elements of an 802
Handoff Solution
David Johnston
[email protected]
[email protected]
Submission
Slide 1
David Johnston, Intel
May. 2003
doc.: 802_Handoff_Architecture_Elements_r2
Purpose (of these slides)
• Outline a solution for a handoff
– Details a possible architecture
– Details possible mechanisms
– Provides information on the breadth of scope
necessary to achieve a functioning handoff
specification
– Does not dictate the actual architecture and
methods that a HO TG or WG should adopt
Submission
Slide 2
David Johnston, Intel
May. 2003
doc.: 802_Handoff_Architecture_Elements_r2
Relevant Elements in Network
L3 Network
AR
AP
802.y
AP
802.x
AP
802.x
AR
AR
AP
802.x
AP
802.y
Potential links
802.x
One or more
802 interfaces
Submission
802.y
Mobile Device
y=x | y!=x
Slide 3
David Johnston, Intel
May. 2003
doc.: 802_Handoff_Architecture_Elements_r2
Handoff Cases
Within L2
boundary
Across L2
boundaries (via L3)
802.x – 802.x
Either L1,2 support (eg. .11)
Or No L1,2 support (e.g. .3)
Use L3 mobility aided by L2 to L3
trigger mechanisms
802.x – 802.y
Either Use L2 HO
mechanisms
Or use L3 HO mechanisms
aided by L2 to L3 trigger
mechanisms
Use L3 mobility aided by L2 to L3
trigger mechanisms
802.x - other
Submission
N.A.
Mechanism defined by other
Slide 4
David Johnston, Intel
May. 2003
doc.: 802_Handoff_Architecture_Elements_r2
Define new MAC_SAP messages
and/or Management Control Elements
MAC
MLME
PLME
PHY_SAP
PHY
Submission
MLME_SAP
MAC_SAP
SME
Messages are generic, E.G.:
Link_up
Link_down
Link_event_pre_indication(what,when)
Handoff_request(where, why)
Fetch_base_descriptor(from where)
MAC and PHY implementations determin
mapping to these based on their own
special cases
Pass triggers and/or roaming
decision data through management
interface
PLME_SAP
MAC_SAP Messages
Defined within base MAC
Spec (802.3/11/16)
+
MAC_SAP Messages
Defined within HO Spec
802.x[.y]
Slide 5
David Johnston, Intel
May. 2003
doc.: 802_Handoff_Architecture_Elements_r2
Define L1,2 – L3 Triggers
• This is the primary driver for the group
– To maintain L3 sessions during handoff L2 support is
required eg. TRIGTRAN, SEAMOBY
– Triggers are the underlying mechanism for enabling
seamless handoffs where possible
– Triggers can be generic (link_up, link_down, etc)
• It is the responsibility of an implementation to determine why
and when it would fire a trigger.
• Enables proprietary differentiation in lower layer mechanisms
while maintaining a standard interface
– Could be extensible. Vendor proprietary triggers?
Submission
Slide 6
David Johnston, Intel
May. 2003
doc.: 802_Handoff_Architecture_Elements_r2
Define Handoff Decision Data
• Pre defined information to support handoff
decisions
–
–
–
–
Network vendor
Auth types supported
L3 network media (internet/PSTN/ATM etc)
Etc
• Make it extensible
• Supports proprietary vendor codes/extensions
• Supports playpen data types
Submission
Slide 7
David Johnston, Intel
May. 2003
doc.: 802_Handoff_Architecture_Elements_r2
Define Media Independent HO Decision
Data Encapsulation
EG:
<base_descriptor>
<media_type>802.11</media_type>
<auth_required>
<auth_vendors>
ipass
boingo
</auth_vendors>
<backbone_pre_auth>
yes
</backbone_pre_auth>
<CS_descriptor>
<type>mIPv6</type>
<address>192.168.0.1</address>
</CS_descriptor>
<adjacent_bases>
base1 base2 etc.
</adjacent_bases>
</base_descriptor>
• Pick
XML/ASN.1/Other
• Extensible
Submission
Slide 8
David Johnston, Intel
May. 2003
doc.: 802_Handoff_Architecture_Elements_r2
Define Convergence Procedures
• Q: How would communication between L2
handoff-ing entities occur if they are not on the
same L2 media?
• A: Via a convergence procedure, so say IP could
be used at L3 to transport the information
• Compare with 802.16 CS
• Define convergence procedures to enable the
encapsulation and transport of HO decision data
and possibly other types of information/messages
over L3
Submission
Slide 9
David Johnston, Intel
May. 2003
doc.: 802_Handoff_Architecture_Elements_r2
Address Security Concerns
• Security is a complex issue addressed elsewhere
(linksec, 802.1x, 802.1aa, 802.10, 802.11i, EAP)
• Trying to include security procedure in handoff
specification would hugely expand scope and
conflict with other groups
• But a HO standard must not undermine security
• So the work should include validating that the
standard is compatible with existing 802 security
architecture
– E.G. can 802.1x operate effectively to establish
authentication at a node being roamed to
– Can pre-authentication be triggered to enable more
seamless handoff
Submission
Slide 10
David Johnston, Intel
May. 2003
doc.: 802_Handoff_Architecture_Elements_r2
Liaison Issues
• With an 802 handoff specification in place, non
802 systems have a recipe for inter-working with
802 systems on handoff
• Interested parties include IETF, 3GPP, 3GPP2
• Spec is 802 scope and so should not describe
explicit non-802 procedures
• However consideration of the needs of non-802
systems will allow a specification to be written
that anticipates the needs of non-802 interworking and so render it more generally useful
• So liaison with these bodies should be addressed
Submission
Slide 11
David Johnston, Intel
May. 2003
doc.: 802_Handoff_Architecture_Elements_r2
Implications for a PAR
• An 802 architecture for handoff between heterogeneous
802 media should not affect the existing 802 model for non
mobile systems (mostly 802, 802.1 and 802.2).
– It’s a five criteria issue
– Therefore new mobility procedures must be placed within the
existing 802 architecture.
• New mobility procedures should be necessary only for
devices seeking to achieve mobility through inter-working
with other devices that support the same standardized
mobility mechanisms
• Will not impede existing or future intra-media handoff activities
• Will not impede media specific inter-media handoff (e.g. 802.x to
802.y) defined elsewhere
Submission
Slide 12
David Johnston, Intel
May. 2003
doc.: 802_Handoff_Architecture_Elements_r2
Implications for a PAR
• Must address where in the 802 architecture the
standard could operate
– MAC management and data, upper edge interfaces
– Convergence procedures at top of MAC
• Opportunities for aligning with other standards
groups
– Should be to aid in formation of a 802 only scoped spec
that happens to be aligned with needs of
3GPP/3GPP2/IETF etc.
– Should be in the PAR to legitimize the liaison activity
for the group
Submission
Slide 13
David Johnston, Intel
May. 2003
doc.: 802_Handoff_Architecture_Elements_r2
Implications for a PAR
• What is being handed off is necessary to identify
– The model of layer 2 mechanisms aimed at supporting
layer 3 handoff should be explicitly called out in the
scope
– Limits scope (a good thing)
• Security
– Exclude security procedures from the specification
– Mandate the consideration of the compatibility of the
specification with security standards
– Limits scope (again, a good thing)
Submission
Slide 14
David Johnston, Intel
May. 2003
doc.: 802_Handoff_Architecture_Elements_r2
Implications for a PAR
• Mechanisms (triggers, decision data, interfaces
etc)
– Do not mandate in the PAR.
– TG/WG must consider liaison inputs
– Must enable the correct procedures to be determined by
the WG/TG
Submission
Slide 15
David Johnston, Intel
May. 2003
doc.: 802_Handoff_Architecture_Elements_r2
An example PAR - scope
12. Scope of Proposed Project:
The scope of this project is to define a specification that shall define
standardized mechanisms (for example MIBs) that may be adopted
into 802 physical layer implementations (PHYs) and 802 Medium
Access Control Layer implementations (MACs) so that handoff of
upper layer sessions E.G. TCP/IP sessions, can be achieved between
homogeneous and heterogeneous 802 media types.
Consideration will be made to ensure compatibility with the 802
architectural model.
Consideration will be made to ensure that compatibility is maintained
with 802 security mechanisms. Security mechanisms shall not be
described in the specification.
Submission
Slide 16
David Johnston, Intel
May. 2003
doc.: 802_Handoff_Architecture_Elements_r2
An example PAR - purpose
13. Purpose of Proposed Project:
The purpose of the project is to enable mobile devices to handoff
between 802 networks that may be of different media types. A further
purpose is to make it possible for mobile devices to perform seamless
handoff where the network environment supports it. This will
improve the user experience with mobile devices by improving the
available network coverage through the support of multiple media
types and preventing the interruption of upper layer sessions during
handoff.
Submission
Slide 17
David Johnston, Intel