Architectural Elements of an 802 Handoff Solution

1
Architectural Elements of an 802 Handoff Solution

• David Johnston
• david.johnston_at_ieee.org
• dj.johnston_at_intel.com

2
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

3
Relevant Elements in Network
4
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 N.A. Mechanism defined by other
5
Define new MAC_SAP messagesand/or Management
Control Elements
6
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?

7
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

8
Define Media Independent HO Decision Data
Encapsulation
EG ltbase_descriptorgt ltmedia_typegt802.11lt/media_t
ypegt ltauth_requiredgt ltauth_vendorsgt ipass
boingo lt/auth_vendorsgt ltbackbone_pre_authgt
yes lt/backbone_pre_authgt ltCS_descriptorgt ltty
pegtmIPv6lt/typegt ltaddressgt192.168.0.1lt/addressgt
lt/CS_descriptorgt ltadjacent_basesgt base1 base2
etc. lt/adjacent_basesgt lt/base_descriptorgt

• Pick XML/ASN.1/Other
• Extensible

9
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

10
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

11
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
  inter-working and so render it more generally
  useful
• So liaison with these bodies should be addressed

12
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).
• Its 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

13
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

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

15
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

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