CROSS LAYER ASSISTED SIP HANDOVER

BASE ON WIMAX

Adviser: Ho-Ting Wu

Presenter: Chi-Fong YangInstitute of Computer Science and Information

EngineeringNational Taipei University of Technology

112/04/22

1

OUTLINE

Introduction Media Independent Handover Service Layer 2 Handover Schemes Layer 3 Handover Schemes Layer 3+ Handover Schemes QoS Supported in 802.16e Hidden Problem of SIP Handover on WiMAX Reference

112/04/22

2

INTRODUCTION

Internet telephony uses SIP to establish and tear down multimedia sessions

Multimedia sessions are mostly based on RTP/RTCP

Layer 2 handover mobility solution for 802.16e MAC handover

Layer 3 handover mobility solution for acquiring a new IP address

in a newly connected network Layer 3+(Upper Layer) handover

mobility solution for real-time traffic.

112/04/22

3

PROBLEMS DEFINITION

Layer 2 handover Link layer handover delay

Layer 3 handover Address allocation delay(Dynamic Host

Configuration Protocol ,DHCP) Router Advertisement delay

Layer 3+(Upper Layer) handover SIP re-INVITE process delay, consists of the

Round Trip Time (RTT) RTP packet transmission delay

112/04/22

4

MEDIA INDEPENDENT HANDOVER SERVICE

The standard IEEE 802.21 The standard defines an abstraction layer,

providing Media Independent Handover(MIH) Functions

The goal of simplifying the management of handovers to and from Ethernet, GSM, GPRS, UMTS, WiFi, Bluetooth and 802.16 networks.

Provide a common interface for managing events and control messages exchanged between network devices

112/04/22

5

IEEE 802.21 ARCHITECTURE

112/04/22

6

PRIMARY SERVICES OF MIH MIES - Media Independent Event Service

The MIES provides support for both local and remote events notification to the upper layers of a mobile host

Common events provided through MIHF are: “Link UP”, “Link DOWN”, “Link Parameters Change”, “Link Going DOWN” and “L2 Handover Imminent”

MICS - Media Independent Command Service The MICS is used to gather information about the status

of connected links and to execute mobility and connectivity decisions

Typical examples of commands are: “MIH Poll” and “MIH Configure” to poll connected links asking for their status and to configure new links, respectively.

MIIS - Media Independent Information Service The MIIS extends further the services of IEEE 802.21 with

a framework and corresponding mechanisms supporting the discovery and distribution of network information within a geographic area

112/04/22

7

HANDOVER MANAGER

Goalsservice continuitymobility policiesadaptation support at the

application levelcommon interface(Media

Independent Handover, MIH)Software ModuleRunning in user space

112/04/22

8

HANDOVER MANAGER STRUCTURE

112/04/22

9

MOBILITY MANAGER Link quality module

in charge of storing the information related to the available links and dispatching notifications about changes in link quality

Handover decision module in charge of performing handoff decisions

according to user’s preferences Power management module

in charge of switching on or off the interfaces according to user’s preferences

User policies module contains description of policies about security, cost, and

access networks priorities

112/04/22

10

MOBILITY MANAGER STRUCTURE

112/04/22

11

APPLICATION MOBILITY INTERFACE (AMI)

GoalsAMI receives the notifications

from the MM (Mobility Manager)AMI is in charge of performing

adaptation of application sessions and/or issuing configuration commands to the legacy application.

112/04/22

12

LAYER 2 HANDOVER SCHEMES

The standard IEEE 802.16e-2005 Support SS(subscriber stations) moving at

vehicular speeds and thereby specifies a system for combined fixed and mobile broadband wireless access.

License-exempt frequencies below 11 GHz (primarily 5–6 GHz)

112/04/22

13

SOFT HANDOVER AND HARD HANDOVER

The process in which an mobile Host(MH) migrates from the air-interface provided by one Base Station(BS) to the air-interface provided by another Base Station(BS)

break-before-make handover(hard handover) A handover where service with the target

BS(Base Station) starts after a disconnection of service with the previous serving BS

make-before-break handover(soft handover) A handover where service with the target BS

starts before disconnection of the service with the previous serving BS.

112/04/22

14

