投影片 1 - NTUT

Download Report

Transcript 投影片 1 - NTUT

Adviser: Ho-Ting Wu
1
Presenter: Chi-Fong Yang
Institute of Computer Science and Information
Engineering
National Taipei University of Technology
2015/7/18
CROSS LAYER ASSISTED SIP
HANDOVER
BASE ON WIMAX
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

2
2015/7/18
INTRODUCTION
Internet telephony uses SIP to establish and tear
down multimedia sessions
 Multimedia sessions are mostly based on
RTP/RTCP
 Layer 2 handover



Layer 3 handover


mobility solution for 802.16e MAC 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.
2015/7/18
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

4
2015/7/18
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

5
2015/7/18
IEEE 802.21 ARCHITECTURE
6
2015/7/18
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
2015/7/18
7
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
2015/7/18
8
HANDOVER MANAGER STRUCTURE
9
2015/7/18
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
2015/7/18
10
MOBILITY MANAGER STRUCTURE
11
2015/7/18
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.
12
2015/7/18
LAYER 2 HANDOVER SCHEMES
2015/7/18
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)

13
SOFT HANDOVER AND HARD
HANDOVER


2015/7/18
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.
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
2015/7/18

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_BSHOREQ 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

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
2015/7/18

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
16
MAC MANAGEMENT MESSAGES
802.16e MAC handover messages

Page 44, Table 14-MAC Management Messages
2015/7/18

17
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


2015/7/18

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
18
EXAMPLE OF CELL SELECTION
WITH RANGING
2015/7/18
19
HANDOVER DECISION AND
INITIATION
2015/7/18
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

20
EXAMPLE OF MOBILE STATION
HANDOVER
2015/7/18
21
EXAMPLE OF BASE STATION
HANDOVER
2015/7/18
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]



2015/7/18

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
23
DHCP IP ADDRESS ALLOCATION
2015/7/18
24
DEFINITION OF FAST HANDOFFS
FOR MOBILE IPV6
Access Router(AR)


Previous Access Router(PAR)


The mobile host's default router subsequent to its handover
Previous CoA(PCoA)


The mobile host's default router prior to its handover.
New Access Router(NAR)


The mobile host's default router
2015/7/18

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
25
MESSAGE FORMATS FOR FAST HANDOFFS
FOR MOBILE IPV6
Router Solicitation for Proxy Advertisement(RtSolPr)


Proxy Router Advertisement(PrRtAdv)


A message from the NAR to the PAR as a response to HI
Fast Binding Acknowledgment(FBAck)


A message from the PAR to the NAR regarding an mobile host’s handover
Handover Acknowledge(HAck)


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 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 to the PAR requesting information for a
potential handover
2015/7/18

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
26
PREDICTIVE FAST HANDOVER
2015/7/18
27
LAYER 3+ HANDOVER SCHEMES
2015/7/18
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

28
SIP HANDOVER WITH 802.16E MAC
2015/7/18
29
FAST SIP HANDOVER WITH 802.16E
MAC(CASE 1)
2015/7/18
30
FAST SIP HANDOVER WITH 802.16E
MAC(CASE 2)
2015/7/18
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)
2015/7/18

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
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.
2015/7/18

Traffic/Burst Value
Max Latency Value
33
SCHEDULING SERVICES
2015/7/18
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)

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
2015/7/18


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
2015/7/18


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
2015/7/18


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

2015/7/18

Minimum reserved traffic rate
 maximum sustained traffic rate
 traffic priority
 uplink grant scheduling type
 request/transmission policy

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

2015/7/18

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(reINVITE), even the SIP session of call setup is
successfully
 Actually the time of RTP transmission has long
delay
 For real time applications is unacceptable
2015/7/18


40
EXAMPLE OF HIDDEN PROBLEM
2015/7/18
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

42
2015/7/18
BANDWIDTH OF RTP RESERVATION
FLOW
2015/7/18
43
BANDWIDTH OF RTP RELEASE
FLOW
2015/7/18
44
CONCLUSION
2015/7/18
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

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.16e2005
[5]. Wooseong Kim, Kyounghee Lee, Chansu Yu, Ben Lee, Link
Layer Assisted Mobility Support Using SIP for Realtime Multimedia Communications
2015/7/18
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 RFC3344, June 2002
 [9]. Henning Schulzrinne, Computer Science
Department, Columbia University, New York,
NY 10027,Optimized Fast-Handoff
Schemes for
Application Layer Mobility
Management

2015/7/18
47
ANNEX A(1) – LINK EVENTS
Back
48
2015/7/18
ANNEX A(2) – MIH LINK EVENTS
49
2015/7/18
Back
ANNEX A(3) – MIH AND LINK
COMMANDS
Back
2015/7/18
50
ANNEX A(4) – INFORMATION
ELEMENT TYPE
51
Back
2015/7/18
ANNEX B(1) –TRAFFIC RATE AND
BURST VALUES
2015/7/18
Back
52
ANNEX B(2) –MAXIMUM LATENCY
VALUES
2015/7/18
Back
53