1 / 53

CROSS LAYER ASSISTED SIP HANDOVER BASE ON WIMAX

CROSS LAYER ASSISTED SIP HANDOVER BASE ON WIMAX. Adviser: Ho-Ting Wu Presenter: Chi-Fong Yang Institute of Computer Science and Information Engineering National Taipei University of Technology. OUTLINE. Introduction Media Independent Handover Service Layer 2 Handover Schemes

ricca
Download Presentation

CROSS LAYER ASSISTED SIP HANDOVER BASE ON WIMAX

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CROSS LAYER ASSISTED SIP HANDOVER BASE ON WIMAX Adviser: Ho-Ting Wu Presenter: Chi-Fong Yang Institute of Computer Science and Information Engineering National Taipei University of Technology

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

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

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

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

  6. IEEE 802.21 ARCHITECTURE

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

  8. HANDOVER MANAGER • Goals • service continuity • mobility policies • adaptation support at the application level • common interface(Media Independent Handover, MIH) • Software Module • Running in user space

  9. HANDOVER MANAGER STRUCTURE

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

  11. MOBILITY MANAGER STRUCTURE

  12. APPLICATION MOBILITY INTERFACE (AMI) • Goals • AMI 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.

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

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

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

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

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

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

  19. EXAMPLE OF CELL SELECTION WITH RANGING

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

  21. EXAMPLE OF MOBILE STATION HANDOVER

  22. EXAMPLE OF BASE STATION HANDOVER

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

  24. DHCP IP ADDRESS ALLOCATION

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

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

  27. PREDICTIVE FAST HANDOVER

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

  29. SIP HANDOVER WITH 802.16E MAC

  30. FAST SIP HANDOVER WITH 802.16E MAC(CASE 1)

  31. FAST SIP HANDOVER WITH 802.16E MAC(CASE 2)

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

  33. 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. Traffic/Burst Value Max Latency Value

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

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

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

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

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

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

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

  41. EXAMPLE OF HIDDEN PROBLEM

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

  43. BANDWIDTH OF RTP RESERVATION FLOW

  44. BANDWIDTH OF RTP RELEASE FLOW

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

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

  47. REFERENCE • [6]. R.Koodli,Ed,Fast Handoffs for Mobile IPv6,IETF RFC-4068,July 2005 • [7]. C.Perkins,Ed,IPMobility 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

  48. ANNEX A(1) – LINK EVENTS Back

  49. ANNEX A(2) – MIH LINK EVENTS Back

  50. ANNEX A(3) – MIH AND LINK COMMANDS Back

More Related