MACRO DIVERSITY HANDOVER AND FAST BS SWITCHING 802.16e-2005 Page 250 Two optional HO(Handover) modes

Macro Diversity Handover(MDHO) Fast BS Switching(FBSS)

The MDHO or FBSS capability can be enabled or disabled in the REG-REQ/RSP message exchange

MDHO Decision A MDHO begins with a decision for an MH(Mobile Host) to

transmit to and receive from multiple BSs(Base Station) at the same time

A MDHO can start with either MOB_MSHO-REQ or MOB_BSHO-REQ messages

FBSS HO Decision A FBSS handover begins with a decision for an mobile host to

receive/transmit data from/to the Anchor BS A FBSS handover can be triggered by either MOB_MSHO-REQ

or MOB_BSHO-REQ messages

112/04/22

15

MAC LAYER HANDOVER PROCEDURES Cell reselection

MH(Mobile Host) may use Neighbor BS(Base Station) information acquired from a decoded MOB_NBR-ADV message, or may make a request to schedule scanning intervals or sleep-intervals to scan, and possibly range

Handover decision and initiation A handover begins with a decision for an MH(Mobile Host) to

handover from a serving BS(Base Station) to a target BS(Base Station)

The decision may originate either at the MH(Mobile Host) or the serving BS(Base Station)

Decision consummates with a notification of MH(Mobile Host) intent to handover through MOB_MSHO-REQ or MOB_BSHO-REQ message

Synchronization to target BS MH(Mobile Host) shall synchronize to downlink transmissions of

Target BS(Base Station) and obtain downlink and uplink transmission parameters

Ranging Ranging is collection of processes by witch SS and BS maintain

the quality of RF commutation link between them

112/04/22

16

MAC MANAGEMENT MESSAGES

112/04/22

17

802.16e MAC handover messages Page 44, Table 14-MAC Management Messages

CELL RESELECTION

Scanning procedure using the MOB_SCN-REQ and MOB_SCN-RSP

message for scanning intervals The mobile host indicates in this message the estimated

duration of time it requires for the scanning Association procedure

Association is an optional initial ranging procedure occurring during scanning interval with respect to one of the neighbor BSs(Base Stations)

There are three levels of association as follows Association Level 0(Scan/Association without coordination) Association Level 1(Association with coordination) Association Level 2(Network assisted association reporting) 802.16e-2005 Page 236

112/04/22

18

EXAMPLE OF CELL SELECTION WITH RANGING

112/04/22

19

HANDOVER DECISION AND INITIATION

A handover begins with a decision for an MH(Mobile Host) to handover from a serving BS(Base Station) to a target BS(Base Station)

The decision may originate either at the mobile host

proceed with a notification through either MOB_MSHO-REQ or MOB_BSHO-REQ messages

mobile host actual pursuit of handover to one of BSs(Base Stations) specified in MOB_BSHO-RSP is recommended

112/04/22

20

EXAMPLE OF MOBILE STATION HANDOVER

112/04/22

21

EXAMPLE OF BASE STATION HANDOVER

112/04/22

22

LAYER 3 HANDOVER SCHEMES 802.16e establish IP connectivity

MH(Mobile Host) using IPv4 and not using mobile IP, they shall invoke DHCP mechanisms [IETF RFC 2131]

MH(Mobile Host) using IPv6, they shall either invoke DHCPv6 [IETF RFC 3315] or IPv6 Stateless Address Autoconfiguration [IETF RFC 2462]

Once the L3 handoff has occurred, the MH(Mobile Host) has to wait for some time in order to acquire a new IP address for that subnet via DHCP(Dynamic Host Configuration Protocol)

Mobile IP supported IP Mobility Support for IPv4(IETF RFC-3344) Fast Handoffs for Mobile IPv6(IETF RFC-4068)

predictive fast handover reactive fast handover

112/04/22

23

DHCP IP ADDRESS ALLOCATION

112/04/22

24

DEFINITION OF FAST HANDOFFS FOR MOBILE IPV6

Access Router(AR) The mobile host's default router

Previous Access Router(PAR) The mobile host's default router prior to its handover.

New Access Router(NAR) The mobile host's default router subsequent to its

handover Previous CoA(PCoA)

The mobile host's Care of Address valid on PAR's subnet New CoA(NCoA)

