Download 21-04-0164-01-0000-Freescale

• 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