Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
IEEE 802.1aq wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Distributed firewall wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Computer network wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Airborne Networking wikipedia , lookup
• IEEE 802.21 MEDIA INDEPENDENT HANDOVER • DCN: IEEE802.21-04-0164-02-0021 • Title: Optimal Beacon & Architecture for MIH • Date Submitted: Jan. 10, 2005 • Presented at IEEE 802.21 in Monterey, CA • Authors or Source(s): Michael Hoghooghi, Karl Heubaum, Jeff Keating, Dan Orozco, Michael Lee • Freescale Semiconductor, Inc. • Abstract: This contribution aims to facilitate MIH services for mobile nodes & networks able to support multiple protocols while adhering to the requirements of the IEEE802.21 WG. 21-04-0164-02-0021 Slide 1 Freescale Semiconductor, Inc. Hoghooghi, et al • • • IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.21. The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual <http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html> 21-04-0164-02-0021 Slide 2 Freescale Semiconductor, Inc. Hoghooghi, et al IEEE802.21 – Media Independent Handover Optimal Beacon & Architecture for MIH Freescale Semiconductor, Inc. DCN: IEEE802.21-04-0164-02-0021 Michael Hoghooghi Karl Heubaum Jeff Keating Michael Lee Dan Orozco 21-04-0164-02-0021 Slide 3 Freescale Semiconductor, Inc. Hoghooghi, et al Overview • Considerations for mobility and HO • MIH-WG TRD & Selection Criteria Recommendations MIH recommendation – geared for MIH & IEEE Link metrics for MIH Mandatory v. optional & items Network detection v. selection v. selection-support? MN v. Net-Controller services or measurements – capability advertising • Higher layer functions for HO & service engines • Responses to comments from San Antonio review • Scope matrix & MIH call flow • Summary 21-04-0164-02-0021 Slide 4 Freescale Semiconductor, Inc. Hoghooghi, et al MIH Req’t. from TRD (Based on v.12, 21-04-0087-12-0000) • TRD & Down Selection Process (DCN: 21-04-200-00) will be used on evaluation of proposed solutions for the standards draft • Each MN will be multi-mode to be MIH capable • Security algorithms & protocols are out-of-scope for MIH specification • Functions supported thru L2: net-detection, net-selection, seamless HO • Application classes based on ATM/UMTS classifications systems RT, delay-sensitive, delay insensitive, best-effort, RT loss-tolerant, soft-RT loss-sensitive, lossless assured-delivery, loss-tolerant non-RT. • 802.21 to enhance user experience by supporting seamless HO in heterogeneous networks w/ MoIP for session or service continuity • HO service support between: 802.11/15/16 & cellular standards 802.20 may also be supported as well as single 802.11 crossing multiple ESS • Provide means of obtaining QoS information for ea. network involved in HO HO policy to be flexible by providing for session continuity, if desired HO policy will not be defined in specification • Net-discovery supported above LLC thru reliable MAC/PHY indications (events) • Power Management – support bat-efficient net-scanning procedures 21-04-0164-02-0021 Slide 5 Freescale Semiconductor, Inc. Hoghooghi, et al MIH Req’t. from TRD (con’t.) (Based on v.12, 21-04-0087-12-0000) • MIH function & arch – just below the IP layer & is uniform across bearer types Can use info from L2 (trigger events, hints, access to info on alt-net) Include inputs from user-policy & configuration influence HO process Define generic interfaces from MIH to L3 – MoIP & SIP, for example • Event indication – triggers – defines Link layer events Requirement for events Event transport Event grouping • Info Services (IS) elements supported Link access Parameters Security Mechanisms Neighbor Maps Location Provider & Other Access Info Cost of Link 21-04-0164-02-0021 Slide 6 Freescale Semiconductor, Inc. Hoghooghi, et al Transport Protocol & MIH Function (Based on v.12, 21-04-0087-12-0000) • No restrictions on use of any transport protocol to exchange MIH function events between STA Fn-Entity & Net Fn-Entity Mgmt L3 App Mgmt MIHSignaling MIHFunction L3 App MIHFunction MAC LLC Function PHY MACFunctions(802.xx) 802.yy PHYFunction(802.xx) PHY 802.yy MACFunction(802.xx) LLCFunction PHYFunctions(802.xx) Station Functional Entity 21-04-0164-02-0021 MAC Data Network Functional Entity Slide 7 Freescale Semiconductor, Inc. Hoghooghi, et al Recommendations for Mobility • Architectural partitioning & main modules All modules per MIH function & signaling – per TRD Differentiate between Network HO & Device HO Net-Detect – per existing specifications Net-Support – per existing specifications Protocol impact – per MIH specification Link metrics – per recommendations & service engine options Specify MIH signaling, link metrics reporting, etc. • HO scenarios Class-1: Both MN & Network are MIH capable Follows HO procedures as recommended, when possible or needed Class-2: MN is MIH but Network is not More likely scenario for mobile-initiated HO, where applicable Class-3: MN is non-MIH but Network is More likely scenario for network-initiated HO, where applicable Class-4: Neither is MIH – legacy and existing systems – no HO 21-04-0164-02-0021 Slide 8 Freescale Semiconductor, Inc. Hoghooghi, et al HO Scenarios MN Network MN Controller MIH Network Controller Comments Network MN Controller Network Controller Non-MIH MN Class-1 Class-2 Class-3 Class-4 Full HO capability Device-initiated HO Network-initiated HO Legacy & existing systems today. No HO MN – Mobile Node Network Controller – AP, BSC, BTS, etc. 21-04-0164-02-0021 Slide 9 Freescale Semiconductor, Inc. Hoghooghi, et al Option-1: MIH Recommendations for Mobility & HO • Important mobility enablers Network capability ID – modified Beacon (MIH-Beacon) Best fit in the native protocol - Control Channel concept in a broadcast mode – fits into existing protocols and may vary one to another protocol, in placement Minimal protocol impact with optimized channel utilization and spectral efficiency. Device-initiated move – link metrics (L3) & L1-2 reporting Independent of legacy systems – works w/ legacy regardless. Billing, tariffs, GoS, etc. – per existing protocols – no change to protocols Security – use existing and not reinvent Link security – AAA, certificates, trust mechanisms, etc. Higher layer protection – DRM (content protection) QoS classifications – per TRD PS modes (battery-efficient net scanning, low-power modes, etc.) Policy engines – Out of Scope – implementation items 21-04-0164-02-0021 Slide 10 Freescale Semiconductor, Inc. Hoghooghi, et al Connection Analysis • Use existing protocols as native-modes • Only 2 new elements introduced BSC-1 • Leverage MoIPv6 • No change to other elements Cellular BTS BSC-2 Rely on existing net/link security mechanisms Service engines are implementation specific .... BSC-n STA-1 AN HTTP Server BSC STA-2 Internet AP-1 STA-n FTP Server STA-1 .... PDSN AP-2 STA-2 Ethernet STA-n Video Server AP-n 21-04-0164-02-0021 Slide 11 Freescale Semiconductor, Inc. Hoghooghi, et al Logical HO Views • All traffic types & payload converge on the ether level – follow MoIPv6 rules Home-Adr, c/o-Adr, subnet fields, etc. • Service engine plays a big role on Fast-HO Enables native & non-native traffic flows Net-controller can harmonize, when needed >> MoIP addressing over Ethernet . ... . MAC-xx MAC-xx MAC-yy MAC-zz PHY-xx PHY-xx PHY-yy PHY-zz 21-04-0164-02-0021 Slide 12 Freescale Semiconductor, Inc. Hoghooghi, et al MIH-Beacon Options 1. Network & MN to broadcast MIH-beacon Periodic broadcast Beacon contains MIH capabilities of network & MN Alternatively, network to broadcast MIH capability-flag ONLY 2. MN to scan for networks in background 3. MN will recognize that network is MIH capable MN will query network for detailed MIH capabilities This process could also be done (in reverse) for MN MN decide when want to roam onto a new network Exchange basic capabilities with network during registration Capabilities exchange during registration process MN advertise neighbor networks Periodic broadcast of networks heard Resolve concerns on battery life, contention, and BW 21-04-0164-02-0021 Slide 13 Freescale Semiconductor, Inc. Hoghooghi, et al Preferred MIH Beacon Option Prefer Opt-1: network to broadcast MIH beacon • Periodic broadcast Beacon contains MIH capabilities of network Modifications needed to protocol New management message (or other appropriate frame) to indicate MIH beacon – communicate MIH capabilities New data type to define capabilities, per recommendations 21-04-0164-02-0021 Slide 14 Freescale Semiconductor, Inc. Hoghooghi, et al MIH Network Selection Example Scenario 1. Upon power-up (or association), MN scans for MIH beacon Scan MN native mode first then proceed to other modes, if needed Immediately register in native mode, if available 2. If receive beacon from multiple networks, determine and track network types – could use influence from service engine, etc. 3. MN needs to determine primary function 4. Adherence to service engine rules to determine network selection Link metrics will influence decision to associate, or not Register with that network 21-04-0164-02-0021 Slide 15 Freescale Semiconductor, Inc. Hoghooghi, et al Content of MIH Beacon Message MAC Header • QOS Level APPL CLASS (4 Bits) (4 Bits) NET-TYPE Carrier ID (4 Bits) (32 bits) TRUST CAPACITY EXTENDED LEVEL (4 Bits) SERVICES (4 Bits) CRC (4 Bits) Optimization methods MIH-Capability (MIHC) flag TRUE or FALSE (1 bit), for example Most spectrally efficient option If MIHC is true, several options may be implemented MN could query the network for additional details or share its capability info Capability IS may also be shared via some form of flexible (XML?) and permissions – as an example of implementation Service engine may perform the lookup to get MIH details i.e. each field maps to a lookup table for decode New fields to consider: MoIP-ver (2 bits), location (relative or absolute), device/user preferences, etc. If MIHC flag is not set, there may be other options for the MN It could still register with the network Send its visiting net info to its native net along with routing Service engine could determine association or other options 21-04-0164-02-0021 Slide 16 Freescale Semiconductor, Inc. Hoghooghi, et al MIH Field Content • MIH capability information field or service (IS) Mandatory v. optional IS Include mandatory & optional fields – provision for growth flexibility Mandatory classifications: Net-type, QoS class, tariff/free, carrier-ID, trustlevel, capacity, extended services, and link metrics Optional fields: Expansion Net-types, data rates, capacity, extended services support, home Net-member, security grade, nomadic support, etc. Adopt a common set for MIH 21-04-0164-02-0021 Slide 17 Freescale Semiconductor, Inc. Hoghooghi, et al Conceptual Steps in HO Network advertising MIH capability – common criteria 1. a. b. 2. Based on MIH beacons w/ link IS Satisfies service engine requirements or enhances it L2 querying its associated L1 for link metrics a. b. c. 3. L2 knows relevant/preferred services Can differentiate in-service HO, from keeping-tabs, etc. May all be initiated by the service engine L1 reporting of relevant parameters a. b. c. Link quality and connection type Metrics reporting – per agreed upon list Continuously, or on an as-needed basis, periodically? L2 (or other higher entity) determines suitability for HO – 2 options 4. a. b. 5. Device requesting HO – user initiated Network requesting HO – carrier initiated HO negotiations and eventual transfer a. b. Maintenance of service & associated performance Maintenance of appropriate service grade, billing agreements, etc. 21-04-0164-02-0021 Slide 18 Freescale Semiconductor, Inc. Hoghooghi, et al Steps in HO (con’t.) • Many options can be developed for this HO • Example probe/response flow Alternate Network to MIH Net Controller to MN, etc. Alt-Net 21-04-0164-02-0021 Net-xx Network Controller Net-xx MN (1) Slide 19 Net-xx MN (2) ... Freescale Semiconductor, Inc. Net-xx MN (n) Hoghooghi, et al San Antonio Comments • Why MoIP-v6? Both versions of MoIP are viable within this proposal We can (if required) provision for the MoIP-version field within the information or capability exchange fields – upon association, etc. MoIPv6 clarifies and enhances MoIP-v4 Most importantly it has provisions for direct sharing of the subnet addressing optimizing other-than home agent transactions • Is the MIH-Beacon part of the bootstrap sequence? Generally, yes. There may, however, be other reasons for sharing this more frequently, if needed. • What could be communicated in fields containing: Net-Type, Carrier-ID, Trust-Level? Already addressed during the presentation Other examples could be provided based on regional, applications, user profiles or service engine preferences – but do not wish to discuss implementation-specific items in the WG. 21-04-0164-02-0021 Slide 20 Freescale Semiconductor, Inc. Hoghooghi, et al Capability Advertising Who advertises this information and how frequently is it done? • MIH-Beacon information may be exchanged by the network controller only during association with the MN • Or, it may be exchanged more frequently and periodically – in this case MN may choose to look for this only when required, or it may choose to batterysave otherwise • Neighboring networks advertised Network controller (assuming it is MIH capable) will share this information MIH capable MN may periodically scan for supported protocols and report results to network controller or the service set This ability distributes the detection burden (power & time) Extends beyond network boundaries (if left only to network controller) Does not affect non-MIH MN 21-04-0164-02-0021 Slide 21 Freescale Semiconductor, Inc. Hoghooghi, et al Heterogeneous Network Example • Device HO based on movement • 4 different networks, as an example Ethernet MN GSM Cellular WLAN IEEE802.16 Mobile & Fixed CDMA Cellular 21-04-0164-02-0021 Slide 22 Freescale Semiconductor, Inc. Hoghooghi, et al Metrics & Behaviors Revisited • Indicators for link quality Combination of PHY/MAC (L1/L2) parameters RSSI, SNR, PER/BER/FER/BLER, highest PHY data rate supported, PHY type, power management modes, RTS threshold, service priority, frame size & spacing, fragmentation status, location information (relative or absolute), retry of un-ACK frames, RTS/CTS, management and control frames, metric about capacity or population (# of MN), nominal beacon intervals, etc. Some of these may be normalized w/ application or service Not every element may be available or appropriate for reporting across all network types – some basic set will be mandatory, others may be service engine specific and optional 21-04-0164-02-0021 Slide 23 Freescale Semiconductor, Inc. Hoghooghi, et al Event & Link Triggers • Signal strength (RSSI) • Authorized MIH Capable Force to leave network roamed to, if needed Pay for feature access • BER • Network billing cost • CINR/SNR • User-selected preferences • QoS • Applications Bit rate Voice quality Jitter Bandwidth availability Traffic congestion • MIH Preferences Roam priority i.e. Home, .11, .16, etc. 21-04-0164-02-0021 Slide 24 Freescale Semiconductor, Inc. Hoghooghi, et al MIH Logical Stack Interfaces Application Mobility Mgmt - User Preferences - Net. operation preference - Applications LLC MIH Mobility Management Convergence MAC 802.X/3GPP MIH Handover Control PHY 802.X/3GPP MIH Physical Convergence 21-04-0164-02-0021 Slide 25 Freescale Semiconductor, Inc. Hoghooghi, et al MIH Block Within the Stack Mobility Mgmt Application - User Preferences - Net. operation preference - Applications MIH Mobility Management Convergence MIH Handover Control Mobility Events LLC MIH MIH Physical Convergence MAC Events MAC 802.X/3GPP PHY Events PHY 802.X/3GPP 21-04-0164-02-0021 Slide 26 Freescale Semiconductor, Inc. Hoghooghi, et al Event & Link Triggers Trigger Name Source Destination MIH.MOB.COST MIH.MOB.ROAM_PRIO MIH.MOB.USER MIH.MOB.APPL MIH.MAC.NETWORK MIH.MAC.QoS MOB MOB MOB MOB MAC MAC MIH Mobility Mgmt Conv MIH Mobility Mgmt Conv MIH Mobility Mgmt Conv MIH Mobility Mgmt Conv MIH Handover Control MIH Handover Control PHY PHY PHY MIH Phys Conv MIH Phys Conv MIH Phys Conv Bit rate Voice quality Jitter Bandwidth allocation Traffic congestion MIH.PHY.RSSI MIH.PHY.BER MIH.PHY.CINR 21-04-0164-02-0021 Slide 27 Freescale Semiconductor, Inc. Hoghooghi, et al MIH Call Flow Multimode STA HL MIH Function MIH Mobility Conv Old Point of Attachment LL LL MIH Function New Point of Attachment HL LL MIH Function Local Trigger HO Rqst MIH HO Control MIH PHY Conv Beacon Message Handover association request and SS basic parameters Query current network Obtain subscriber details Handover grant Activate on new network 21-04-0164-02-0021 Slide 28 Freescale Semiconductor, Inc. Hoghooghi, et al HL MIH Layer Interactions 1. Triggers come in MIH Mobility Management Convergence 2. Process triggers 3. MIH Handover Control 2. Process triggers 5. Handover request 4. Handover functions performed to determine handover feasibility, etc. MIH Physical Convergence 3. 2. Process triggers 21-04-0164-02-0021 Slide 29 Freescale Semiconductor, Inc. Hoghooghi, et al HO Triggering Parameters Parameter RSSI Data Rate QoS Cost Security (L2) Battery Power Peer Group Controlling Entity Device/User Network Service Provider √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ √ • Above table serves as an example for the considerations • It provides 3 views potentially triggering HO • The final list parameters may vary slightly based on Link & Event Triggers and, possibly, other metrics to be agreed upon (location, movement speed, rate of signal or QoS change, etc.) • Other factors are NOT shown in this table (weighting, priority, etc.) 21-04-0164-02-0021 Slide 30 Freescale Semiconductor, Inc. Hoghooghi, et al Media Independent Handover Proposal Scope Matrix for Discussion Part-I Core Elements Event Service Information Service MIHO Support MIH Reference Model 802.3 to/from 802.X 802.3 to/from 3GPP 802.3 to/from 3GPP2 802.X to/from 802.Y 802.X to/from 3GPP 802.X to/from 3GPP2 - Addressed - Addressed - Addressed - Addressed - Addressed - Addressed - Addressed - Addressed - Addressed - Addressed - Addressed - Addressed 21-04-0164-02-0021 - Addressed Network Discovery Other Elements Transport Special HL Security Support Schema QoS Schema Other - Addressed - Addressed - Addressed - Addressed - Addressed - Addressed - Addressed - Addressed - Addressed - Addressed - Addressed - Addressed - Addressed - Addressed - Addressed Slide 31 Freescale Semiconductor, Inc. Hoghooghi, et al Media Independent Handover Proposal Scope Matrix for Discussion Part-II MIHO Support 802.3 to/from 802.X 802.3 to/from 3GPP 802.3 to/from 3GPP2 802.X to/from 802.Y 802.X to/from 3GPP 802.X to/from 3GPP2 21-04-0164-02-0021 Station Initiated – Station Controlled Architectural Precepts of the Proposal Station Initiated – Network Initiated – Network Controlled Station Controlled - Supported - Supported - Supported - Supported - Supported - Supported - Supported - Supported - Supported - Supported - Supported - Supported - Supported - Supported - Supported - Supported - Supported - Supported - Supported - Supported - Supported - Supported - Supported - Supported Slide 32 Network Initiated Network Controlled Freescale Semiconductor, Inc. Hoghooghi, et al Summary • Provided additional updates to our initial proposal • Added new elements for link & event triggers • Addressed comments raised in the Nov-04 meeting • We see a great deal of potential with several contributions for harmonization and will explore opportunities to do so by/before the March meeting 21-04-0164-02-0021 Slide 33 Freescale Semiconductor, Inc. Hoghooghi, et al