The mobile host's Care of Address valid on NAR's subnet

112/04/22

25

MESSAGE FORMATS FOR FAST HANDOFFS FOR MOBILE IPV6

Router Solicitation for Proxy Advertisement(RtSolPr) A message from the mobile host to the PAR requesting information

for a potential handover Proxy Router Advertisement(PrRtAdv)

A message from the PAR to the mobile host that provides information about neighboring links facilitating expedited movement detection. The message also acts as a trigger for network- initiated handover.

Fast Binding Update(FBU) A message from the mobile host instructing its PAR to redirect its

traffic(toward NAR) Handover Initiate(HI)

A message from the PAR to the NAR regarding an mobile host’s handover

Handover Acknowledge(HAck) A message from the NAR to the PAR as a response to HI

Fast Binding Acknowledgment(FBAck) A message from the PAR in response to an FBU

Fast Neighbor Advertisement(FNA) A message from the mobile host to the NAR to announce

attachment, and to confirm the use of NCoA when the MN has not received an FBACK

112/04/22

26

PREDICTIVE FAST HANDOVER

112/04/22

27

LAYER 3+ HANDOVER SCHEMES

Mobile Host(MH) will have to inform of its IP address change the Correspondent Node(CN)

Mobile Host(MH) will have to update its SIP session with the Correspondent Node(CN)

Only at this point the L3 handoff can be considered done

SIP outbound proxy supported SIP proxy in the visited network, namely the SIP

outbound proxy SIP outbound proxy can also support fast handoff

112/04/22

28

SIP HANDOVER WITH 802.16E MAC

112/04/22

29

FAST SIP HANDOVER WITH 802.16E MAC(CASE 1)

112/04/22

30

FAST SIP HANDOVER WITH 802.16E MAC(CASE 2)

112/04/22

31

QOS SUPPORTED IN 802.16E Service flows

service flow is a unidirectional flow of packets that is provided a particular QoS

an SFID(Service Flows Identify) is assigned to each existing service flow, it is uniquely identified by a 32-bits

the relationship between SFID and transport CID, when present, is unique(An SFID shall never be associated with more than one transport CID)

Service classes mobile networks require common definitions of service

class names and associated AuthorizedQoSParamSets in order to facilitate operation across a distributed topology.

global service class names are employed as a baseline convention for communicating AuthorizedQoSParamSet or AdmittedQoSParamSet

Scheduling Services Each connection is associated with a single scheduling

type

112/04/22

32

SERVICE CLASSES Std 802.16e–2005 page 211 Service class names are a rules-based naming system

whereby the global service class name itself contains referential QoS Parameter codes.

112/04/22

33

Traffic/Burst Value

Max Latency Value

SCHEDULING SERVICES

Std 802.16e-2005 page 183 Unsolicited Grant Service (UGS) Real-Time Polling Service (rtPS) Extended Real-Time Polling Service (ertPS) Non-Real-Time Polling Service (nrtPS) Best Effort ( BE)

112/04/22

34

MANDATORY QOS PARAMETERS FOR UGS

Unsolicited Grant Service (UGS) support real-time uplink service flows that transport

fixed-size data packets on a periodic basis, such as T1/E1 and Voice over IP without silence suppression

The BS shall provide Data Grant Burst IEs to the SS at periodic intervals based upon the Maximum Sustained Traffic Rate of the service flow.

The mandatory QoS parameters maximum sustained traffic rate maximum latency tolerated jitter uplink grant scheduling type request/transmission policy

112/04/22

35

MANDATORY QOS PARAMETERS FOR RTPS

Real-Time Polling Service (rtPS) support real-time uplink service flows that generate

transport variable size data packets on a periodic basis, such as MPEG video

allow the SS to specify the size of the desired grant(offers real-time,periodic, unicast request opportunities)

The mandatory QoS parameters Minimum reserved traffic rate maximum sustained traffic rate maximum latency uplink grant scheduling type request/transmission policy

112/04/22

36

MANDATORY QOS PARAMETERS FOR ERTPS

Extended Real-Time Polling Service (ertPS) scheduling mechanism which builds on the

efficiency of both UGS and rtPS. BS shall provide unicast grants in an unsolicited

manner like in UGS, saving the latency of a bandwidth request

