1 / 17

Architectural Elements of an 802 Handoff Solution

This presentation outlines a solution for a handoff in an 802 network, including possible architecture and mechanisms. It emphasizes the need for defining MAC_SAP messages, handoff decision data, convergence procedures, and addressing security concerns. It also highlights the implications for a PAR and the need for liaison with non-802 systems.

fhughes
Download Presentation

Architectural Elements of an 802 Handoff Solution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Architectural Elements of an 802 Handoff Solution David Johnston david.johnston@ieee.org dj.johnston@intel.com David Johnston, Intel

  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 David Johnston, Intel

  3. Relevant Elements in Network David Johnston, Intel

  4. Handoff Cases David Johnston, Intel

  5. Define new MAC_SAP messagesand/or Management Control Elements David Johnston, Intel

  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? David Johnston, Intel

  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 David Johnston, Intel

  8. 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 David Johnston, Intel

  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 David Johnston, Intel

  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 David Johnston, Intel

  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 David Johnston, Intel

  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). • 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 David Johnston, Intel

  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 David Johnston, Intel

  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 spec • 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) David Johnston, Intel

  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 David Johnston, Intel

  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 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. David Johnston, Intel

  17. An example PAR - purpose 13. Purpose of Proposed Project: The purpose of the project is to enable mobile devices 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. David Johnston, Intel

More Related