Optimal Beacon & Architecture for MIH

woundcallousΗμιαγωγοί

1 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

75 εμφανίσεις

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
1

21
-
04
-
0164
-
02
-
0021


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.

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
2

21
-
04
-
0164
-
02
-
0021

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
>



Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
3

21
-
04
-
0164
-
02
-
0021

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

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
4

21
-
04
-
0164
-
02
-
0021

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

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
5

21
-
04
-
0164
-
02
-
0021

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

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
6

21
-
04
-
0164
-
02
-
0021

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

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
7

21
-
04
-
0164
-
02
-
0021

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

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
8

21
-
04
-
0164
-
02
-
0021

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

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
9

21
-
04
-
0164
-
02
-
0021

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 Node

Network Controller


AP, BSC, BTS, etc.

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
10

21
-
04
-
0164
-
02
-
0021

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

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
11

21
-
04
-
0164
-
02
-
0021

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

. . . .

Internet

Cellular BTS

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

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
12

21
-
04
-
0164
-
02
-
0021

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

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
13

21
-
04
-
0164
-
02
-
0021

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

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
14

21
-
04
-
0164
-
02
-
0021

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


Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
15

21
-
04
-
0164
-
02
-
0021

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

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
16

21
-
04
-
0164
-
02
-
0021

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)

CRC

CAPACITY

(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

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
17

21
-
04
-
0164
-
02
-
0021

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


Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
18

21
-
04
-
0164
-
02
-
0021

Conceptual Steps in HO

1.
Network advertising MIH capability


common criteria

a.
Based on MIH beacons w/ link IS

b.
Satisfies service engine requirements or enhances it

2.
L2 querying its associated L1 for link metrics

a.
L2 knows relevant/preferred services

b.
Can differentiate in
-
service HO, from keeping
-
tabs, etc.

c.
May all be initiated by the service engine

3.
L1 reporting of relevant parameters

a.
Link quality and connection type

b.
Metrics reporting


per agreed upon list

c.
Continuously, or on an as
-
needed basis, periodically?

4.
L2 (or other higher entity) determines suitability for HO


2 options

a.
Device requesting HO


user initiated

b.
Network requesting HO


carrier initiated

5.
HO negotiations and eventual transfer

a.
Maintenance of service & associated performance

b.
Maintenance of appropriate service grade, billing agreements, etc.

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
19

21
-
04
-
0164
-
02
-
0021

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

Net
-
xx

Network Controller

Net
-
xx

MN (1)

Net
-
xx

MN (2)

Net
-
xx

MN (n)

...

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
20

21
-
04
-
0164
-
02
-
0021

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.


Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
21

21
-
04
-
0164
-
02
-
0021

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



Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
22

21
-
04
-
0164
-
02
-
0021

Heterogeneous Network Example


Device HO based on movement


4 different networks, as an example


WLAN





GSM

Cellular






IEEE802.16

Mobile & Fixed





CDMA

Cellular




Ethernet

MN

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
23

21
-
04
-
0164
-
02
-
0021

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

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
24

21
-
04
-
0164
-
02
-
0021

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

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
25

21
-
04
-
0164
-
02
-
0021

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


Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
26

21
-
04
-
0164
-
02
-
0021

MIH Block Within the Stack

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

Mobility Events

MAC Events

PHY Events

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
27

21
-
04
-
0164
-
02
-
0021

Event & Link Triggers


Trigger Name


Source


Destination


MIH.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 Control

Bit rate

Voice quality

Jitter

Bandwidth allocation

Traffic congestion



MIH.PHY.RSSI


PHY



MIH Phys Conv


MIH.PHY.BER


PHY



MIH Phys Conv


MIH.PHY.CINR


PHY



MIH Phys Conv


Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
28

21
-
04
-
0164
-
02
-
0021

MIH Call Flow

Old Point of Attachment

Multimode STA

New Point of Attachment

HL

MIH
Function

LL

LL

HL

MIH
Function

LL

HL

MIH
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

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
29

21
-
04
-
0164
-
02
-
0021

MIH Layer Interactions

MIH Mobility Management Convergence

MIH Handover Control

MIH Physical Convergence

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

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
30

21
-
04
-
0164
-
02
-
0021

HO Triggering Parameters


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

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
31

21
-
04
-
0164
-
02
-
0021

Media Independent Handover Proposal
Scope Matrix for Discussion Part
-
I

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
32

21
-
04
-
0164
-
02
-
0021

Media Independent Handover Proposal
Scope Matrix for Discussion Part
-
II

Freescale Semiconductor, Inc. Hoghooghi, et al

Slide
33

21
-
04
-
0164
-
02
-
0021

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