UGS allocations are fixed in size, ertPS allocations are dynamic

The mandatory QoS parameters Minimum reserved traffic rate maximum sustained traffic rate maximum latency request/transmission policy

112/04/22

37

MANDATORY QOS PARAMETERS FOR RTPS

Non-Real-Time Polling Service (nrtPS) support non-real-time uplink service flows that

generate transport variable size data The BS shall provide timely unicast request

opportunities, The BS typically polls nrtPS CIDs on an interval on the order of one second or less

The mandatory QoS parameters Minimum reserved traffic rate maximum sustained traffic rate traffic priority uplink grant scheduling type request/transmission policy

112/04/22

38

MANDATORY QOS PARAMETERS FOR BE

Best Effort ( BE) provide efficient service for best effort traffic in the

uplink the Request/Transmission Policy setting shall be

set such that the SS is allowed to use contention request opportunities

112/04/22

39

HIDDEN PROBLEM OF SIP HANDOVER ON WIMAX

Scheduling type of 802.16 SIP is the traffic of BE(Best Erroft) RTP is the traffic of UGS/rtPS/ertPS(Unsolicited Grant

Service / Real-Time Polling Service /Extended Real-Time Polling Service )

The bandwidth request of RTP is not reserved in a duration of SIP session of call setup(re-INVITE), even the SIP session of call setup is successfully

Actually the time of RTP transmission has long delay

For real time applications is unacceptable

112/04/22

40

EXAMPLE OF HIDDEN PROBLEM

112/04/22

41

BANDWIDTH OF RTP RESERVATION

SIP outbound proxy use re-INVITE to configure the RTP transmission

SIP outbound proxy usually has access to the Session Description Protocol(SDP) information containing the mobile host media address and port

SIP outbound proxy use Application Mobility Interface(AMI) to negotiate with MAC

SIP outbound proxy send the RTP bandwidth request(release) through AMI to MAC

112/04/22

42

BANDWIDTH OF RTP RESERVATION FLOW

112/04/22

43

BANDWIDTH OF RTP RELEASE FLOW

112/04/22

44

CONCLUSION

Propose predictive handover with SIP to reduces the handover latency

Provide SIP proxy to fast configure the RTP transmission

Challenge Bandwidth reservation for RTP transmission Admission Control(AC) and Bandwidth

Allocation(BA) for mobility network

112/04/22

45

REFERENCE [1].Jared Stein,Survey of IEEE802.21 Media

Independent Handover Services ,

http://www.cs.wustl.edu/~jain/cse574-06/ftp/handover/index.html [2].Filippo Cacace, Luca Vollero, Managing Mobility

and Adaptation in Upcoming 802.21Enabled Devices [3].IEEE Standard for Local and metropolitan area

networks Part 16:Air Interface for Fixed Broadband Wireless Access Systems, IEEE Std 802.16-2004, 2004.

[4].IEEE Standard for Local and metropolitan area networks Part 16:Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment 2: Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands IEEE Std 802.16e-2005

[5]. Wooseong Kim, Kyounghee Lee, Chansu Yu, Ben Lee, Link Layer Assisted Mobility Support Using SIP for Real-time Multimedia Communications

112/04/22

46

REFERENCE

[6]. R.Koodli,Ed,Fast Handoffs for Mobile IPv6,IETF RFC-4068,July 2005

[7]. C.Perkins,Ed,IP Mobility Support for IPv4,IETF RFC-3344,August 2002。

[8]. Session Initiation Protocol(SIP),IETF RFC-3344, June 2002

[9]. Henning Schulzrinne, Computer Science Department, Columbia University, New

York, NY 10027,Optimized Fast-Handoff Schemes for Application Layer Mobility Management

112/04/22

47

ANNEX A(1) – LINK EVENTS

112/04/22

48

Back

ANNEX A(2) – MIH LINK EVENTS

112/04/22

49

Back

ANNEX A(3) – MIH AND LINK COMMANDS

112/04/22

50Back

ANNEX A(4) – INFORMATION ELEMENT TYPE

112/04/22

51Back

ANNEX B(1) –TRAFFIC RATE AND BURST VALUES

112/04/22

52Back

ANNEX B(2) –MAXIMUM LATENCY VALUES

112/04/22

53Back