doc.: 802_Handoff_Architecture_Elements_r2 Submission May David Johnston, IntelSlide 1 Architectural Elements of an 802 Handoff Solution David Johnston

doc.: 802_Handoff_Architecture_Elements_r2 Submission May David Johnston, IntelSlide 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

doc.: 802_Handoff_Architecture_Elements_r2 Submission May David Johnston, IntelSlide 3 Relevant Elements in Network

doc.: 802_Handoff_Architecture_Elements_r2 Submission May David Johnston, IntelSlide 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

doc.: 802_Handoff_Architecture_Elements_r2 Submission May David Johnston, IntelSlide 5 Define new MAC_SAP messages and/or Management Control Elements

doc.: 802_Handoff_Architecture_Elements_r2 Submission May David Johnston, IntelSlide 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?

doc.: 802_Handoff_Architecture_Elements_r2 Submission May David Johnston, IntelSlide 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

doc.: 802_Handoff_Architecture_Elements_r2 Submission May David Johnston, IntelSlide 8 Define Media Independent HO Decision Data Encapsulation Pick XML/ASN.1/Other Extensible EG: ipass boingo yes mIPv base1 base2 etc.

doc.: 802_Handoff_Architecture_Elements_r2 Submission May David Johnston, IntelSlide 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 CS Define convergence procedures to enable the encapsulation and transport of HO decision data and possibly other types of information/messages over L3

doc.: 802_Handoff_Architecture_Elements_r2 Submission May David Johnston, IntelSlide 10 Address Security Concerns Security is a complex issue addressed elsewhere (linksec, 802.1x, 802.1aa, , i, 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

doc.: 802_Handoff_Architecture_Elements_r2 Submission May David Johnston, IntelSlide 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

doc.: 802_Handoff_Architecture_Elements_r2 Submission May David Johnston, IntelSlide 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, 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

doc.: 802_Handoff_Architecture_Elements_r2 Submission May David Johnston, IntelSlide 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

doc.: 802_Handoff_Architecture_Elements_r2 Submission May David Johnston, IntelSlide 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)

doc.: 802_Handoff_Architecture_Elements_r2 Submission May David Johnston, IntelSlide 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

doc.: 802_Handoff_Architecture_Elements_r2 Submission May David Johnston, IntelSlide 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.

doc.: 802_Handoff_Architecture_Elements_r2 Submission May David Johnston, IntelSlide 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.