freescale semiconductor, inc. hoghooghi, et alslide 121-04-0164-02-0021 ieee 802.21 media...

21-04-0164-02-0021 Freescale Semiconductor, Inc. Hoghooghi, et alSlide 1

• 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.


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>


IEEE802.21 – Media Independent HandoverOptimal Beacon & Architecture for MIH

Freescale Semiconductor, Inc.DCN: IEEE802.21-04-0164-02-0021

Michael Hoghooghi

Karl Heubaum

Jeff Keating

Michael Lee

Dan Orozco


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


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


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


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

MAC Function (802.xx)

PHY Function (802.xx)

MIH Function

MAC Functions (802.xx)

PHY Functions (802.xx)

Station Functional Entity Network Functional Entity

PH

Y

MA

C

PH

Y

Data L3 App

MIH Signaling

LLCFunction

MIH Function

LLC Function

Mgmt L3 AppMgmt

MA

C

802.

yy

802.

yy


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


HO Scenarios

MN Network

Controller

MN Network

Controller

MN Network

Controller

MN Network

Controller

MIH

Non-MIH

Comments Class-1

Full HO capability

Class-2

Device-initiated HO

Class-3

Network-initiated HO

Class-4

Legacy & existing systems today. No HO

MN – Mobile NodeNetwork Controller – AP, BSC, BTS, etc.


Option-1: MIHRecommendations 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


Connection Analysis

• Use existing protocols as native-modes

• Only 2 new elements introduced

• Leverage MoIPv6

• No change to other elements Rely on existing net/link security mechanisms Service engines are implementation specific

HTTP Server

FTP Server

Video Server

. . . .

InternetInternet

Cel

lula

r B

TS

AN BSC

PDSN

Ethernet

BSC-1

BSC-2

BSC-n

. . . .

AP-n

. . .

AP-1

STA-1

STA-2

STA-n

. . .

AP-2

STA-1

STA-2

STA-n

. . .


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

MAC-xx

PHY-xx

MAC-zz

PHY-zz

MAC-yy

PHY-yy

> >. ... .

MAC-xx

PHY-xx

MoIP addressing over Ethernet


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

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

2. MN to scan for networks in background MN decide when want to roam onto a new network Exchange basic capabilities with network during registration Capabilities exchange during registration process

3. MN advertise neighbor networks Periodic broadcast of networks heard Resolve concerns on battery life, contention, and BW


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


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 Adherence to service engine rules to determine network selection Link metrics will influence decision to associate, or not

4. Register with that network


Content of MIH Beacon Message

TRUST

LEVEL

(4 Bits)

Carrier ID

(32 bits)

NET-TYPE

(4 Bits)

APPL CLASS

(4 Bits)

QOS Level

(4 Bits)

MAC Header

EXTENDED

SERVICES

(4 Bits)

CRCCAPACITY

(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


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, trust-

level, 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


Conceptual Steps in HO

1. Network advertising MIH capability – common criteriaa. Based on MIH beacons w/ link IS b. Satisfies service engine requirements or enhances it

2. L2 querying its associated L1 for link metricsa. L2 knows relevant/preferred servicesb. Can differentiate in-service HO, from keeping-tabs, etc.c. May all be initiated by the service engine

3. L1 reporting of relevant parametersa. Link quality and connection typeb. Metrics reporting – per agreed upon listc. Continuously, or on an as-needed basis, periodically?

4. L2 (or other higher entity) determines suitability for HO – 2 optionsa. Device requesting HO – user initiatedb. Network requesting HO – carrier initiated

5. HO negotiations and eventual transfera. Maintenance of service & associated performanceb. Maintenance of appropriate service grade, billing agreements, etc.


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.

MIH-Beacon

Net Controller Query to MN

MN response to Net Controller

Net Controller handshake

w/ Alt-net

MN handshake w/ Alt-net

Alt-Net Net-xxNetwork Controller

Net-xxMN (1)

Net-xxMN (2)

Net-xxMN (n)...

Net Controller nego w/ MN


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.


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 battery-save 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


Heterogeneous Network Example

• Device HO based on movement

• 4 different networks, as an example

WLAN GSMCellular

IEEE802.16Mobile & Fixed

CDMACellular

Eth

ern

et MN


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


Event & Link Triggers

• Signal strength (RSSI)

• BER

• Network billing cost

• CINR/SNR

• QoS Bit rate Voice quality Jitter Bandwidth availability Traffic congestion

• MIH Preferences Roam priority

i.e. Home, .11, .16, etc.

• Authorized MIH Capable Force to leave network roamed

to, if needed Pay for feature access

• User-selected preferences

• Applications


MIH Logical Stack Interfaces

Application

LLC

MAC 802.X/3GPP

PHY 802.X/3GPP

MIH Mobility Management Convergence

MIH Handover Control

MIH Physical Convergence

Mobility Mgmt- User Preferences- Net. operation preference- Applications


MIH Block Within the Stack

Application

LLC

MAC 802.X/3GPP

PHY 802.X/3GPP




Mobility Mgmt- User Preferences- Net. operation preference- Applications

MIHMobility Events

MAC Events

PHY Events


Event & Link Triggers

Trigger Name Source DestinationMIH.MOB.COST MOB MIH Mobility Mgmt Conv

MIH.MOB.ROAM_PRIO MOB MIH Mobility Mgmt Conv

MIH.MOB.USER MOB MIH Mobility Mgmt Conv

MIH.MOB.APPL MOB MIH Mobility Mgmt Conv

MIH.MAC.NETWORK MAC MIH Handover Control

MIH.MAC.QoS MAC MIH Handover ControlBit rateVoice qualityJitterBandwidth allocationTraffic congestion

MIH.PHY.RSSI PHY MIH Phys Conv

MIH.PHY.BER PHY MIH Phys Conv

MIH.PHY.CINR PHY MIH Phys Conv


MIH Call FlowOld Point of AttachmentMultimode STA New Point of Attachment

HL MIH Function LL LL HLMIH

Function LL HLMIH Function

MIH Mobility Conv

MIH HO Control

MIH PHY Conv

HO Rqst

Local Trigger

Beacon Message

Handover association request and SS basic parameters

Query current network

Obtain subscriber details

Handover grant

Activate on new network


MIH Layer Interactions




1. Triggers come in

2. Process triggers

4. Handover functions performed to determine handover feasibility, etc.

3.

3.

5. Handover request

2. Process triggers

2. Process triggers


HO Triggering Parameters

Controlling Entity Parameter Device/User Network Service Provider RSSI √ √ √ Data Rate √ √ √ QoS √ √ √ Cost √ √ √ Security (L2) √ √ Battery Power √ Peer Group √

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


Media Independent Handover Proposal Scope Matrix for Discussion Part-I

Core Elements Other Elements MIHO

Support MIH Reference Model

Event Service Information Service

Network Discovery

Transport Special HL Support

Security Schema

QoS Schema

Other

802.3 to/from 802.X

- Addressed - Addressed - Addressed - Addressed - Addressed

802.3 to/from 3GPP

- Addressed - Addressed - Addressed - Addressed

802.3 to/from 3GPP2


802.X to/from 802.Y


802.X to/from 3GPP

- Addressed - Addressed - Addressed - Addressed

802.X to/from 3GPP2



Media Independent Handover Proposal Scope Matrix for Discussion Part-II

Architectural Precepts of the Proposal MIHO

Support Station Initiated – Station Controlled

Station Initiated – Network Controlled

Network Initiated – Station Controlled

Network Initiated - Network Controlled

802.3 to/from

802.X

- Supported

- Supported - Supported - Supported

802.3 to/from 3GPP

- Supported - Supported - Supported - Supported

802.3 to/from 3GPP2


802.X to/from 802.Y


802.X to/from 3GPP


802.X to/from 3GPP2



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

freescale semiconductor, inc. hoghooghi, et alslide 121-04-0164-02-0021 ieee 802.21 media...

Documents