Transcript Mobility Management in IP

Mobility Management in IP-Based
Wireless Networks
1. Basic issues in mobility management
2. Mobility management in IP networks
3. Mobility management in 3GPP packet
networks
1. Basic Issues in Mobility Management
1.1 Impact of naming and addressing on mobility
management
1.2 Location management
1.3 Packet delivery to mobile destinations
1.4 Handoffs
1.5 Roaming
Types of Mobility
 Terminal mobility
 the ability for a user terminal to continue to access
the network when the terminal moves
 User mobility
 the ability for a user to continue to access network
services, may be from different terminals, under the
same user identity when the user moves
 Service mobility
 the ability for a user to access the same services
regardless of where the user is
Basic Mobility Management Requirements
 Support all forms of mobility
 Support mobility for all types of applications
 real-time and non-real-time data, voice, and multimedia
applications
 Support mobility across heterogeneous radio systems in the
same or different administrative domains
 Support session (service) continuity
 continue without significant interruptions as the user
moves about
 Global roaming
 the ability for a user to move into and use different
operators’ networks
Basic Functional Components
 Location management
 a process that enables the network to determine a
mobile’s current location
 i.e., the mobile’s current network attachment point
where the mobile can receive traffic from the
network
 Packet delivery to mobiles
 a process whereby a network node, mobile terminal,
or end-user application uses location information to
deliver packets to a mobile terminal
 Handoff and roaming
 handoff (or handover)
 a process in which a mobile terminal changes its
network attachment point
 example: a mobile may be handed off from one
wireless base station (or access point) to another, or
from one router or switch to another
 roaming
 the ability for a user to move into and use different
operators’ networks
 Network access control
 a process used by a network provider to determine
whether a user is permitted to use a network and/or a
specific service provided by the network
 main steps
 authentication: verify the identity of user
 authorization: determine whether a user should be
permitted to use a network or a network service
 accounting: collect information on the resources used
by a user
1.1 Impact of Naming and Addressing
on Mobility Management
 A name identifies a network entity, such as a user, a
user terminal, a network node, or a service
 An address is a special identifier used by the network
to determine where traffic should be routed
 A terminal’s address typically identifies a network
attachment point
 a telephone number in a PSTN network
 identifies a port on a PSTN switch rather than the telephone
set itself
 an IP terminal’s IP address
 identifies an attachment point to an IP network
 Today’s networks, the name of a terminal is often tied
with the terminal’s address, example,
 an IP terminal has traditionally been named by the Internet
Domain Name associated with the terminal’s IP address
 mobile terminals that use multiple network addresses are
becoming increasingly popular, example,
 a mobile terminal may have multiple radio interfaces
 each radio interface may use a different type of radio
technology
 each radio interface may need to have its own IP address
 which domain name should be used as the
terminal’s name in this case?
 solutions
 make the IP terminal names independent of the
terminal’s addresses
 e.g., IETF has defined Network Access Identifier
(NAI) that allows a terminal to be identified by a
single globally unique NAI regardless of how
many IP addresses this terminal may have
 Traditional circuit-switched networks, such as the
PSTN, typically do not support user names
 they assume a static mapping between a terminal and the user
responsible to pay for the services used by the terminal
 Static mapping of users to terminals could lead to a
range of problems in a mobile network
 mobile users often have to, or like to, use different types of
terminals in different locations depending on what types of
terminals are available or best fit their needs
 this suggests that a mobile user’s name should not be
statically tied to a mobile terminal
 Terminal-independent user names have become
increasingly common in mobile networks, example,
 GSM
 each subscriber is identified by a globally unique
International Mobile Subscriber Identity (IMSI) that
is independent of the terminal used by the user
 a Subscriber Identity Module (SIM) carries a
mobile’s IMSI and can be ported from one mobile
terminal to another to allow a user to use different
terminals and still be recognized by the network as
the same user
 Today’s IP Networks, applications provide their own
naming schemes for users, example
 e-mail users are identified by their e-mail addresses
 SIP users are identified by their SIP URIs
 the NAI may serve as a user’s globally unique and
terminal-independent user name
1.2 Location Management
1.2.1 Location update strategies
1.2.2 Location discovery (paging)
1.2.3 Interactions between location update and
paging
1.2.1 Location Update Strategies
 When a mobile should perform location
updates and what location-related information
the mobile should send to the network?
 update the mobile’s precise location every time the
mobile changes its network attachment points,
example, Mobile IP
 knowing a mobile’s precise location allows the
network to deliver traffic to the mobile via unicast
 when mobiles change their network attachment points
frequently, maintaining precise locations of all mobiles could
lead to heavy location update traffic, which wastes limited
radio bandwidth
 to save scarce resources on the mobile and in the wireless
network, a network can group network attachment points into
location areas
 only keeps track of which location area each mobile is likely
in when the user and the network have no traffic to send to
each other
 the network tries to determine a mobile’s precise location
only when it needs to deliver user traffic to the mobile
Location Update
 Time-based update
 update periodically at a constant interval (called update
interval)
 Movement-based update
 update whenever it traverses a predefined number of
location areas, called movement threshold
 most existing wireless networks (e.g., GSM, GPRS,
3GPP, 3GPP2) use movement-based location update
strategy in which the movement threshold is one
 Distance-based update
 update whenever it has traveled a predefined distance
threshold from the location area in which it performed
its last location update
 distance may be measured in many different ways, such
as physical distance, or cell distance (i.e., distance
measured in number of radio cells or location areas)
 the physical distance-based strategy is used, for example,
as an option in 3GPP2
 Parameter-based update
 update whenever the value of any preselected parameter
changes
 these strategies are sometimes referred to as profilebased strategies
 this strategy is used, for example, as an option in 3GPP2
 Implicit update
 a mobile does not send any message explicitly for the
purpose of location update
 instead, the network derives the mobile’s location when
the network receives other signaling or user data from
the mobile
 Probabilistic update
 update based on a probability distribution function
 a probabilistic version of time-based, movement-based,
or distance-based location update strategies may be
created
 example: a time-based location update
 the new update time interval after each update may
be dynamically adjusted based on the probability
distribution of call arrival times
Movement-Based vs. Distance-Based
Location Update Strategies
 Assumptions
 the mobile last performed a location update
in the center location area
 the number on each arrowed line indicates
the number of times the mobile has crossed
a cell boundary
 the movement threshold used by a
movement-based update strategy is three
cell boundary crossings
 the distance threshold used by the distancebased update strategy is three cells
 Movement-based update strategy
 update at the third, sixth, and the ninth times it
crosses a cell boundary
 Distance-based update strategy
 only update once, i.e., at the ninth time it crosses a
cell boundary
1.2.2 Location Discovery
(Paging)
 Network performs paging
 send one or multiple paging messages to a paging
area where the mobile is likely to be located
 Upon receiving a paging message
 a mobile needs to update its precise current location
with the network
Issues with Paging
 Paging should be done within a reasonable time
constraint
 if paging takes too long, the call setup latency could
become intolerable to end users and call attempts
may be dropped
 How to construct paging areas?
 paging areas do not have to be identical to location
areas
 How to search a paging area to locate a mobile?
Paging Strategies




Blanket paging
Sequential paging
Geographic paging
Group paging
Blanket Paging
 Blanket paging is deployed in most of today’s wireless
networks
 A paging message is broadcast simultaneously to all radio
cells inside the paging area where the mobile is located
 Advantages
 simplicity
 low paging latency
 Drawback
 broadcasting paging messages to a large number of
radio cells could consume a significant amount of scarce
resources, including radio bandwidth and power on all
the mobiles in the paging area
Blanket Paging
Page
every
cells
within the
LA
Sequential Paging
 A large paging area is divided into small paging sub-areas
(e.g., radio cells)
 Procedure
 paging messages are first sent to a subset of the paging
areas where the network believes the mobile is most
likely to be located
 if the mobile is not in this sub-area, subsequent paging
messages will be sent to another paging sub-area
 the process continues until either the mobile is found or
the entire paging area is searched
Sequential Paging
Page the cells
sequentially
until the user
is found
1
4
2
3
5
8
7
6
9
10
 Issues
 how to divide a large paging area into smaller paging
sub-areas
 which sub-areas should be searched first
Blanket Paging vs. Sequential Paging
Blanket
Sequential
paging cost
large
small
paging delay
small
large
sequential group paging may be used if
there is a constraint on paging cost
Geographic & Group Paging Strategies
 Geographic paging
 network uses geographical position of a mobile to
determine where a paging message should be sent
 Group paging
 to locate a mobile, the network pages a group of mobiles
together instead of paging only the mobile to be located
1.2.3 Interactions between Location
Update and Paging
 Design of location update and paging strategies should
consider a proper balance among the following
 overhead
 network resources consumed by location updates and
paging
 performance, e.g., paging latency
 complexity
 complexities of location update and paging as well as
protocols needed to support these strategies
 high complexity results in high network costs and
high level of difficulty in operating the network
1.3 Packet Delivery Strategies
to Mobile Destinations
 Direct delivery strategy
 a packet originator first obtains the destination
mobile’s current location (from location servers)
 then addresses and sends packets directly to that
location
 Relayed delivery strategy
 a packet is sent first to a mobility anchor point
 the packet is then relayed toward its final
destination
 the packet originator does not need to know
 the destination mobile’s current location
 whether a destination is a mobile or a fixed node
 Limitations of relayed delivery strategy
 may cause packets to take longer paths than direct
delivery strategies
 the mobility anchor points could become traffic and
performance bottlenecks
 Integrated relayed delivery and direct delivery strategies
 packets destined to the destination will be routed first toward
a mobility anchor point
 mobility anchor point relays these packets to mobile’s current
location
 the mobility anchor point or the destination then inform the
packet originator of the destination’s current location
 the packet originator then address the packets directly to the
mobile’s current location
1.4 Handoffs
 Handoffs in an IP-based wireless network may occur at
different protocol layers
 Handoffs at each protocol layer may occur in different
scopes
 Handoffs can be hard or soft
Layers of Handoff
 Physical layer
 a mobile changes its network attachment point at the
physical layer
 example: the mobile may change from one radio
channel to another, from one wireless base station to
another
 Logical link layer
 a mobile changes its logical link layer over which the
mobile exchanges user IP packets with the network
 IP layer
 the mobile changes its IP address or moves to a different
IP access router
Scopes of Handoff
 Handoffs at each protocol layer may occur in different
scopes
 Handoffs at the IP layer
 intra-subnet handoff
 a mobile remains on the same IP subnet after it
changes its IP address or moves from one base
station to another
 inter-subnet handoff
 a mobile moves into a new IP subnet and
changes its IP address
 inter-router handoff
 a mobile moves to a new IP access router
Types of Handoff Processes
 Hard handoff
 a mobile can receive user data from only one base
station at any time
 handoff implementations
 make-before-break
 mobile sets up new network attachment before it
tears down old network attachment
 break-before-make
 mobile tears down old network attachment point
and then sets up new network attachment
 Soft handoff
 a mobile receives copies of the same user data from two
or more base stations simultaneously
 the mobile uses signal processing techniques to
determine the most likely correct value of the data from
its multiple copies
 soft handoff has been proven to be an effective way for
increasing the capacity, reliability, and coverage range
 requires the following capabilities
 data distribution and selection
 data content synchronization
Data Distribution and Selection
 BS → Mobile
 separate copies of the same data sent via multiple base
stations to the same mobile
 the mobile should construct a single copy and only pass the
copy to upper layer protocols or applications
 Mobile → BS
 multiple copies of the same user data originated from a
mobile sent to network via different base stations
 the edge devices connecting the radio access networks to the
core network should select one copy of the data to send to the
destination
Data Content Synchronization
 Mobile’s radio system should combine copies of the
same data arriving from multiple base stations
Selection and Distribution Unit (SDU)
 Responsible for data distribution from network to
mobile
 May be located on a base station or a MSC
 Create and distribute multiple streams of the same data
over layer-2 circuits to multiple base stations that relay
the data to the mobile
1.5 Roaming
 Home domain
 the domain where the mobile maintains a service
subscription account
 uses user’s accounts and service profiles to
determine
 how to provide services to a mobile
 how to charge the services used by the mobile
 user’s account
 subscriber’s identity
 billing address
 service profile
 security information (for authentication)
 user’s service profile
 the network services subscribed by the user
 the networks the user is allowed to use
 Visited domain
 when a user moves into a domain with which it
does not have an account
Extra Capabilities Needed to
Support Roaming
 Network access control for visiting mobiles
 Roaming agreement between mobile’s home domain
and visited domains
 Session continuity while a user crosses domain
boundaries
Network Access Control for
Visiting Mobiles
 Decision on allowing a user to use a visited domain is
based on
 who this user is
 whether the user or its home domain agrees to pay
for its use of the visited domain
 where to send the bill of this user
Roaming Agreement between Mobile’s
Home Domain and Visited Domains
 A roaming agreement should decide
 how a visiting mobile should be authenticated,
authorized, and billed
 The visited domain may ask the user’s home domain to
 authenticate the user
 confirm how to charge for the user’s use of the
visited domain
 The home domain may send information regarding the
user’s service profile to the visited domain
 to help the visited domain to determine how to
provide services to the user, for example, the user’s
QoS requirements
Roaming Broker
 Problem
 users may roam outside the countries into different network
providers in other countries
 it is difficult for a network provider to establish a roaming
agreement with every other network provider
 One alternative solution is to use a Roaming Broker
 Roaming broker
 each network provider only needs to establish a roaming
agreement with the roaming broker
 when a user roams into a new visited network
 this visited network will ask the roaming broker to
authenticate and authorize the user
 the roaming broker
 relay the authentication and authorization requests
from the mobile’s home network provider
 relay the responses to the mobile’s current visited
network
2. Mobility Management in
IP Networks
2.1 Naming and addressing of IP terminals
2.2 Mobile IPv4
2.3 MIPv4 regional registration
2.4 Paging extensions to Mobile IPv4
2.5 Mobile IPv6
2.6 SIP-based mobility management
2.7 Cellular IP
2.8 HAWAII
 Mobile IPv4 (or MIPv4)
 standard protocol defined by IETF for mobility
management in IPv4 networks
 enables an IP terminal to maintain a permanent IP
address and receive packets addressed to this
permanent address regardless of the mobile’s
current attachment point to the Internet
 Mobile IPv6 (MIPv6)
 the IETF is leveraging MIPv4 to define an IP-layer
mobility management protocol for IPv6 networks
 Micromobility management protocols
 IP-layer mobility protocols that provide enhanced
mobility support (e.g., reduced handoff delay)
within a limited geographical region
 E.g., a building, campus, or a metropolitan area
network
 Examples of micromobility management protocols
 MIPv4 Regional Registration
 Cellular IP
 HAWAII
 SIP-based mobility management
 the most widely accepted application-layer mobility
protocol as the session management protocol for
wireline and wireless IP networks
2.1 Naming and Addressing of
IP Terminals
 Issues
 with regular IP routing protocols, when a terminal
moves to a new IP network or IP subnet (visited or
foreign network)
 the terminal have to use an new IP address of
the new IP network in order to receive packets
from the visited network
 if the mobile terminal uses its IP address as its
identifier, the identifier will change as the
mobile moves from one IP network to another
 a mobile may have multiple radio interfaces, each
with a different IP address
 a mobile’s radio interfaces may not all be
reachable by the network at any given time
 depending on which radio systems are available at
the mobile’s current location or which radio
system the mobile user wishes to use if multiple
radio systems are available
 this makes it difficult to determine which IP
address configured on the mobile should be used
as the mobile’s identifier
 Resolution：Network Access Identifier (NAI)
 IETF defined NAI that can identify a mobile
terminal (or user) regardless of either the terminal’s
current location or how many IP addresses the
terminal may have
 NAI form
 username@realm
 username：identifies the terminal
 realm：identifies the Internet domain name of a
Network Access Server (NAS)
Note: Network Access Server (NAS)
 A single point of access to a remote resource
 Act as a gateway to guard access to a protected
resource
 this can be anything from a telephone network, to printers, to
the Internet
 Operations
 the client connects to the NAS
 the NAS then connects to another resource asking whether
the client's supplied credentials are valid
 based on that answer the NAS then allows or disallows
access to the protected resource
 NAS contains no information about what clients can connect
or what credentials are valid
 all the NAS does is send the credentials the client supplied to
a resource which does know how to process the credentials
 Associated protocols
 although not required, NAS are almost exclusively used with
AAA servers
 RADIUS tends to be the most widely used
 DIAMETER base protocol extends RADIUS services by
providing error handling and inter-domain communications
 this protocol is used in networks like IP Multimedia
Subsystem (IMS)
2.2 Mobile IPv4
 Mobility issues in IP Networks
 once a mobile terminal moves to a new subnet, a
correspondent node needs to use the mobile’s new
IP address
 it is difficult to force every possible
correspondent node to keep track when a mobile
terminal may change its IP address and what the
mobile’s new address will be
 changing IP address will cause on-going TCP
sessions to break
 Mobility management should
 ensure on-going TCP connection does not break
 restore quickly if TCP connection breaks
Home Network
 Home address
 a globally unique and routable IP address
 preconfigured or dynamically assigned
 Home network
 the network whose network address prefix matches that of the
mobile terminal’s home address
 Home agent (HA)
 maintain up-to-date location information for the mobile
 intercept packets addressed to the mobile’s home address
 tunnel packets to the mobile’s current location
Note: Network Prefix
7
A:
0
24
Network
Host
14
B:
1
0
16
Network
Host
21
C:
1
1
0
Network
8
Host
Class A Network (/8 Prefixes)
Class B Networks (/16 Prefixes)
Class C Networks (/24 Prefixes)
 IP addresses are divided into three different
classes
 each of the following figure defines different-sized
network and host parts
 there are also class D addresses specify a multicast
group, and class E addresses that are currently
unused
 in all cases, the address is 32 bits long
78
7
A:
0
24
Network
Host
14
B:
1
0
16
Network
Host
21
C:
1
1
0
Network
8
Host
IP addresses: (a) class A; (b) class B; (c) class C
79
 the class of an IP address is identified in the most
significant few bits
 if the first bit is 0, it is a class A address
 if the first bit is 1 and the second is 0, it is a class B
 if the first two bits are 1 and the third is 0, it is a class
C address
 of the approximately 4 billion (= 232) possible IP
addresses
 one-half are class A
 one-quarter are class B
 one-eighth are class C
80
 Class A addresses
 7 bits for the network part and 24 bits for the host
part
 126 (= 27-2) class A networks (0 and 127 are
reserved)
 each network can accommodate up to 224-2 (about 16
million) hosts (again, two are reserved values)
 Class B addresses
 14 bits for the network part and 16 bits for the host
part
 65,534 (= 216-2) hosts
81
 Class C addresses
 21 bits for the network part and 8 bits for the
host part
 2,097,152 (= 22l) class C networks
 254 hosts (host identifier 255 is reserved for
broadcast, and 0 is not a valid host number)
82
 IP addresses are written as four decimal integers
separated by dots
 each integer represents the decimal value contained in
1 byte (= 0~255) of the address, starting at the most
significant
 Example, 171.69.210.245
 Internet domain names (DNS)
 also hierarchical
 domain names tend to be ASCII strings separated by
dots, e.g., cs.nccu.edu.tw
83
Foreign Network
 Care-of Address (CoA)
 assigned to the mobile by the foreign network
 a mobile uses its CoA to receive IP packets in the
foreign network
 Foreign agent (FA)
 provides CoAs and other necessary configuration
information (e.g., address of default IP router) to
visiting mobiles
 de-tunnels packets from the tunnel sent from a visiting
mobile’s HA and then delivers the packets to the
visiting mobile
 acts as the IP default router for packets sent by visiting
mobile terminals
 helps visiting mobiles to determine whether they have
moved into a different network
Two Types of CoAs in MIPv4
 Foreign Agent CoA
 an IP address of a FA
 each FA is responsible for providing FA CoAs to
visiting mobiles
 when FA CoA is used, the mobile’s HA tunnels the
packets to the mobile’s current FA that addressed to
the mobile’s home address
 the FA will then de-tunnel the packets and deliver
them to the mobile
 Co-located CoA
 a CoA acquired by a mobile terminal through any
method external to Mobile IP
 example, a mobile may use the Dynamic Host
Configuration Protocol (DHCP) to obtain a
temporary address dynamically
 the mobile terminal’s HA tunnels the packets
addressed to the mobile’s home address directly to
the mobile itself; these packets do not have to go
through any FA
Main Phases of MIPv4 Operation





Agent discovery
Movement detection
Leaving the home network
Entering and staying in a visited network
Returning to the home network
2.2.1 Agent discovery
2.2.2 Movement detection
2.2.3 Leaving the home network
2.2.4 Entering and staying in a visited network
2.2.5 Returning to the home network
2.2.6 Mobile-home authentication extension
2.2.7 Vendor/organization specific extensions to Mobile IP
messages
2.2.8 Reverse tunneling
2.2.9 Limitations of MIPv4
2.2.10 MIPv4 route optimization
2.2.1 Agent Discovery
 Goal
 for a mobile terminal to discover mobility agents (home
agent and foreign agent)
 Approach
 mobility agents advertise services and system information to
mobiles via Agent Advertisement messages
 a mobile may solicit an Agent Advertisement message from
any mobility agents by sending an Agent Solicitation
message to the Mobile-Agents Multicast Group address
224.0.0.11
 all mobility agents should respond to any received Agent
Solicitation message
 Agent discovery using Internet Control Message
Protocol (ICMP) Router Discovery Messages
 ICMP Router Advertisement Message
 sent by router to terminals to inform its IP
address
 ICMP Router Solicitation Message
 sent by a terminal to ask router to send ICMP
Router Advertisement Messages
Agent Advertisement Message
 ICMP Router Advertisement message with extensions
to carry MIPv4 specific information
 Mobility Agent Advertisement Extension
 indicate this is a MIPv4 Agent Advertisement message
 carry information specific to MIPv4 mobility agent
 Prefix-Lengths Extension (optional)
 indicate the network prefix length (in bits) of each
advertised Router Address
 mobile may use this prefix lengths to determine whether
it has moved into a new IP network
Structure of Mobile IP Agent
Advertisement Message
MIPv4 Mobility Agent Advertisement
Extension to ICMP Router Advertisement Message
Fields and Flags
 Type
 16, indicates a Mobility Agent Advertisement Extension
 Length
 length in octets of the extension from the beginning of
Sequence Number field to the end
 Sequence Number
 number of Agent Advertisement messages sent since the
agent was initiated
 Registration Lifetime
 longest lifetime in seconds the agent is willing to accept
any Registration Request
 R (Registration required)
 set, if Mobile IP registration through this FA is required
 B (Busy)
 set, if this FA will not accept registrations from
additional mobile terminals
 H (Home agent)
 set, if this agent offers service as a HA
 F (Foreign agent)
 set, if this agent offers service as a FA
 M (Minimal encapsulation - RFC 2004)
 set, if this agent can accept tunneled messages that use
Minimal Encapsulation
 G (GRE encapsulation - RFC 3095)
 set, if this agent accepts tunneled packets that use
Generic Routing Encapsulation (GRE)
 r (Reserved)
 this field is not used
 must be set to zero and ignored on reception
 T (Reverse tunneling)
 set, if this FA supports reverse tunneling
 Reserved
 not currently used and shall be ignored by the mobiles
 Foreign Agent Care-of Addresses
 addresses, if any, provided by this FA
MIPv4 Prefix-Length Extension
to ICMP Router Advertisement message
Fields
 Type
 19, indicates a Prefix-Length Extension
 Length
 the value of the “Num Addrs” field in the ICMP Router
Advertisement portion of the Agent Advertisement
 indicating the number of Router Addresses advertised in this
message
 Prefix Lengths
 the number of leading bits that define the network prefix of
the corresponding Router Address
 encoded as a separate byte, in the order that the Router
Addresses are listed in the ICMP Router Advertisement
portion
Agent Solicitation Message
 The format is identical to ICMP Router Solicitation
message, except
 its IP Time-to-Live (TTL) must be set to 1, means that
Agent Solicitation message will not propagate beyond
local IP subnet
2.2.2 Movement Detection
 For a mobile to detect whether it enters a new IP
subnet (changes its care-of address)
 Approach 1
 use the Lifetime field in Agent Advertisement
messages
 Lifetime indicates the length of time that this
Advertisement is valid
 Algorithm
 if the mobile does not receive any new Agent
Advertisement from the same mobility agent within the
remaining Lifetime
 it will assume that it has lost contact with that
mobility agent
 if, by this time, the mobile has already received Agent
Advertisement from other mobility agents
 it may use one of these mobility agents
 otherwise, the mobile should start searching for a new
mobility agent by issuing Agent Solicitation messages
 Approach 2
 a mobile may compare the network prefix of old
network with that of new IP subnet
 if the two network prefixes differ then it means the
mobile has just entered a new IP subnet
2.2.3 Leaving the Home Network
 As a mobile leaves its home network
 the HA captures the packets addressed to the mobile’s
home address
 ARP (Address Resolution Protocol)
 used to determine the hardware address associated with
a target IP address
 hardware address
 identify a node at the link layer
 used by link layer protocol to forward link-layer
frames or packets
 ex：Medium Access Control (MAC) address
 ARP protocol
 when a node wants to send an IP packet to a target node
and does not know it’s hardware address
 it broadcasts an ARP REQUEST message (include
sender IP address, target IP address, sender hardware
address) to ask all the nodes on the local IP network for
the target node’s hardware address that matches target
IP address
 the node that matches the target IP address will reply
with ARP REPLY message including its IP address and
hardware address
 once a node learns the mapping from an IP address to a
hardware address, the node caches the mapping in its
ARP cache for later use
Issues & Resolutions
 Issue-1
 after a mobile leaves its home network, other nodes
on the home network may still have cached the
mapping of the mobile’s IP address to its hardware
address
 those nodes will continue to send packets to the
mobile’s hardware address rather than to the HA,
and thus these packets will be lost
 Resolution-1 (Gratuitous ARP)
 a Gratuitous ARP packet, can be an ARP
REQUEST packet, is sent by a node to trigger other
nodes to update their ARP caches
 before a mobile leaves its home network
 it broadcasts a Gratuitous ARP packet to all
other nodes (including mobility agents) on the
local IP subnet
 those nodes that receives such a Gratuitous ARP
packet will
 update its ARP cache to map the sending
mobile’s home address to the HA’s hardware
address
 these nodes will forward future packets
addressed to the mobile’s home address to the
mobile’s HA
 Issue-2
 if a node on a mobile’s home network does not
have the mobile’s hardware address in its ARP
cache
 when it wants to send a packet to the mobile, this node
will use ARP to find the mobile’s hardware address
 however, when the mobile is away from the home
network, the mobile will not be able to reply to the
ARP REQUESTs sent by nodes on the home network
 Resolution-2 (Proxy ARP)
 a Proxy ARP packet is an ARP REPLY message sent by
one node on behalf of another node in response to an
ARP REQUEST
 when the HA receives an ARP REQUEST asking for
hardware address of the mobile that is away from the
home network, the HA will reply to this ARP
REQUEST on behalf of the mobile
 the HA will set the Sender Protocol Address (IP address)
and the Sender Hardware Address of this ARP REPLY
message to the HA’s own IP and hardware addresses,
respectively
 those nodes that receive the ARP REPLY message will
forward packets addressed to the mobile’s home address
to the HA
2.2.4 Entering and Staying in a
Visited Network
 Upon entering a visited network
 a mobile must acquire a temporary CoA from the
visited network to receive packets from the visited
network
 the mobile will then register its new CoA with its
HA
 this registration serves as a location update and will
cause the HA to tunnel packets addressed to the
mobile’s home address to this new CoA
 Two messages for registration
 Registration Request
 Registration Reply
 Registration Request and Registration Reply
messages are transported over UDP to a port
number 434
 Registration request & reply
 a mobile sends a Registration Request message to
its HA to register its current CoA
 upon receiving a Registration Request message, the
HA authenticates the mobile
 if the authentication is positive, the HA will use this
CoA to update the mobile’s CoA
 the HA will then return a Registration Reply
message to the mobile
 A mobile may register its current CoA
 with its HA directly
 send Registration Request messages directly to
the HA without having to go through a FA
 through a FA
 send Registration Request messages first to a FA
and then forward them to the mobile’s HA
 Mutual authentication
 HA authenticates all Registration Requests it
receives
 mobile authenticates all Registration Reply
messages it receives
 protections against a range of security attacks
 redirection attack
 protect against malicious users from sending
Registration Requests to a HA to cause
packets to another redirected mobile user
 denial of service (DOS)
 protect a malicious user from pretending to be
a HA to conduct “denial of service” attacks
by rejecting its Registration Requests
MIPv4 Registration Request
Message Format
Fields and Flags
 Type
 1, indicate whether this is a MIPv4 Registration
Request
 S (Simultaneous bindings)
 set, if a mobile requests its HA to maintain multiple
care-of addresses for the mobile at the same time
 when the HA intercepts a packet addressed to the
mobile’s home address, it will tunnel a copy of the
packet to each currently registered care-of address
 B (Broadcast datagrams)
 set, if the mobile requests that the HA tunnel to it
any broadcast datagrams that it receives on the
home network
 D (Decapsulation by mobile terminal)
 set, if the mobile will itself decapsulate datagrams
that are sent to the co-located care-of address
 M (Minimal encapsulation)
 set, if the mobile requests that its HA use Minimal
Encapsulation for datagrams tunneled to the mobile
 G (GRE encapsulation)
 set, if the mobile requests that its HA use GRE
encapsulation for datagrams tunneled to the mobile
node
 r
 set to zero and ignored on reception
 not used for any other purpose
 T
 reverse tunneling requested
 x
 set to zero and ignored on reception
 not used for any other purpose
 Lifetime
 number of seconds remained before registration is
expired
 a zero lifetime indicates a request for deregistration
 Home Address
 if a mobile has a preconfigured home address
 it may put its home address in the Home Address
field
 if the mobile does not have a preconfigured home
address
 the mobile sets the Home Address field to
0.0.0.0
 the mobile should specify its NAI (Network
Access Identifier) in the Registration Request
message
 Home Agent
 if the mobile knows the address of its HA
 the Home Agent field contains the IP address of
the mobile’s HA
 if the mobile does not know the address of its HA
 use Dynamic Home Agent Address Resolution
to discover the HA’s address
 Care-of Address
 the mobile’s CoA
 Identification
 a 64-bit number
 used for protecting against replay attacks of
registration messages by matching Registration
Requests (mobile) with Registration Replies (HA)
 Extension
 one or more extension fields
 used to support future enhancement
 Mobile-Home Authentication Extension
 a mandatory extension in every Registration
Request message
 used by HA to authenticate Registration Request
MIPv4 Registration Reply Message Format
Fields
 Type
 3, indicate whether this is a MIPv4 Registration
Reply message
 Code
 indicate the result of the corresponding Registration
Request
 Lifetime
 for successful registration
 contain the number of seconds remained before
registration is expired
 for failed registration
 should be ignored
 0
 indicate that the mobile has been deregistered
 Home Address
 the mobile’s home address
 Home Agent
 the IP address of the mobile’s HA
 Identification
 a 64-bit number
 used for protecting against replay attacks of
registration messages by matching Registration
Requests (mobile) with Registration Replies (HA)
 Extension
 Mobile-Home Authentication Extension
 a mandatory extensions field to be carried in
every Registration Reply message
 used by a mobile to authenticate the Registration
Reply message
2.2.5 Returning to the Home Network
 When a mobile returns to its home network
 packets addressed to its home address will now be
forwarded to itself directly, rather than to its HA
 Two steps to take
 those nodes on the home network, which cache IPto-hardware address binding, will start to send
packets directly to the mobile rather than to the HA
 the mobile should inform its HA to remove the
obsolete states for the mobile
2.2.6 Mobile-Home Authentication
Extension
 Used to authenticate Registration Request and
Registration Reply messages
Mobile-Home Authentication
Extensions to Mobile IP Messages
Fields
 Type
 32, indicate a Mobile-Home Authentication Extension
 Length
 length in octets of the extension from the beginning of
the SPI field to the end
 Security Parameter Index (SPI)
 a four-octet identifier used to identify a security context
between a mobile and its HA
 SPI identifies the authentication algorithm and the secret
used by the mobile and its HA to compute the
Authenticator
 Authenticator
 a number calculated by applying an authentication
algorithm on the message that needs to be protected
 protect the following fields of a Registration Request or
a Registration Reply message
 the data of the Registration Request or the
Registration Reply
 all other Extensions to the Registration Request or
the Registration Reply message prior to the MobileHome Authentication Extension
 the Type, Length, and SPI fields of this MobileHome Authentication Extension
Fields Protected by MIP
Mobile-Home Authentication Extension
2.2.7 Vendor/Organization Specific
Extensions to Mobile IP Messages
 Allow network equipment vendors and other
organizations (e.g., network operators) to
 add their specific information to the Mobile IP
signaling messages (i.e., Registration Request,
Registration Reply, Agent Advertisement messages)
 implement creative mobility control capabilities in
addition to the basic mobility control capabilities
 Two Vendor/Organization Specific Extensions have
been defined in IETF RFC 3115
 Critical Vendor/Organization Specific Extensions
(CVSE)
 Normal Vendor/Organization Specific Extensions
(NVSE)
Critical Vendor/Organization Specific
Extensions (CVSE)
CVSE Fields
 Type
 37, the CVSE-TYPE-NUMBER
 Reserved
 reserved for future use
 set to 0 by the sender and must be ignored on
reception
 Length
 length in bytes of this extension, not including the
Type and Length bytes
 Vendor/Org-ID
 the identifier of the vendor or organization that is
using this extension
 Vendor-CVSE-Type
 the particular type of this CVSE
 a vendor may assign and use different types of
CVSEs
 Vendor-CVSE-Value
 vendor/organization-specific data
 it may contain zero or more octets
Normal Vendor/Organization Specific
Extensions (NVSE)
NVSE Fields
 Type
 133, the NVSE-TYPE-NUMBER
 Length
 length in bytes of this extension, not including the
Type and Length bytes
 Reserved
 reserved for future use
 set to 0 by the sender and must be ignored on
reception
 Vendor/Org-ID
 the identifier of the vendor or organization that is
using this extension
 Vendor-NVSE-Type
 the particular type of this NVSE
 a vendor may assign and use different types of
NVSEs
 Vendor-NVSE-Value
 vendor/organization-specific data
 it may contain zero or more octets
2.2.8 Reverse Tunneling
 Reverse tunneling
 tunnel a mobile’s outgoing packets from the
mobile’s CoA back to the mobile’s HA
 the HA will then decapsulate the packets and route
the original packets to their final destinations
 IETF RFC 3024
 specifies how reverse tunneling works when a
mobile uses Foreign Agent CoA
 a mobile arrives at a visited network
 listen for Agent Advertisement messages
 select a FA that supports reverse tunnels
 a FA informs visiting mobiles that it supports
reverse tunneling by
 setting the “T” flag in the Agent Advertisement
messages it sends to the mobiles
 the mobile requests the reverse tunneling service
when it registers through the selected FA
 by setting the “T” flag in the MIPv4 Registration
Request
 Two ways for a visiting mobile to deliver packets to
FA
 direct delivery style
 the mobile
 designate the FA as its default router
 send packets directly to the FA without
encapsulation
 the FA
 intercept these packets
 tunnel them over the reverse tunnel to the
mobile’s HA
 encapsulate delivery style
 the mobile
 encapsulate all its outgoing packets
 send the encapsulated packets to the FA
 the FA
 decapsulate these packets
 tunnel them over the reverse tunnel to the
mobile’s HA
Mobile IPv4 Reverse Tunneling
2.2.9 Limitations of MIPv4
 [Limitation-1] Triangular routing
 packets addressed to a mobile’s home address
→ routed to the mobile’s HA first
→ forwarded to the mobile’s current care-of
address
 could introduce long end-to-end packet delays and
lead to inefficient use of network resource
 solution：route optimization
 [Limitation-2] HA may become a traffic and
performance bottleneck
 all user traffic destined to a mobile outside its home
network have to go through the mobile’s HA
 this makes a HA a potential traffic and performance
bottleneck as the number of mobiles and/or the
traffic volume grow
 [Limitation-3] Potential long handoff delay
 when a mobile changes its CoA (e.g., handoffs to
another IP subnet), it has to register its new CoA
with its HA
 if the foreign network is far away from the mobile’s
home network
 could introduce a long delay registration process
 may be unacceptable to on-going real-time
sessions of voice or multimedia applications
 solution：micromobility management protocols
 [Limitation-4] Potential insufficient deregistration
capability
 after a mobile is registered through a FA, the
mobile may move into a new network
 in basic MIPv4, the mobile does not explicitly
deregister with the FA in the old network
 this registration expires only when its lifetime
expires
 it’s difficult for a visited network to determine
when a mobile left the network
 [Limitation-5] Insufficient capabilities to support other
mobility management requirements
 example, current MIPv4 does not support dormant
mobiles
 a dormant mobile exchanges limited information
infrequently with network in order to save scarce
resources (e.g., power)
 network may not know the precise location of
this dormant mobile
 network needs to perform paging to determine the
mobile’s precise location when it has packets to
send
 solution
 to support dormant mobile terminals, IP paging
protocols are required
2.2.10 MIPv4 Route Optimization
 A correspondent node knows a mobile’s current CoA
→ tunnel packets to the destination mobile’s CoA directly
 A correspondent host may maintain a Binding Cache that
maps the mobiles’ home addresses to their CoAs
 When a packet is to be sent, the correspondent host will
first search its Binding Cache for the mobile’s CoA
 if the search is found, the correspondent host will tunnel
the packets to the mobile’s CoA directly
 otherwise, it will send the packet to the mobile’s home
address as in the basic MIPv4
MIPv4 Route Optimization
2.3 MIPv4 Regional Registration
 Problem
 a mobile has to register with its HA every time it
changes its CoA
 this could introduce long handoff delay when the
visited network is far away from the mobile’s home
network
 MIPv4 Regional Registration
 extend the basic MIPv4 protocol to allow a mobile
to register its new CoA locally with its visited
network domain
 network domain
 a collection of networks sharing a common
network administration
MIPv4 Regional Registration
 Each network domain consists of a two-level hierarchy
of FAs
 top level：Gateway Foreign Agents (GFAs)
 each domain will have at least one GFA
 GFAs are the FAs that directly interact with
visiting mobiles’ HAs outside the domain
 a GFA must have a publicly routable IP address
 lower level：any number of FAs
 A mobile inside a visited domain will have two CoAs
 GFA address: the mobile will register the address of a
GFA in the visited domain as its CoA with its HA
 local CoA: a local CoA is an address used by the mobile
to receive packets over a network inside the visited
domain
 MIPv4 Agent Advertisement message is extended to
include a flag “I” to indicate whether the domain supports
MIPv4 Regional Registration
 The mobile can learn the GFA address in one of the
following ways
 from Agent Advertisement messages
 these messages are extended to carry GFA address
 dynamically assigned by visited network
 the mobile sets the CoA field in its Registration
Request to zero to require the visited network to
dynamically assign it with a GFA address
 FA will add the following extensions to the received
Registration Request message and then relay this
message with the added extensions to the GFA
 a GFA IP Address Extension
 contain the address of the assigned GFA
 a Hierarchical Foreign Agent Extension
 contain the address of the FA
 MIPv4 Regional Registration introduces two new
messages
 Regional Registration Request
 mobile → FA → GFA
 initiate regional registration
 Regional Registration Reply
 GFA → mobile
 respond to a Regional Registration Request
2.4 Paging Extensions to Mobile IPv4
 Mobile IP can be extended to support paging
 P-MIP (Paging in Mobile IP) is one set of paging
extensions to Mobile IPv4
 P-MIP
 mobile
 a mobile can be in active or idle state
 active state
 mobile operates in the same manner as in
standard Mobile IP without P-MIP
 idle state
 mobile may not perform MIP registration
 a mobile uses an Active Timer to determine
whether it should be in active or idle state
 it stays in active state for an Active Timer period
and changes into idle state when its Active
Timer expires
 each time a mobile sends or receives a packet, it
restarts its Active Timer
 an idle mobile transitions into active state
whenever it receives or sends any packet
 Registered FA
 the FA through which a mobile performed its
last Mobile IP registration
 use an Active Timer to determine whether the
mobile is active or idle
 each time this FA sends a packet to or receives a
packet from the mobile, it restarts the Active
Timer for the mobile
 P-MIP requirement
 an FA is required on each IP subnet
 mobiles can only use FA CoAs and have to perform
Mobile IP registration through FAs
 Paging Areas
 FAs are grouped into Paging Areas
 each Paging Areas is identified by a unique Paging
Area Identifier (PAI)
 Requirement of MIP registration
 No
 if an idle mobile moves from one IP subnet to
another inside the same paging area
 Yes
 if an idle mobile moves into a new paging
area
Paging Extensions to Mobile IPv4
 P-MIP procedure (deliver packets to idle mobiles)
 sending
 packets → mobile’s HA → mobile’s CoA (the
mobile’s Registered FA) → Registered FA
checks if the mobile is active or idle → mobile’s
home address
 if the mobile is active
 mobile's Registered FA will forward the packets
over its own local network directly to the mobile
 if the mobile is idle
 mobile's Registered FA will
 broadcast a Paging Request over its own local
network, and
 unicast a Paging Request to every FA in the
same Paging Area
 note：there is no requirement of MIP
registration if an idle mobile moves from one
IP subnet to another inside the same paging
area
 when an idle mobile receives a Paging Request, it
will transit into active mode
 Limitations on Active Timers
 setting of Active Timer
 value of Active Timer depends on the
application traffic
 example, value of Active Timer of sending and
receiving a stream of packets should be longer
than that of inter-packet arrival, so that no extra
paging will be needed before the last packet of
the packet stream is received by the mobile
 different applications generate different types of
traffic with widely varying inter-packet arrival
times
 mobiles should dynamically adjust the value of
Active Timer by sending signaling messages to
inform its Registered FA of the new Active
Timer value
 consistency of Active Timers
 the value of the Active Timer maintained on the
mobile should be about the same as that used by
the mobile’s Registered FA
 this requires an FA to know the value of the
Active Timer for each mobile
 preconfigure such Active Timer values on all
FAs for every mobile does not seem to be a
scalable approach
2.5 Mobile IPv6
 Mobile IPv6
 use the same concepts of home networks and home
addresses as in MIPv4
 ensure that a mobile can receive packets addressed
to its home address regardless of where it is
 make a mobile’s movement transparent to upper
layer protocols and applications
 Basic concept
 mobile
 has a home network and a home address
 mobile’s home address
 does not need to change regardless of where the
mobile is
 correspondent node
 can always address packets to a mobile’s home
address
 when a mobile moves into a foreign network
 it acquires a IPv6 CoA to receive packets from
foreign network by registering its current CoA
with its HA
 binding
 association between a mobile’s home address
and its CoA
MIPv6 Address Binding with
Home Agent
 Address binding
 as a mobile changes its CoA
 mobile sends a Binding Update (BU) message to
its HA to register its current CoA
 HA returns a Binding Acknowledgment (BA)
message to inform the mobile of the status of the
Binding Update
 Authentication
 HA authenticates every BU message it receives
 mobile authenticates every BA it receives
 authentication of BU and BA messages is achieved
using IPsec
 IP Security (IPsec)
 IETF develops IP Security (IPsec) to secure IP
packet transmissions
 IPsec provides data origin authentication, replay
protection, data integrity, data confidentiality, and
access control
 IPsec is a suite of protocols for protecting IP
datagrams and higher-layer protocols
 it consists of security protocols, authentication and
encryption algorithms, security associations, and
key management
 IPsec is optional for IPv4 but mandatory in IPv6
 Security protocols
 Authentication Header (AH)
 support data integrity and authentication of
packets
 Encapsulating Security Payload (ESP)
 mainly provide confidentiality services,
including confidentiality of message content and
limited traffic flow confidentiality
Family of IPsec Protocols
Note: Security
 Different facets of network security
 authentication
 an ability for communicating parties, including network
operators and users, to validate each other’s authentic
identity
 authorization
 the ability for a party (e.g., a network provider) to determine
whether a user should be allowed to access particular
networks, network services, or information
 also referred to as access control
 integrity
 protection of information from unauthorized change
 confidentiality or privacy
 keep the information private such that only authorized users
can understand it
 confidentiality is also referred to as privacy
 confidentiality is often achieved by encryption
 availability
 the network operators should prevent outside malicious
users from blocking legitimate access to a network or a
network service
 denial-of-service, for example, will deter legitimate users
from accessing the network information and resources
 nonrepudiation
 the ability for a network to supply undeniable evidence
to prove the message transmission and network access
performed by a user
 Security attacks (active attack)
 denial-of-service (DoS)
 prevent a service from being provided to one or more
users or to cause significant disruptions to the services
 example, an attacker may initiate a large number of
connections to a target destination continuously to
overload the target to make it impossible or difficult
for the target to provide any service
 legitimate users, therefore, are deterred from network
access
 masquerade
 an attacker first acquires the identity of a legitimate
user
 it then pretends to be an authorized user to access the
network information and resources
 man-in-the-middle
 an attacker positions forces between communicating
parties to intercept and manipulate the messages
transmitted between the communicating parties
 example, the attacker may delay, modify, or counterfeit
the messages
 the attacker may also divert the messages to other
locations before relaying them between the legitimate
communicating parties
 before such attacks are detected, the legitimate
communicating parties believe that they are still
sending messages to each other directly
 replay
 an attacker intercepts and records the legitimate
transmission
 the attacker then replays (i.e., resends) the messages
later on
 using replay attacks, an attacker could pretend to be an
authorized user to access a network or information
even when the captured transmission was encrypted
and even when the attacker does not know the security
key needed to decrypt the captured transmission
 example, an attacker could replay a banking transaction
to duplicate the previous transaction
 MIPv6 does not use FAs
 in IPv6 network, mobiles use only co-located CoAs,
and no need of FA CoAs
 mobiles can use IPv6 Neighbor Discovery to detect
movement
 MIPv6 supports two modes of operation
 bi-directional tunneling mode
 route optimization mode
MIPv6 Bi-directional Tunneling Mode
 Similar to how MIPv4 works when using a co-located
CoA
 It treats a mobile destination in exactly the same way it
treats a fixed destination
 Correspondent host sends packets to mobile
 it always uses the mobile’s home address as the
destination address
 packets will be routed via regular IPv6 routing to
mobile’s home network
 if the mobile is inside its home network
 packets will be delivered to mobile via
regular IPv6 routing protocols without MIPv6
 if the mobile is outside its home network
 HA intercepts the packets
 tunnel packets to mobile
 Mobile sends packets to correspondent host
 while a mobile is away from its home network
 packets are tunneled to mobile’s HA first
 HA then uses regular IPv6 routing to route these
packets toward their final destinations
MIPv6 Route Optimization Mode
 Operation
 a mobile will register its binding not only with its
HA but also with its correspondent hosts
 packets from a correspondent host can be routed
directly to the CoA of the destination mobile
 Before a correspondent host has the binding for a
mobile
 it will address packets to mobile’s home address
 initial packets are tunneled by HA to the mobile
 mobile can then send binding to correspondent host
for it to sent future packets directly to mobile
 To support route optimization
 MIPv6 requires each IPv6 host and MIPv6 HA to
use a binding cache to maintain binding information
 when an IPv6 terminal wishes to send packets to
another IPv6 terminal, it first checks its binding
cache to see if it has a binding for the destination
 if it does, packets are addressed to the
destination’s CoA directly
 if it does not, packets are addressed to the
destination’s home address
2.5.1 Movement Detection
 The basic approach used by an IPv6 mobile for
movement detection is IPv6 Neighbor Discovery
 IPv6 Neighbor Discovery
 enables an IPv6 terminal to discover new IPv6
routers and determine if a router is reachable (i.e.,
terminal and router can receive packets from each
other)
 an IPv6 router broadcasts Router Advertisement
messages to mobiles on that local network
 these advertisement messages
 carry the IPv6 addresses of the router and
network prefixes that can be used by mobiles to
configure their CoA
 help a mobile to discover new IPv6 routers
 also help a mobile to detect whether an IPv6
router is still reachable, i.e. whether it has moved
out of a network or moved into a new network
 A mobile can probe the network to see if there are
reachable routers by broadcasting Neighbor
Solicitation messages
 upon receiving such message, a router will send
Router Advertisement messages to the mobile
 A mobile may use other means to help movement
detection
 example, a handoff at the lower layer (e.g., change
of radio channels, radio cells, or radio interfaces on
the mobile) can be used as an indication that the
mobile may have moved into a new IP network
 A mobile can acquire an IPv6 CoA by using
 auto-configuration
 combine a network prefix received in the Router
Advertisement messages with the mobile’s own
hardware address
 DHCPv6
2.5.2 Sending Packets Directly to Mobile’s
Care-of Address
 When a correspondent host has a binding for a mobile
 the host can address packets directly to the mobile’s
CoA
 In IPv6, a routing header is used by a source node
 to list one or more nodes that should process the
packet (or the nodes to be visited by the packet), in
addition to the node identified by the destination
address in the packet header
 A routing header is inserted between the IPv6
header and the header of upper layer protocol
(e.g., UDP or TCP)
IPv6 Packet傳送架構
Next Header (8 bits)
值(10進位)
0
6
17
41
43
44
46
50
51
58
59
60
下一個標頭的種類
Hop By Hop Option Header
TCP
UDP
Capsule IPv6 Header
Routing Header
Fragment Header
Resource Reservation Protocol
Security Payload Capsule Header (RFC2406)
Authentication Header (RFC2402)
ICMPv6
No Next Header
Destination Option Header
IPv6封包延伸標頭的例子
IPv6 header
CoA
Routing header
Home address
 When a correspondent host sends a packet directly to a
mobile
 it uses the mobile’s CoA as the destination address
in the IPv6 header of the packet
 the mobile’s home address will be carried in a
routing header defined by MIPv6
 When the packet arrives at the destination mobile’s
CoA
 it will process the routing header and know where is
the mobile’s home address
IPv6 header
Home address
 it replaces the IPv6 destination address in the IPv6
header with the mobile’s home address
 decrements the Segments Left field in the
routing header by one
 0, indicating that the mobile’s home address is
the final destination
MIPv6 Routing Header Format
Fields
 Next Header
 8-bit code
 identifies the type of header immediately following
the routing header
 Header Extension Length
 8-bit unsigned integer
 indicates the length of the routing header in eightoctect units, not including the first eight octets
 Routing Type
 type of the routing header
 Segments left
 8-bit unsigned integer
 indicates the number of nodes listed in this routing
header that are still to be visited
 1, this MIPv6 routing header will carry only a
single home address
 Reserved
 32-bit field
 reserved for future use
 Home Address
 home address of the destination mobile
2.5.3 Sending Packets while Away
from Home
 When a mobile is away from its home network and
wants to send a packet to a correspondent host or the
mobile’s HA
 the mobile may use its current CoA as the source
address in the packet header and pass to the access
routers in a visited network without using reverse
tunneling
 MIPv6 uses IPv6 Destination Options Header
 Header carries optional information to be examined
only by destination node
 Header is placed between IPv6 header and the
header of upper layer protocols (e.g., UPD)
 MIPv6 defines a Home Address Option that will be
carried inside an IPv6 Destination Option Header
 when a mobile is away from its home network and
wants to send a packet, it uses the Home Address
Option to inform the packet’s recipient of the
mobile’s home address
Format of IPv6 Destination Options Header
Carrying a Mobile IPv6 Home Address Option
Fields
 Next Header
 8-bit code
 identifies the type of header immediately following
the destination options header
 Header Extension Length
 8-bit unsigned integer
 indicates the length of the destination options
header in eight-octect units, not including the first
eight octets
 Option Type
 identifies the type of the Option carried in IPv6
Destination Options Header
 201, defined by MIPv6
 Option Length
 8-bit unsigned integer
 indicates the length of the Home Address Option in
octets, excluding the Option Type field and the
Option Length field
 Home Address
 the home address of the mobile sending the packet
 When a correspondent host (or a HA) receives a packet
that carries a MIPv6 Home Address Option
 if it does not have a binding entry for the home
address carried in Home Address Option
 it drops the packet
 if it has a binding entry for the home address
 it replaces the source address in the packet
header with the home address carried in the
Home Address Option
2.5.4 Formats of Binding Update and
Binding Acknowledgment Messages
 MIPv6 Binding Update (BU) and Binding
Acknowledgment (BA) messages
 transported inside a special IPv6 extension header,
the Mobility Header defined by MIPv6
 Mobility Header
 placed between IPv6 header and upper layer
protocol (e.g., UDP or TCP) header of a user IPv6
packet
Mobile IPv6 Mobility Header
Fields
 Payload Protocol
 8-bit value
 identifies the type of the header immediately
following the Mobility Header
 Header Length
 8-bit unsigned integer
 represents the length of the Mobility Header in
units of octets, excluding the first eight octets
 must be a multiple of eight octets
 Mobility Header Type
 8-bit value
 identifies the type of mobility message in the
Message Data field
 Reserved
 8-bit field
 reserved for future use
 Checksum
 16-bit unsigned integer
 checksum of the Mobility Header
 Message Data
 a variable-length field
 contains a specific mobility message, such as a BU
message or a BA message
 Note：a checksum is a form of redundancy check, a very
simple measure for protecting the integrity of data by
detecting errors in data
Format of Mobile
IPv6 Binding Update message
Fields
 Sequence Number
 16-bit unsigned integer
 used by receiving node to sequence BU messages
 used by sending node to match a returned BA
message with a BU message
 A (acknowledge)
 1-bit flag
 set by sending node to request a BA message be
returned by receiving node upon receipt of BU
message
 H (Home Registration)
 1-bit flag
 set by sending node to request that the receiving
node act as the sending node’s HA
 L (Link-Local Address Compatibility)
 1-bit flag
 set when the home address reported by mobile node
has the same interface identifier as the mobile
node’s link-local address
 interface identifier
 a number used to identify a node’s interface on a
link
 the remaining low-order bits in the node’s IP
address after the subnet prefix
 link-local address
 an address that is only valid within the scope of a
link, such as one Ethernet segment
 K (Key Management Mobility Capability)
 1-bit flag
 only valid in a BU message sent to a HA
 set by the sending node to indicate whether the
protocol used for establishing the IPsec security
association between a mobile and its HA can
survive movement
 Reserved
 reserved for future use
 Lifetime
 16-bit unsigned integer
 indicates the number of time units remaining before
the binding expires
 Mobility Options
 a variable-length field that contains one or more
Mobility Options in a Type-Length-Value format
 used to carry
 information needed for MIPv6 mobility
management such as a mobile’s CoA
 security-related information needed for a
receiving node to authenticate a received
message
 examples of Mobility Options
 Alternative CoA option
 used to carry a mobile’s CoA
 Binding Authorization Data option
 used to carry security-related information
needed by the receiving node to authenticate
and authorize BU message
 Nonce Indices option
 a nonce is a random number used by a
correspondent node to help authenticate a BU
from a mobile
 this option is only used when BU message is
sent to a correspondent node
 the correspondent node uses the information
carried in this option with the information
carried in the Binding Authorization Data
option to authenticate a BU message from a
mobile
Formats of Mobile IPv6 Alternative CoA
Option and Binding Authorization Data Option
Alternative CoA Option Format
 Type
 3, identifies an Alternative CoA option
 Length
 length in octets of the portion of this option starting
immediately after the Length field
 16, means exactly one CoA will be carried in the
option
Binding Authorization Data Option Format
 Type
 5, indicates a Binding Authorization Data option
 Option Length
 length in octets of the Authenticator field
 Authenticator
 a cryptographic value used to determine that the
message comes from a right user
 Protects the following mobility data fields
 Care-of Address
 final destination address of the packet
 Mobility Header Data
 the content of the Mobility Header excluding
the Authenticator field
Format of Mobile IPv6
Binding Acknowledgement Message
Fields
 Status
 an 8-bit unsigned integer
 indicating the status of how the corresponding BU
message is processed
 K
 indicate whether the protocol used by a HA for
establishing the IPsec security association between
the mobile and the HA can survive movement
 Reserved
 reserved for future use
 Sequence Number
 copied from the Sequence Number field of the
corresponding BU message
 Lifetime
 the time, in units of 4 seconds, for which the sender
of this BA message will retain the binding of the
receiving node of this BA message
 Mobility Options
 a variable-length field that
 one or more Mobility Options in a Type-LengthValue format
 A BA message may carry the following Mobility
Options
 Binding Authorization Data option
 used to carry the security-related information for
the receiving node to authenticate the BA
message
 Binding Refresh Advice option
 used by a HA to inform a mobile how often the
mobile should send a new BU message to the
HA
 this option is only used in a BA sent by a HA to
a mobile in response to a received BU message
2.5.5 Hierarchical Mobile IPv6 Registration
 When a mobile is far away from its HA
 the process of binding update with HA may
experience a long delay
 One approach to reduce binding update delay
 implement local HAs dynamically using the
“forwarding from the previous CoA”
Mobile IPv6 “Forwarding from Previous
Care-of Address" Mechanisms
 Assumptions on a mobile
 original home network is Subnet A
 original home agent, HA A, is in Subnet A
 mobile movement：Subnet A → Subnet B → Subnet C
 Scenario
 while a mobile in Subnet B
 acquires a CoAB
 performs a binding update with original home agent
HA A
 register CoAB as its primary CoA
 When the mobile moves into Subnet C
 acquires a new CoAC
 the mobile does not have to perform address
binding with home agent HA A
 it may send a Binding Update to home agent HA
B to request HA B to serve as the HA for CoAB
and use CoAC as the current care-of address for
CoAB
 packets addressed to the mobile’s home address
continue to be routed to mobile’s home network,
where they will be captured by mobile’s HA
 HA continues to use CoAB as the primary careof address for the mobile and tunnel intercepted
packets to CoAB, i.e., to HA B
 HA B will extract the original packets from the
tunnel and then tunnel them to the mobile’s
current CoAC, i.e., to the mobile itself
 The “forwarding from the previous CoA” may be used
to support hierarchical registration
 consider that the mobile subsequently moved from
Subnet C to a new subnet D
One Approach to Support Hierarchical
Mobile IPv6 Registration
 Upon entering subnet D
 mobile will acquire a new CoAD
 mobile can choose to make HA B its local HA and
register its new CoAD with this local HA only
 mobile uses “forwarding from the previous CoA”
 it sends a Binding Update message to HA B to
use its CoA to update the CoA for its CoAB
 when HA B receives packets that are addressed to
CoAB
 it will tunnel them to the mobile’s CoAD
2.6 SIP-Based Mobility Management
 MIPv4 and MIPv6
 IP-layer protocols
 Session Initiation Protocol (SIP)
 application-layer protocol
 used to support mobility over IP networks
 used for signaling and control of real-time voice
and multimedia applications over
 IP networks
 3GPP
 3GPP2
SIP
 An application-layer protocol that can establish,
modify, and terminate multimedia sessions
(conferences) over the Internet
 a multimedia session is a set of senders and
receivers and the data streams flowing from the
senders to the receivers
 example, a session may be a telephony call between
two parties or a conference call among more than
two parties
 SIP can also be used to invite a participant to an ongoing session such as a conference
 SIP messages could contain session descriptions such
that participants can negotiate with media types and
other parameters of the session
 SIP provides its own mechanisms for reliable
transmission and can run over several different
transport protocols such as
 TCP
 UDP
 SCTP (Stream Control Transmission Protocol)
 SIP is compatible with both IPv4 and IPv6
 SIP provides the following key capabilities for
managing multimedia communications
 determine destination user’s current location
 determine whether a user is willing to participate in
a session
 determine the capabilities of a user’s terminal
 set up a session
 manage a session
 modify the parameters of a session
 invoke service functions to provide services to a
session
 terminate a session
 SIP is a client-server protocol that uses a request and
response transaction model
 Four major components in SIP architecture
 SIP user agent
 a user agent (UA) is an Internet endpoint, such
as IP phone, PC, or conference bridge, that is
used to establish, modify, and terminate sessions
 a UA could act as both a user agent client (UAC)
and user agent server (UAS)
 a UAC is a logical entity that initiates a request
 a UAS, on the other hand, generates a response
to a SIP request
 SIP redirect server
 a redirect server is a UAS that generates a
response to redirect a request to other location
 SIP proxy server
 a proxy server assumes the roles of both UAC
and UAS
 it acts as an intermediary entity between other
user agents to route SIP messages to the
destination user
 SIP registrar
 a registrar is a UAS that processes SIP
REGISTER requests
 it maintains mappings from SIP user names to
addresses and is the front end of the location
service
 it is consulted by a SIP server to route messages
SIP in Redirect Mode
SIP in Proxy Mode
2.6.1 Movement Detection
 SIP application to handle mobility
 should detect when the mobile terminal changes its IP
address (e.g., moves into a new IP network) and what the
new IP address will be
 DHCP can help to detect network change and acquire new IP
addresses
 mobile may ask a DHCP server for a new IP address each
time the mobile detects a handoff from one radio cell to
another
 mobile will supply its current IP address as the preferred
address in its request sent to DHCP server
 if the address assigned by the DHCP server is the
same as the mobile’s current IP address, the mobile
is still in the same IP subnet
 otherwise, the mobile assumes that it has moved
into a new IP network
 once the mobile’s IP address changed, the software
on the mobile should inform the SIP application of
the change
 the SIP applications should ensure that
correspondent hosts can establish SIP sessions with
the mobile at its new location
2.6.2 Pre-session Terminal Mobility
 Pre-session terminal mobility
 the ability for correspondent hosts to establish a SIP
session with a mobile regardless of where the
mobile is located currently
 A SIP Redirect Server in a mobile’s home network
 tracks the mobile’s current location
 provides the location information to a caller so that
the caller can contact the mobile at its new location
directly to set up a SIP session
SIP-Based Pre-session Terminal
Mobility Management
 Scenario
① a correspondent user sends a SIP INVITE message
to SIP redirect server in the destination user’s
home network to establish a SIP session
② the SIP Redirect Server returns the destination
terminal’s current location to the correspondent
user
③ the correspondent user sends a new SIP INVITE
message directly to the destination user’s current
location to establish SIP session
④ once the session is successfully established, user
data will flow between the users directly without
having to traverse the SIP redirect server
 Key difference between SIP Redirect Server and
Mobile IP HA in tracking current locations of mobiles
 SIP Redirect Server
 simply tells a caller where a destination is
currently and will not be involved in relaying
user traffic to the destination
 mobility uses Direct Delivery strategy for
delivering a call to a mobile destination
 Mobile IPv4 HA
 will also be responsible for relaying user packets
to destination mobile
 Mobile IPv4 uses the Relayed Delivery strategy
for delivering traffic to a mobile
Location Update for Supporting
SIP-based Terminal Mobility
 SIP Redirect Server learns the user’s current location
from user’s SIP REGISTRATION messages
 whenever a user starts to use a new IP address (e.g.,
mobile terminal changes IP address or user uses a
different terminal), it will register its new IP
address with SIP Redirect Server
 user registration process may be performed directly
with home register or via a SIP Proxy Server in
visited network
 Current location registration
 mobile sends a SIP REGISTRATION message
carrying its current location to its home SIP
Redirect Server
 Home SIP Redirect Server interacts with AAA
servers in the home network to authenticate the user
 if authentication is positive
 Home SIP Redirect Server returns a positive
acknowledgment to the mobile
 location update process is thus completed
2.6.3 Mid-Session Terminal Mobility
Support
 Mid-session (mid-call) terminal mobility
 the ability to maintain an on-going SIP session,
whereas the mobile terminal moves from one IP
subnet to another
 When the mobile changes its IP address in the middle
of an on-going SIP session
 mobile will send a new SIP INVITE message to
invite correspondent host to re-establish SIP session
to mobile’s new location
 Upon receiving such update information and
acknowledging the mobile’s SIP INVITE request
 the correspondent host will start to use the mobile’s
new IP address to address the packets destined to
the mobile
 The mobile will update its location with its home SIP
Redirect Server using location update procedure
SIP-Based Mid-Session
Terminal Mobility Management
2.6.4 Limitations of IP Mobility Using SIP
 Limitation
 Limitation-1
 a mobile using SIP mobility has to register its
new IP address with a SIP server (e.g., a SIP
Redirect Server) in the mobile’s home network
every time the mobile changes its IP address
 this could introduce long handoff delays when
the mobile is far away from its home network
 this could also create a high load on home server
 Resolution
 hierarchical registration is used to reduce the
registration latency
 Limitation-2
 it is difficult for SIP-based mobility
management to keep a TCP session alive while a
mobile changes its IP address
 changing the IP address on either end of a TCP
session will cause the TCP session to break
 with SIP-based terminal mobility, when a
mobile changes its IP address, a correspondent
host will have to address its outgoing packets to
the mobile’s new IP address
 Resolution
 a mobile terminal and a correspondent host uses
a software agent called a SIPEYE agent to hide
the IP address change from the on-going TCP
sessions
 A SIPEYE agent on a terminal operates as follows
 it maintains a list of the on-going TCP connections
on the terminal
 it detects the birth and death of TCP connections by
examining the headers of TCP packets
 for each on-going TCP session, the SIPEYE agent
records the following information
 original IP address of the terminal
 served as a terminal’s source IP address when
the TCP session was initiated
 current IP address of the terminal
 used to receive IP packets from the visited
network
 original IP address of the correspondent host for
this TCP session
 served as correspondent host’s source IP
address when the TCP session was initiated
 when the mobile terminal changes its IP address
 it will send a SIP INFO message to the
correspondent host of each on-going TCP
session to inform them of the mobile’s new IP
address
 the TCP application on the mobile
 does not need to know that the mobile has
changed its IP address
 continues to use its original IP address as the
source IP address in all outgoing TCP packets
 The SIPEYE agent on a correspondent host operates as
follows
 being notified that the mobile has changed its IP
address
 encapsulate each outgoing TCP packet with a new
IP header that carries the mobile’s new IP address
as the destination address
 these packets will be routed via regular IP routing
to the mobile terminal’s new location
 the TCP application on the correspondent host
 does not need to be aware that the mobile has
changed its IP address
 continues to address its outgoing packets to the
mobile’s original IP address
 The SIPEYE agent on the mobile terminal operates as
follows
 receive such an encapsulating packet
 strip off the encapsulating header added by the
correspondent host
 deliver the payload TCP packet to the TCP process
 TCP application
 continue to use the original source and
destination IP addresses throughout the on-going
TCP session without any modification to the
TCP protocol
 allows TCP session to remain alive when the
mobile changes its IP address
 SIPEYE approach has a potentially significant limitation
 it requires a SIPEYE agent to be implemented on
every mobile and every correspondent host
 it’s difficult over a large network such as Internet
2.7 Cellular IP
 With Mobile IP
 when a mobile is far away from its HA and wants to register
new IP address with its HA
 this could lead to long handoff delay
 Cellular IP
 designed to support fast handoff in a wireless network of
limited size (e.g. a network within the same administrative
domain)
 mobile doesn’t need to change its IP address while moving
inside a Cellular IP network, and thus reducing handoff
latency
 Main reason for a mobile to change its IP address when
moving into a new IP subnet
 regular IP routing uses prefix-based routing
 which divides network into subnets and requires
different subnets to use disjoint IP address spaces
 Cellular IP
 a mobile doesn’t need to change its IP address
inside a cellular network
 does not use prefix-based routing
 uses host-specific routing
 network nodes perform routing and packet
forwarding based on the full IP address of each
mobile
 network maintains a host-specific downlink
route to forward packets to each mobile, rather
than maintaining a route for each IP address
prefix
Cellular IP
 Two types of network nodes in Cellular IP network
 Base Stations (BS)
 internal to a Cellular IP network and do not
interface directly with external networks
 can be a wireless access point that provides air
interface to mobiles or a router that does not
have any air interface
 Gateway Router
 interconnects a Cellular IP network with external
IP networks
 Nodes
 use Cellular IP routing protocol to determine
 routes from one node to another
 host-specific downlink route to each mobile
2.7.1 Cellular IP Routing
 Uplink packets
 packets originated from mobiles inside Cellular IP
network
 first routed hop-by-hop to gateway router
 gateway router
 determines where to route the packet and then
forward the packet toward destination
 periodically broadcasts a beacon packet
throughout Cellular IP network
 BS
 records the interface on which the beacon packet
is received
 uses reverse path to forward uplink packets to
router
 Downlink packets
 packets sent over a host-specific downlink route
from gateway router to a mobile inside Cellular IP
network
 host-specific downlink routes are established and
maintained by Cellular IP routing
 each network node maintains a routing cache
 an entry in a routing cache is called a routing
entry
 a routing entry points to the next-hop network
node along host-specific route
 the host-specific downlink route to a mobile is
established when any packet is forwarded from
mobile toward gateway router
 as a packet from a mobile is forwarded toward
gateway router, each network node along the
path packet will create a routing entry that points
to BS from which the packet is received
 Network nodes maintain routes in “soft states”
 routes will be removed if no route-update packet is
received during a predetermined time period
 when a mobile does not have any user packet to
transmit, it may send small special route-update
packets toward gateway to refresh route entries
 Cellular IP integrates location management with
routing
 each time a mobile sends a route-update packet or
any other packet
 the downlink host-specific route for the mobile
will also be updated
 mobile’s location is implicitly maintained by upto-date host-specific downlink route to the
mobile
 The way Cellular IP BSs learn the routes to the
gateway router and to each mobile suggests that the
physical configuration of a Cellular IP network has to
be loop free, i.e., a tree or a string
 otherwise, routing loops may occur
 example
 if there is a physical connection between BSs 3
and 4; i.e., BSs 1, 3, and 4 form a loop
 when gateway router broadcasts beacon packets,
BSs 3 and 4 will receive beacon from each other
 BS 3 will take BS 4 as the next hop to forward
uplink packet, and BS 4 will take BS 3 as the
next hop to forward uplink packet → forms a
routing loop
2.7.2 Handoffs Inside a Cellular IP Network
 Cellular IP supports two types of handoffs
 hard handoff
 semi-soft handoff
Hard Handoff
 Implemented using Break-before-Make strategy
 When a mobile moves from old BS to new BS, it tunes
its radio to new BS
 The packets on the way to old BS may be lost
 Mobile then sends a route-update packet toward
gateway router
 Route-update packet triggers the nodes along its path
to setup a host-specific downlink route for mobile
 the route-update packet will eventually reach a
cross-over node
 cross-over node is a node shared by
 mobile's old downlink host-specific route that
goes to old BS
 mobile's new downlink host-specific route set up
by current route-update packet
 examples
 if mobile moves from BS 3 to BS 4, the crossover node will be BS 1
 if mobile moves from BS 5 to BS 6, the crossover node will be BS 2
 When route-update packet reaches a cross-over node
 this node will update mobile's downlink hostspecific route and start to forward future packets to
mobile's new BS
 packets that have already been on their way to old
BS may be lost
Semi-Soft Handoff
 Allows a mobile to receive packets from old BS before
network sets up its route to new BS
 Mobile
 tunes its radio to new BS
 sends a semi-soft handoff packet via new BS
toward gateway
 tunes its radio back to old BS immediately to
continue receiving packets from old BS while
network is setting up mobile's downlink hostspecific route to new BS
 Semi-soft handoff packet
 triggers nodes on its path to set up a downlink hostspecific route to new BS for the mobile
 when this packet reaches the first cross-over node,
this node will start forwarding packets to both old
and new BSs
 After a predetermined amount of delay (expected
downlink host-specific route setup time)
 mobile disconnects from old BS and tunes its radio
to new BS to receive packets from new BS only
2.7.3 Handoff between Cellular IP Networks or
between Cellular IP and Regular IP Networks
 Handled by a “macromobility” management protocol
(e.g., Mobile IP)
 Mobile inside a Cellular IP network
 uses the IP address of gateway router as its Mobile
IP CoA
 uses its Mobile IP home address to send and receive
packets over Cellular IP network
 Upon entering a new Cellular IP network
 mobile sends a route-update packet toward gateway
router to trigger new Cellular IP network to set up a
downlink host-specific route for the mobile
 Gateway router
 acts as a Mobile IP FA
 sends Mobile IP Agent Advertisement messages
to mobile after it receives the first packet from
mobile
 mobile
 learns the IP address of gateway router from
Advertisement
 uses this address as its new CoA
 registers this address with its HA
 After a successful Mobile IP registration
 packets addressed to mobile's home address will be
tunneled by mobile's HA to mobile's current CoA
(the IP address of gateway router)
 Gateway router will de-tunnel packets and forward
the payload packets along the downlink hostspecific route to mobile directly without
encapsulation or tunneling
2.7.4 Paging
 Dormant (idle) mobile
 a mobile that has not transmitted packets for a
predefined time period (active-state-timeout)
 For a mobile that has not sent packets over active-statetimeout
 its host-specific route will be removed by network
 When a gateway router has packets to send to a mobile
 if the router does not have a valid routing entry for
mobile (i.e., mobile is dormant), it will initiate
paging to locate mobile first
 To support paging
 Cellular IP organizes BSs into paging areas
 when a dormant mobile crosses a paging area
boundary, it updates its location with the network
by sending a paging-update packet to gateway
router
 this packet is addressed to gateway router and
forwarded by BSs hop-by-hop to the router
 A network node may optionally use a paging cache to
maintain paging routes for dormant mobiles
 paging entry in the cache
 points to the next-hop network node along the
paging route to a specific dormant mobile
 paging update packet
 trigger the network nodes, which have paging
caches, to create a new paging entry or update its
existing paging entry
Paging in Cellular IP Networks
 When a node receives a downlink packet to send to a
mobile but does not have a valid routing entry
 the node will check if it has a valid paging entry for
the mobile
 if it does, it will forward a paging message along
the paging route toward mobile
 otherwise, it will broadcast a paging message
over all its interfaces except the one that receives
packets
 When a paging message reaches the first BS in the
dormant mobile's current paging area
 this message will be broadcast over the paging area
to all BSs and, hence, to all mobiles inside the
paging area
 Upon receiving a paging message or any other packet,
a dormant mobile will
 transit into active mode
 start to send route-update packets toward gateway
router
 trigger network to set up and maintain a hostspecific downlink route for the mobile
 The paging entries are maintained as “soft states”
 a dormant mobile may refresh its paging route by
periodically sending paging-update packets to
gateway router
 Paging-update packets cannot be used to update
routing caches
 as a result, a network node may maintain only a
paging entry for a dormant mobile, but it does not
need to maintain any routing entry for the mobile
 this reduces the sizes of the routing caches because
a large percentage of the mobiles may be dormant
at any given time in a real wireless network
 When a BS wants to send a packet to an active mobile
 it only needs to search the routing cache, which
reduces the delay incurred by table lookups at the
BSs
2.8 HAWAII
 Handoff-Aware Wireless Access Internet Infrastructure
 HAWAII and Cellular IP are similar in many ways
 both designed to support fast handoff and paging
inside a wireless network under a single
administrative domain
 use similar techniques
 use host-specific routes to deliver packets to
mobile
 reduce handoff latency by reducing the
frequency of changing IP addresses
 HAWAII and Cellular IP are different in routing and
mobility management implementations
 HAWAII organizes a network into domains
 a HAWAII domain is a network under the control
of one administrative entity and uses HAWAII
internally
 A HAWAII domain consists of three types of
network nodes
 Base Stations (BSs)
 Routers
 Domain Root Routers (DRRs)
HAWAII
 Base Station
 a network node that supports air interface or other
radio specific functions
 Router
 used to interconnect BSs
 Domain Root Router (DRR)
 used to interconnect a HAWAII domain to external
IP networks (e.g., the Internet)
 Mobile
 has a home domain (belongs to mobile's service
provider)
 has an IP address
 could be statically configured when subscribes to
network services
 may also dynamically assigned by DHCP
 while moving inside the same HAWAII domain
 does not need to change IP address
 upon entering a new domain
 has to obtain a new IP address from new domain
 All IP packets originated from or destined to any
mobile inside a HAWAII domain
 will be routed first to DRR in HAWAII domain
 DRR then forwards these packets to destinations
 DRR uses regular IP routing to route packets
destined to external IP networks
 DDR uses a host-specific forwarding route
established by HAWAII Path Setup Schemes to
forward packets destined to a mobile inside
HAWAII domain
 Network nodes maintain host-specific forwarding
routes in soft states
 a network node needs to maintain state information
about a host-specific route only if it is part of that
route
 this reduces state information each router needs to
maintain and thus improves network scalability
 HAWAII uses regular IP routing protocol to route and
forward packets
 example
 IP packets addressed to any HAWAII network
node or to external IP networks will be routed by
regular IP routing protocol
 the physical configuration of each HAWAII
domain can be of any topology as IP routing
creates loop-free routes
2.8.1 Mobile Powers Up in its Home
HAWAII Domain
 When a mobile powers up in its home HAWAII
domain
 it may need to acquire an IP address from its home
domain if it does not already have one
 home HAWAII domain needs to establish a hostspecific forwarding route from DRR to mobile for
packets delivering
HAWAII Mobile Power-up Procedure
Power-Up Procedure
 Step1
 mobile powers up in home HAWAII domain
 mobile sends a MIPv4 Registration Request
(Message 1) to its current BS A
 BS A creates a host-specific forwarding entry for
mobile indicating that the mobile is reachable over
its air interface
 Mobile IP may be used to support handoff between
HAWAII domains
 mobile's Mobile IP HA may be located inside
mobile's home HAWAII domain
 mobile's IP address obtained from home
HAWAII domain can be mobile's Mobile IP
home address
 Mobile IP Registration Request is used only for
triggering HAWAII path setup procedure
 Step 2
 BS A looks up its regular IP forwarding table to
find the next-hop node (“Router 1”) toward DRR
 BS A sends a HAWAII power-up message
(Message 2) to Router 1
 this message triggers Router 1 to create a hostspecific forwarding entry points to BS A
 Step 3
 Router 1 sends a HAWAII message (Message 3) to
its next-hop node (DRR) toward DRR
 Message 3 triggers DRR to create a host-specific
forwarding entry points to Router 1
 Step 4
 DRR sends an ack (Message 4) back to BS A
 Step 5
 BS A sends a MIP Registration Reply to mobile
 From this point on
 DRR will use host-specific forwarding route created
during powering up procedure to forward user IP
packets to mobile
 Network nodes maintain host-specific routes in soft
states
 mobile has to refresh its host-specific route by
sending HAWAII path refresh messages to DRR
periodically
2.8.2 Handoffs Inside a HAWAII Domain
 HAWAII provides two basic path setup schemes to
support handoff
 Forwarding Path Setup Scheme
 Non-Forwarding Path Setup Scheme
HAWAII Forwarding Path Setup Schemes
Forwarding Path Setup Scheme
 Allows old BS to forward user packets to new BS
(which in turn forwards packets to mobile)
 A host-specific route will be established from old BS
to new BS
 Procedure
[Step1]
 when a mobile connects to a new BS B, it sends a
MIPv4 Registration Request message (Message 1)
to new BS
 this message will inform new BS that the mobile's
previous BS was BS A
[Step 2]
 BS B initiates a HAWAII Handoff Message
(Message 2) and sends it to BS A along the route
created by regular IP routing
 BS A uses the IP address of BS B and the
forwarding table generated by regular IP routing to
determine Router 1 as the next-hop router for
forwarding packets to BS B
 BS A then sets up a host-specific forwarding entry
for mobile
 this will allow BS A to forward future packets
destined to mobile to Router 1
[Step 3]
 BS A sends a HAWAII message (Message 3) to
Router 1 to trigger Router 1 to set up a host-specific
forwarding entry for mobile
[Step 4]
 Router 1 uses the IP address of BS B and the
forwarding table generated by regular IP routing to
determine the next-hop router (Router 2) for
forwarding packets to BS B
 Router 1 will establish a host-specific forwarding
entry for mobile and set the next-hop for the hostspecific route to Router 2
 from now on, Router 1 will forward packets
destined to mobile to Router 2
 Router 1 will also send HAWAII message 4 to
Router 2 to trigger Router 2 to create a host-specific
forwarding entry for mobile
[Step 5]
 Router 2 is the cross-over router
 Router 2 will start to forward future packets
destined to mobile along the new host-specific route
to new BS B directly, and then to mobile
[Step 6]
 Router 2 sends a HAWAII message to the next-hop
router (Router 3) along the route toward BS B
 the process continues until a host-specific route is
established from BS A to BS B for the mobile
[Step 7]
 BS B sends a MIP Registration Reply message to
mobile, completing the path setup process
Nonforwarding Path Setup Scheme
 Packets may not be forwarded from old BS to new BS
 When packets destined to mobile arrive at a cross-over
router
 packets will be forwarded by cross-over router to
new BS, and then to mobile
 a cross-over router is a router shared by
 host-specific forwarding route from DRR via old
BS to mobile
 host-specific forwarding route from DRR via
new BS to mobile
 HAWAII defined multiple forms of Nonforwarding
Path Setup Schemes
 Here we focus on Unicast Nonforwarding Scheme
HAWAII Unicast Non-Forwarding
Path Setup Schemes
 Procedure
[Step 1]
 when a mobile moves to BS B, it sends a MIPv4
Registration Request message to BS B to initiate
handoff procedure
 this message will carry the IP address of the old
base station BS A
[Step 2]
 BS B creates a host-specific forwarding entry for
mobile with outgoing interface set to the interface
on which it received Registration Request
 BS B uses the IP address of BS A and looks up the
IP forwarding table established by regular IP
routing to determine the next-hop router (“Router
3”) toward BS A
 BS B then sends HAWAII Message 2 to Router 3
[Step 3]
 Router 3 creates a host-specific forwarding entry
for mobile with the next-hop node set to BS B
 Router 3 then determines the next hop toward BS A
is Router 2 and forwards HAWAII Message 3 to
Router 2
[Step 4]
 Router 2 creates a host-specific forwarding entry
for mobile with outgoing interface set to Router 3
 Router 2 is the cross-over router
 after Router 2 creates the new host-specific
forwarding entry for mobile, it will forward future
user packets destined to mobile to BS B directly
 Router 2 also sends a HAWAII message (Message
4) to the next-hop router (Router 1) toward BS A
[Step 5]
 this process continues until BS A receives a
HAWAII message (Message 5)
[Step 6]
 BS A establishes a host-specific forwarding entry
for mobile and then sends an ack message (Message
6) back to BS B
 this message will trigger BS B to send a MIPv4
Registration Reply message back to mobile to
complete path setup and handoff procedure
2.8.3 Moving into Foreign HAWAII
Domains
 A “macromobility”management protocol such as
Mobile IP can be used to
 support handoff between HAWAII domains
 ensure that a mobile is always addressable by a
permanent home address when it moves into
foreign HAWAII domains
Handoff between HAWAII Domains
Using Mobile IP
Interdomain Handoff Procedure
using Mobile IP
 When a mobile enters a new HAWAII domain
 it first needs to obtain a new IP address from new
HAWAII domain
 this may be achieved using, e.g., DHCP
 After the mobile acquires a new IP address
 the new HAWAII domain needs to set up the initial
host-specific forwarding route from DRR to mobile
 this is achieved using power-up procedure
 When mobile's current BS receives ack message
(Message 4) from DRR indicating that a host-specific
forwarding route has been set up from DRR to mobile
 the BS will forward mobile's Mobile IP
Registration Request message to mobile's Mobile IP
home agent
 The mobile uses the IP address it obtained from new
HAWAII domain as its co-located CoA
 packets addressed to mobile's home address will be
tunneled by mobile's HA to mobile directly
 these packets will enter mobile's current HAWAII
domain via a DRR in the domain
 DRR will forward packets along the host-specific
forwarding route to mobile
 mobile will then de-tunnel packets to extract
original packets
2.8.4 Paging
 HAWAII groups BSs into paging areas
 Each paging area is identified by an IP Multicast
Group Address (MGA) that has a scope of the
administrative domain
 While a mobile is in dormant mode (or standby mode)
 network will only know mobile’s currently located
paging area but not the currently connected BS
 a dormant mobile will send a location update
message toward DRR every time it crosses a paging
area boundary
 location update message is propagated hop-by-hop
from mobile's current BS to DRR
 it triggers BS and each router along its path to
create a new or update its existing host-specific
routing entry and paging entry for mobile
 a routing entry is for forwarding regular user
packets to a mobile
 a paging entry is for forwarding paging messages to
a mobile
 routing entries and paging entries on a network
node are maintained separately
 Paging entry contains the following main information
 the MGA (Multicast Group Address) that identifies
mobile's current paging area
 the outgoing interface for sending paging messages
to mobile
 To page a mobile
 a network node (router or BS) acts as a Paging
Initiator
 a paging initiator is responsible for
 creating a paging message and multicasting it to
the MGA (all the BSs) of paging area
 each BS will in turn send a paging message to
all the mobiles it is serving
 buffering packets destined to a dormant mobile
while the mobile is being paged
 To increase network reliability and scalability
 paging in a HAWAII domain does not use a
centralized paging initiator for all mobiles
 paging initiator functionality is dynamically
distributed to network nodes
 a network node may dynamically elect itself as a
mobile's paging initiator
 before a network node can initiate paging for a
mobile (ensuring paging initiator knows mobile’s
latest paging area)
 only a node along mobile's latest host-specific
paging route (established by mobile's latest
location update) can be paging initiator for
mobile
 a paging initiator initiates paging only when it
receives packets destined to mobile from an
upstream node
 node A is node B's upstream node when both
nodes are on the latest paging route from
DRR to mobile's last-known BS, but node A
is closer to DRR
 Packets originated inside a dormant mobile's current
HAWAII domain have to be routed first to DRR
 DRR will forward packets along mobile's latest
paging route toward mobile's current paging area
 Upon receiving a packet from the DRR
 a router or BS on mobile's latest paging route may
then elect itself as mobile's paging initiator and
initiates a paging message
3. Mobility Management in 3GPP Paket
Networks
 Assumptions
 mobility management in packet-switched (PS)
domain of a 3GPP network (Release 5)
 RAN is assumed to be UTRAN
3GPP Conceptual Network Architecture
(Release 5)
3GPP Network Architecture and Protocol
Reference Model (Release 5)
Components
 Public Land Mobile Network (PLMN)
 a public network administrated by a single network
operator for providing land mobile services
 3GPP PLMN
 consists of one or more Radio Access Networks
(RANs) interconnected via a Core Network (CN)
 RAN
 provides radio resources (e.g., radio channels,
bandwidth) for users to access CN
 Release 5 currently supports GSM/EDGE RAN
(GERAN) and UMTS Terrestrial RAN (UTRAN)
GERAN
 GERAN
 divided into Base Station Subsystems (BSS)
 BSS
 consists of one or multiple Base Transceiver
Stations (BTSs) and Base Station Controllers
(BSCs)
 BSC
 controls radio connections toward mobile terminals
as well as wireline connections toward CN
 each BSC can control one or more BTSs
 BTS
 maintains air interface
 handles signaling and speech processing over air
interface
UTRAN
 UTRAN
 divided into Radio Network Subsystems (RNS)
 RNS
 consists of one or multiple Node Bs controlled by a
Radio Network Controller (RNC)
 RNC
 analogous to a BSC in GSM
 controls radio connections toward mobile terminals
and wireline interfaces with CN
 Node B
 a wireless base station
 analogous to a BTS in GSM
 provides air interface with mobile terminals
Core Network
 CN
 support both circuit-switched (CS) and packetswitched (PS) communication services
 communication services include basic services and
advanced services
 basic CS services
 switching of CS voice and data calls and call
control functions for supporting basic pointto-point CS calls
 basic PS services
 routing and transport of user IP packets
 advanced CS services
 prepaid calls, toll-free calls, call forwarding
(e.g., forward a voice phone call to another
phone or to an e-mail box), multiparty
communications, and pay-per-view
 advanced PS services
 e-mail, World-Wide Web, location-based
services, multimedia messaging services,
network gaming, and e-commerce
 CN is divided into the following functional building
blocks
 circuit-switched domain
 packet-switched domain
 IP Multimedia Subsystem (IMS)
 provides all the network entities and procedures
to support real-time voice and multimedia IP
applications
 uses SIP to support signaling and session control
for real-time services
 Information Servers
 maintain necessary information for network
operations and provide services to users
 these information servers are as follows
 Home Subscriber Server (HSS)
 the connecting element between PS and
IMS domains
 Authentication Center (AuC)
 Equipment Identity Register (EIR)
 In CN, old CS switch, MSC, has been divided into two
logical entities
 MSC server
 control logic is in MSC
 Media gateway (CS-MGW)
 actual switching matrix in MGW
 data typically bypasses the control logic in CN
Protocol Reference Model for
3GPP PS Domain
Packet Data Protocols, Bearers, and
Connections for Packet Services
 A mobile uses a Packet Data Protocol (PDP)
 to exchange user packets over a 3GPP PS CN
domain with other mobiles either inside the same
3GPP network or in other IP networks
 PDP Packet Data Units (PDUs) (i.e. user packets)
 transported inside a 3GPP network over traffic
bearers
 Traffic bearer
 a set of network resources and data transport
functions used to deliver user traffic between two
network entities
 can be a path, a logical connection, or a physical
connection between two network nodes
3GPP Bearers for Supporting PacketSwitched Services
Traffic Bearers Structure Supporting
Packet-Switched Services
 3GPP Bearer
 a dedicated path between mobile and its serving
GGSN
 for a mobile to send or receive packets over a 3GPP
PS CN
 a 3GPP Bearer in a UMTS network would be a
UMTS Bearer
 constructed by concatenating
 Radio Access Bearer (RAB)
 connects a mobile over a RAN to the edge of
CN (i.e., a SGSN)
 CN Bearer
 carries user traffic between the edge of CN
and a GGSN
Signaling and Traffic Connections between
Mobile and SGSN
 The signaling connection between mobile and SGSN is
constructed by concatenating
 Signaling Radio Bearer
 between mobile and RAN (e.g., the RNC in
UTRAN)
 Iu Signaling Bearer
 between RAN and SGSN
 Signaling and traffic connections between mobile and
SGSN
 Radio Resource Control (RRC) connection
 Radio Access Network Application Part (RANAP)
connection
 Radio Resource Control (RRC) connection
 includes Signaling Radio Bearers and Traffic Radio
Bearers for the same mobile
 used to establish, maintain, and release Radio
Bearers
 a mobile will use a common RRC connection to
carry signaling and user traffic for both PS and CS
services
 Radio Access Network Application Part (RANAP)
connection
 includes Iu Signaling Bearers and Iu Traffic Bearers
for the same mobile
 used to establish, maintain, modify, change, and
release all these Iu Bearers
Packet Routing in 3GPP PS Domain
Mobility Management in 3GPP
Packet Networks
 All PS user data to and from a mobile is first sent to a
GGSN called mobile's serving GGSN
 serving GGSN will in turn forward user data toward
their destinations
 mobile and its serving GGSN use a host-specific
route to exchange user data
 mobility management in 3GPP PS domain is to
manage the changes of host-specific route between
each mobile and its serving GGSN
 Host-specific route consists of
 a RRC connection between mobile and RAN
 a RANAP connection between RAN and SGSN
 CN Bearers between SGSN and mobile's serving
GGSN
 Mobile's Serving RNC
 the RNC that receives data from PS CN domain and
then distributes data to mobile
 For a mobile to exchange signaling messages with PS
CN (e.g., to set up and manage traffic bearers, to
perform location update)
 a dedicated logical signaling connection (Signaling
Radio Bearer and Iu Signaling Bearer) needs to be
established between mobile and SGSN
 Mobile
 does not need to maintain all traffic bearers in
RAN or CN if it does not expect to send or receive
user data soon
 does not even need to maintain its dedicated
signaling connection to SGSN at all times
 may release radio resources for other mobiles to use
Scope of Mobility in 3GPP
Packet-Switched Domain
 Scope of mobility
 Inter-Node B handoff
 Inter-RNC handoff
 Inter-SGSN handoff
 Inter-GGSN handoff
 Inter-Node B Handoff
 change mobile's Radio Bearers from source Node B
to target Node B
 Inter-RNC Handoff
 change mobile’s Radio Bearers
 change mobile's Iu Bearers
 Inter-SGSN Handoff
 change Radio Bearers
 change Iu Bearers
 update mobile's PDP context
 establish a new CN Bearer
 Inter-GGSN Handoff
 change Radio Bearers
 change Iu Bearers
 mobile's new serving GGSN creates a PDP context
for mobile
 establish a CN Bearer between mobile's new
serving GGSN and new serving SGSN
3.1 Packet Mobility Management (PMM)
Context and States
 Mobile’s PMM context
 a set of information used by network to track
mobile’s location
 State of a mobile’s PMM context determines
 which network connections (bearers) between
mobile and SGSN should be maintained for mobile
 how mobile’s location should be tracked by
network
 3GPP PS domain
 Mobile
 needs to maintain a PMM context to collaborate
with network for location tracking
 SGSN
 responsible for tracking locations of mobiles that
are using PS services
 needs to maintain PMM contexts of mobiles
 GGSN
 not directly involved in location tracking
 does not need to know any mobile’s PMM
context or PMM state
 A PMM context on mobile or SGSN can be in one of
the following states (for UMTS)
 PMM-DETACHED State
 PMM-CONNECTED State
 PMM-IDLE State
PMM-DETACHED State
 No communication between mobile and SGSN
 Mobile and SGSN do not have valid location or routing
information for mobile
 Mobile does not react to system information related to
SGSN
 SGSN cannot reach mobile
PMM-CONNECTED State
 SGSN and mobile have established
 a PMM context for mobile
 a dedicated signaling connection between mobile
and SGSN
 Signaling connection consists of
 RRC connection between mobile and RAN
 Iu signaling connection over Iu interface between
RAN and SGSN
 PS domain-related signaling and CS domain-related
signaling share one common RRC connection
 one IuCS signaling connection for CS domain
 one IuPS signaling connection for PS domain
PMM-IDLE State
 SGSN and mobile have established PMM contexts for
mobile
 No signaling or traffic connection exists between
mobile and SGSN
 A mobile moves into PMM-IDLE state to conserve
scarce resources, e.g.,
 power off the mobile, reduce transmissions of
signaling messages to conserve radio bandwidth
3GPP PMM State Transition Machines
PMM-DETACHED State to
PMM-CONNECTED State
 When mobile performs GPRS Attach to attach to PS
domain
 GPRS Attach procedure
 a signaling connection needs to be established
between mobile and its serving SGSN
PMM-CONNECTED State to
PMM-IDLE State
 Whenever the signaling connection between mobile
and its serving SGSN is released
 Example
 when GPRS Attach process is finished, this
signaling connection may be released immediately,
which will cause mobile’s PMM state to change
from PMM-CONNECTED to PMM-IDLE
PMM-IDLE State to
PMM-CONNECTED State
 A mobile in PMM-IDLE state may need to establish a
signaling connection to SGSN for various purposes
 example
 a mobile needs to establish a signaling
connection to SGSN to perform routing area
update
 when this signaling connection is not needed in
near future (e.g., after routing area update is
completed), it may be released to allow mobile’s
PMM state to change back to PMM-IDLE
PMM-CONNECTED State to
PMM-DETACHED State
 When GPRS Detach procedure is performed
 When mobile’s GPRS Attach request is rejected by
SGSN
 When mobile’s Routing Area Update (RAU) request is
rejected by SGSN
PMM-IDLE State to
PMM-DETACHED State
 A mobile or a SGSN may change from PMM-IDLE to
PMM-DETACHED as a result of a local event
 Example
 state change on a mobile
 when SIM, USIM, or battery is removed from
mobile
 state change on SGSN
 when the lifetime of PMM state expires
Discussions
 PMM context cannot change from PMM-DETACHED
to PMM-IDLE directly
 before a mobile’s PMM context can be in PMMIDLE state, mobile’s PMM context has to be
created first on SGSN
 to create a PDP context on SGSN, mobile has to
perform GPRS Attach
 this will cause mobile’s PMM state to change from
PMM-DETACHED to PMM CONNECTED first,
before it transits into PMM-IDLE
3.2 Location Management for PacketSwitched Services
3.2.1 Location Concepts
 RANs and CN in 3GPP network use different location
concepts to track mobile’s locations
 RAN uses the following location concepts
 Cell Area (or Cell)
 the geographical area served by one wireless BS
 UTRAN Registration Area (URA)
 covered by a set of cells
 CN uses the following location concepts
 Location Area (LA)
 a group of Cells used by CS CN domain to track
the locations of mobiles that are using CS
services
 Routing Area (RA)
 a group of Cells used by PS CN domain to track
the locations of mobiles that are using PS
services
3GPP Location Management
for Packet Services
 LA
 consists of one or more Cells that belong to the
RNCs that are connected to the same MSC/VLR
 all Cells in the same URA have to be served by the
same MSC/VLR
 one LA is handled by only one MSC/VLR
 each LA is identified by a globally unique Location
Area Identifier (LAI)
 when a mobile moves inside an LA, it does not
have to perform location update with CN CS
domain
 RA
 consists of one or more Cells that belong to the
RNCs that are connected to the same SGSN
 one RA is handled by only one SGSN
 an RA is either the same as an LA or a subset of
one and only one LA
 one RA cannot belong to more than one LA,
whereas each LA may contain multiple RAs
 each RA is identified by a globally unique Routing
Area Identifier (RAI)
Structures of 3GPP Location Area Identifier
and Routing Area Identifier
 LAI
 Mobile Country Code (MCC)
 identifies the country in which the 3GPP
network is located
 Mobile Network Code (MNC)
 identifies a 3GPP network in that country
 Location Area Code (LAC)
 identifies a Location Area within a 3GPP
network
 RAI
 Location Area Identifier (LAI)
 contains an LAI that identifies the Location Area
in which the RA resides
 Routing Area Code (RAC)
 identifies a Routing Area inside the LA
identified by the LAI
3.2.2 Location Tracking
 3GPP uses hierarchical location tracking
 the methods and accuracy level of location tracking
for each mobile depend on activeness level of
mobile
 a mobile’s activeness level is represented by the
mode of its RRC connection
 A mobile’s RRC connection has two modes
 RRC-CONNECTED mode
 a mobile has an established RRC connection
 mobile may be either in PMM-CONNECTED or
PMM-IDLE state because a mobile uses a single
RRC connection for both CS and PS services
 mobile can be in RRC-CONNECTED mode and
PMM-IDLE state at the same time because the RRC
connection may be present but is currently used only
for CS services; i.e., no signaling connection is
established to SGSN
 RRC-IDLE mode
 a mobile has not established any RRC
connection
 mobile’s PMM state can only be PMM-IDLE or
PMM-DETACHED because no signaling
connection between mobile and SGSN can exist
without an RRC connection
Location Tracking Depends on Mobile’s
RRC Connection Mode
 When a mobile is in the RRC-IDLE mode (hence, also
in PMM-IDLE state)
 mobile’s location is tracked at the RA level by
SGSNs
 mobile in RRC-IDLE mode will receive Mobility
Management (MM) system information broadcast
by RNCs at RRC layer
 MM system information informs mobile which RA
and Cell it is in currently
 mobile will initiate RA Update toward CN upon
receiving MM system information, indicating that it
moved into a new RA
 When a mobile is in RRC-CONNECTED mode
 mobile’s location inside RAN is tracked at cell
level by RNCs
 an RNC identifies a mobile by a temporary
identifier, the Radio Network Temporary Identity
(RNTI), to track mobiles
 RNTI is assigned to mobile dynamically by an
RNC
 mobile receives MM system information from
serving RNC over the established RRC connection
 it uses MM system information to determine if it
has moved into a new Cell, RA, or LA
 When a mobile is in RRC-CONNECTED mode and
PMM-IDLE state
 SGSNs will also track the mobile’s location at RA
level
 mobile will initiate RA Update toward CN PS
domain upon receiving MM system information,
indicating that it has just moved into a new RA
 When a mobile is in RRC-CONNECTED mode and
PMM-CONNECTED state
 mobile’s serving SGSN will know the mobile’s
serving RNC because the serving SGSN maintains
a signaling connection through mobile’s serving
RNC to mobile
 when mobile’s serving RNC function needs to be
changed to a new RNC as mobile moves
 mobile’s serving SGSN will participate in this
change process (i.e., Serving RNS Relocation
procedure)
 to ensure that signaling connection between
mobile and SGSN will go through new
serving RNC
 Serving RNS Relocation Procedure
 the process for relocating RNC side of
endpoint of an Iu bearer from one RNC to
another
3.3 Routing Area Update
 Routing area update in 3GPP allows
 mobile’s serving SGSN to know which RA the
mobile is currently in
 mobile’s existing active PDP contexts to be updated
 example
 if moving into a new RA also means that the
mobile has to use a new SGSN
 a PDP context between new SGSN and
mobile’s serving GGSN needs to be
established
 this ensures that the mobile’s serving GGSN
always knows where to forward user packets
destined to mobile
 A mobile performs RA update when
 mobile enters a new RA
 mobile’s periodic routing area update timer expires
 Types of RA update
 Intra-SGSN RA update
 occurs when new RA and old RA connect to the
same SGSN
 Inter-SGSN RA update
 occurs when new RA and old RA connect to
different SGSNs
3.3.1 Intra-SGSN Routing Area Update
 To send uplink signaling messages to perform an RA
update
 the mobile first establishes a RRC connection with
target RNC if such a channel does not exist
 the mobile has to be in PMM-CONNECTED state
for at least the duration of RA Update procedure
 if the mobile is in PMM-IDLE state before it starts
RA Update
 establish necessary signaling connection to
target SGSN
 change mobile’s PMM state into PMMCONNECTED
 Routing Area Update Request (RAUR) carries the
following main information
 P-TMSI (Packet-Temporary Mobile Subscriber
Identity)
 the information that mobile has been using
immediately before sending RAUR message
 mobile’s P-TMSI is assigned by its source
SGSN
 Old RAI
 used by target SGSN to determine whether it is
an intra-SGSN or inter-SGSN RA Update
 Old P-TMSI Signature
 P-TMSI signature is used by SGSN to
authenticate P-TMSI
 Old P-TMSI Signature is the current P-TMSI
signature the mobile has for its current P-TMSI
 Update Type
 tells target SGSN whether RA Update is
triggered by a change of RA, a periodic RA
update, or a combined RA/LA update
 Network Capability
 a set of information describing mobile's nonradio-related capability
 it includes, for example, information needed for
performing ciphering and authentication
Footnote
 IMSI (International Mobile Subscriber Identity)
 each subscriber to 3GPP network services is
assigned a globally unique IMSI as its permanent
identifier
 a subscriber uses its IMSI as its common identifier
for accessing PS services, CS services, or both PS
and CS services at the same time
 TMSI (Temporary Mobile Subscriber Identity)
 to avoid transmitting IMSI over the air, 3GPP uses
TMSI to identify a mobile whenever possible
 TMSI is a four-octet number assigned to a mobile
temporarily
 by an MSC/VLR for CS services, or
 by an SGSN for PS services
 an MSC or SGSN uses a TMSI to uniquely identify
a mobile
 TMSI will only be allocated in ciphered form
 P-TMSI (Packet TMSI)
 a TMSI for packet-switched services
3GPP Intra-SGSN Routing Area
Update Procedure
 [Step 1] Mobile initiates RA update by sending a
RAUR to target RNC
 RAUR is then forwarded to target SGSN
 this will trigger the establishment of an Iu
signaling connection between them if such a
connection does not exist (e.g., if mobile was in
PMM-IDLE state before sending RAUR)
 target SGSN determines whether RA update is
intra-SGSN or inter-SGSN RA update by
examining Old RAI carried in RAUR
 RA update is intra-SGSN RA update if target
SGSN also serves old RA
 [Step 2] Target SGSN needs to authenticate mobile to
determine whether RAUR can be accepted
 as mobile identifies itself by its P-TMSI in RAUR,
target SGSN will authenticate mobile by validating
mobile’s P-TMSI first
 only the SGSN that assigned P-TMSI has sufficient
information (i.e., mobile’s IMSI and correct PTMSI Signature for P-TMSI) to validate P-TMSI
 as target SGSN is identical to source (serving)
SGSN with an intra-SGSN handoff
 target SGSN should be the SGSN that assigned
old P-TMSI to mobile and therefore should be
able to validate P-TMSI locally
 [Step 3 & 4] Upon positive authentication of mobile,
SGSN updates mobile’s RAI
 if mobile was in PMM-CONNECTED state on
target SGSN
 some user traffic destined to mobile may have
been sent by target SGSN to source RNC and are
buffered at source RNC
 as mobile is now connected to target RNC
 source RNC can not deliver these buffered
traffic over its radio connections to mobile
 if these traffic belong to a Radio Access Bearer
that requires in-order delivery packets
 target SGSN may send a Serving RNS (SRNS)
Data Forward Command to instruct source
RNC to tunnel the buffered traffic to target
SGSN
 target SGSN will in turn deliver this traffic to
mobile before sending subsequent traffic
 [Step 5] SGSN will also send a Routing Area Update
Accept (RAUA) message to mobile to inform that its
RAUR is accepted
 target SGSN may assign a new P-TMSI to mobile
 the new P-TMSI together with a P-TMSI Signature
for new P-TMSI will be carried in RAUA message
 [Step 6] Mobile confirms the acceptance of new PTMSI by returning a Routing Area Update Complete
(RAUC) message to SGSN, which completes RA
Update procedure
3.3.2 Inter-SGSN Routing Area Update
 [Step 1] Mobile initiates an inter-SGSN RA update by
sending a RAUR to target SGSN in exactly the same
format and information elements as in initiating an
intra-SGSN RA update
 target SGSN needs to authenticate mobile to
determine if the RAUR can be accepted
3GPP Inter-SGSN Routing Area
Update Procedure
(1)
(3)
(2)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(15)
(16)
(14)
(17)
(18)
(19)
(20)
(21)
(22)
 for an inter-SGSN RA update
 target SGSN is different from source SGSN
 mobile’s P-TMSI in RAUR was assigned by
source SGSN
 target SGSN will ask source SGSN to help
validate P-TMSI
 target SGSN first derives source SGSN from Old
RAI and P-TMSI carried in RAUR
 [Step 2] Target SGSN sends a SGSN Context Request
message to source SGSN to validate mobile’s P-TMSI
 SGSN Context Request carries the following
information elements
 Old P-TMSI
 Old RAI
 Old P-TMSI Signature
 [Step 3 & 4] Some PDP context information (e.g.,
sequence number of the next packet to be sent to
mobile) requested by target SGSN may be maintained
by source RNC
 source SGSN will send an SRNS Context Request
to source RNC to collect such information
 source RNC will stop sending downlink data to
mobile and returns an SRNS Context Response
message to source SGSN
 [Step 5 & 6] Source SGSN will validate P-TMSI and
act as follows
 upon positive validation of P-TMSI
 source SGSN will send a SGSN Context
Response message back to target SGSN
 this message carries mobile’s PMM context and
PDP context
 these contexts contain critical information
needed by target SGSN to handle the traffic to
and from mobile
 example
 PDP contexts describe mobile’s active PDP
contexts immediately before RA update
 target SGSN needs to update PDP contexts on
mobile’s GGSN during RA update
 if mobile was in PMM-CONNECTED state
on source SGSN
 source SGSN could be sending packets to
mobile immediately before RA update
 to ensure in-sequence delivery of packets to
mobile
 target SGSN needs to know the sequence
number of the next user packet that should
send to mobile
Footnote
 PMM context
 mobile’s PMM context
 a set of information used by network to track
mobile's location
 state of a mobile’s PMM context determines
 which network connections (bearers) between
mobile and SGSN should be maintained for
mobile
 how network tracks mobile’s location
Footnote (cont.)
 PDP Context
 a set of information maintained by a network node
used to determine how to forward user packets
destined to and originated from a particular PDP
address
 PDP context為在GPRS/UMTS內部網路中繞送封
包時所需的路由資訊
 當啟動PDP context建立程序時，SGSN會依照
MS所啟動的服務，選擇一適當的APN (Access
Point Name)及GGSN服務該使用者
Footnote (cont.)
 PDP Context Activation
 MS可藉由此程序和GGSN間建立PDP Context
 MS將依據使用者的服務需求，要求與網路端建
立符合QoS的傳輸通道
 網路端若接受MS的QoS需求，則可完成PDP
Context的建立，內容將分別記錄於MS、SGSN及
GGSN中
Footnote: 3GPP PDP Context State
Transitions
 upon negative validation of P-TMSI
 source SGSN will send an appropriate error
cause to target SGSN
 this will trigger target SGSN to initiate security
procedures directly with mobile to authenticate
mobile
 if authentication is also negative
 target SGSN will reject mobile’s RAUR
 if authentication is positive
 target SGSN will send another SGSN Context
Request message to source SGSN to retrieve
mobile’s PMM context and PDP context
 this time, SGSN Context Request will carry
mobile’s IMSI, Old RAI, an indicator (“MS
Validated”) to indicate that mobile has been
positively authenticated
 source SGSN will respond with an SGSN
Context Response message
 carrying mobile’s PMM context and PDP
context if source SGSN has these
information elements, or
 an appropriate error cause if source SGSN
does not have these information elements
 [Step 7]
 after receiving SGSN Context Response from
source SGSN indicating a positive validation of
mobile’s P-TMSI
 target SGSN responds with an SGSN Context ACK
message
 [Step 8 ~ 10]
 if mobile was in PMM-CONNECTED state on
source SGSN
 some user traffic destined to mobile may have
been sent by source SGSN to source RNC and
are buffered at source RNC
 as mobile is now connected to target SGSN
 source RNC can not deliver these buffered
traffic over its own radio connections to
mobile
 if these traffic belong to a RAB that requires inorder delivery, source SGSN may send an SRNS
Data Forward Command to source RNC to
instruct it to tunnel the buffered traffic to source
SGSN, and then to target SGSN
 target SGSN will in turn deliver traffic to mobile
 [Step 11 & 12] After sending SGSN Context ACK
message to source SGSN
 target SGSN will also update mobile’s active PDP
contexts by sending Update PDP Context Request
to ensure that the mobile’s serving GGSN knows to
which SGSN packets destined to mobile should be
delivered
 this will trigger serving GGSN to update mobile’s
PDP context
 [Step 13] For a successful PDP context update
 target SGSN will update mobile’s location with
HLR, which tracks each mobile’s serving SGSN
 when a GGSN has packets to send to a mobile but
does not have active PDP context for mobile
 GGSN may query HLR to find out the address of
mobile’s current serving SGSN, then
 use Network-requested PDP Context Activation
to establish a PDP context to forward packets to
mobile
 SGSN uses Gr interface to interact with HLR for
location update by sending an Update Location
message
 [Step 14] Upon receiving Update Location message
 HLR will inform source SGSN to delete mobile‘s
location information by sending Cancel Location
 source SGSN will then remove mobile’s location
and service subscription information
 [Step 15] Source SGSN will also release Iu connections
between source SGSN and source RNC used by mobile
by sending Iu Release Command
 [Step 18] In the meantime, HLR will also send user’s
service subscription to target SGSN by sending Insert
Subscriber Data message
 [Step 19] Target SGSN records mobile’s service
subscription information and responds to HLR with an
Insert Subscriber Data ACK message
 [Step 20] Now, HLR will send Update Location ACK
message back to target SGSN indicating that location
update with HLR is complete
 [Step 21] Upon a successful location update with HLR
 target SGSN creates a PMM context for mobile
 target SGSN will send a Routing Area Update
Accept (RAUA) message to mobile indicating that
RAUR is accepted
 target SGSN assigns a new P-TMSI to mobile
 the new P-TMSI together with a P-TMSI Signature
for the new P-TMSI will be carried in RAUA
message
 [Step 22] Mobile confirms the acceptance of the new
P-TMSI by returning a Routing Area Update Complete
message to target SGSN, which completes RA Update
procedure
3.4 Serving RNS Relocation
 Serving RNC
 a mobile in PMM-CONNECTED state has a
serving RNC, which receives user traffic from CN
and distributes traffic over RAN to mobile
 Serving RNS
 the RNS that contains a mobile’s serving RNC
 a mobile’s serving RNS may forward user traffic
via another RNC to mobile
3GPP Data Path before and after Serving
RNS Relocation and RA Update
 When a mobile connects to a target RNC
 target RNC may become the mobile’s new serving
RNC
 Serving RNS Relocation procedure (S-RNS-RP)
 only source RNC can initiate S-RNS-RP
 source RNC decides whether to initiate S-RNS-RP
based on measurement results of the quality of
radio channels to mobile
 as an Iu connection needs to be maintained between
mobile’s serving RNC and serving SGSN while the
mobile is in PMM CONNECTED state
 the RNC side of the mobile’s Iu connections needs
to be relocated from old serving RNC to new
serving RNC
 Assumption
 before the relocation, mobile’s serving RNC is
using Iur interface to forward signaling and user
traffic to another RNC, which in turn delivers
traffic to mobile
 such a scenario may occur during or after a soft
inter-RNC handoff
 source RNC distributes copies of user traffic to
one or more other RNCs, which in turn deliver
user data to mobile simultaneously
 Consider a mobile that moves from source RNC to
target RNC
 after mobile connects to target RNC but before
Serving RNS Relocation or RA Update is
performed
 user traffic destined to mobile continues to be
routed by PS CN to source RNC
 source RNC then forwards traffic to target RNC
 target RNC will in turn transmit traffic to mobile
3GPP Serving RNS Relocation
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(13)
(11)
(14)
(12)
(15)
(16)
(18)
(17)
(19)
(20)
 [Step 1] When source RNC decides to initiate S-RNSRP
 it sends a RANAP Relocation Required message to
source SGSN, which carries the following info.
 relocation Type
 indicates whether mobile should get involved
in S-RNS-RP
 in particular, whether mobile’s RRC
connection needs to be relocated during SRNS-RP
 if relocation Type is “UE not Involved”
 network itself carries out S-RNS-RP and
mobile’s RRC connection does not need to
be relocated
 i.e., mobile has already set up the
necessary RRC connection with target
RNC; no handoff procedure needs to be
performed for RRC Connection during SRNS-RP
 network only needs to move RNC side of
mobile’s Iu bearers to target RNC to make
it the mobile’s new serving RNC
 if relocation Type is “UE Involved”
 mobile will also need to get involved in SRNS-RP to relocate its RRC connection to
target RNC
 source ID
 identifier of source RNC
 target ID
 identifier of target RNC
 source RNC to target RNC transparent container
 contains the information needed by target
RNC to perform serving RNC relocation
 security information regarding mobile
 RRC protocol context that describes
mobile’s RRC connection and mobile’s
capabilities
 [Step 2 ~ 4] Source SGSN determines if RNS
relocation is intra-SGSN or inter-SGSN by inspecting
the identifiers of source and target RNCs
 for inter-SGSN relocation
 source SGSN will send a RANAP Forward
Relocation Request message to target SGSN to
request target SGSN to establish Iu connection
for mobile
 target SGSN will then send a RANAP
Relocation Request message to target RNC to
trigger it to establish the necessary RABs for
mobile
 each RAB consists
 Radio Bearers between mobile and RNC
 Iu bearers between SGSN and RNC
 to set up RABs between target SGSN and mobile
 the existing Radio Bearers between mobile
and source RNC
 need to be relocated between mobile and
target RNC
 mobile’s Iu bearers between source SGSN and
source RNC
 need to be relocated between target SGSN
and target RNC
 [Step 5] After target RNC has allocated all necessary
resources for all required RABs
 target RNC will send a RANAP Relocation Request
Acknowledge message back to target SGSN
 at this point, the resources for transporting user
packets between target RNC and target SGSN have
been allocated and target RNC is ready to become
the new serving RNC for mobile
 [Step 6] Target SGSN will send a RANAP Forward
Relocation Response message back to source SGSN
 [Step 7 & 8] Source SGSN sends a Relocation
Command to source RNC to instruct source RNC to
start to hand over the role of serving RNS to target
RNC
 this message will also inform source RNC
 which RABs for mobile should be released, and
 which ones should be kept for a little longer so
that user packets already received by source
RNC can be forwarded to target RNC
 at this moment, source RNC may start to forward
downlink data toward target RNC
 [Step 9] Source RNC will then transfer its serving
RNC role to target RNC
 source RNC sends a Relocation Commit message,
over Iur interface, to target RNC
 this message also sends Serving RNS (SRNS)
Contexts for mobile from source RNC to target
RNC
 these Contexts contain information regarding RABs
between mobile and source SGSN
 [Step 10 ~ 12] Target RNC sends a RANAP
Relocation Detect message to target SGSN to request
SGSN to update PDP Context for mobile if necessary
(i.e., if the relocation is inter-SGSN)
 [Step 13] Immediately after sending out Relocation
Detect message
 target RNC will start to serve as serving RNC for
mobile and will start to send RAN Mobility
Information messages to mobile
 these messages contain
 the identity of mobile’s new serving RNC
 location area identifier (LAI)
 routing area identifier (RAI)
 [Step 14] Mobile may begin to send uplink traffic
toward target RNC
 mobile will also use the received information to
reconfigure itself
 mobile will send RAN Mobility Information
Confirm message to target RNC
 this message indicates that mobile is ready to
receive user traffic from target RNC
 [Step 15 ~ 17] Upon receiving RAN Mobility
Information Confirm message
 target RNC will send Relocation Complete to target
SGSN and then to source SGSN, to inform
completion of S-RNS-RP
 [Step 18 & 19] Source SGSN instructs source RNC to
release Iu Bearers allocated to mobile
 [Step 20] When mobile starts communication with
target RNC
 mobile may find that it has moved into a new RA
 in this case, mobile will initiate RA Update
procedure
3.5 Hard Handoffs
 Assumptions
 inter-RNC hard handoff
 no Iur interface (RNC-RNC) is implemented
 Before inter-RNC hard handoff
 source RNC is the mobile’s serving RNC
 During and after inter-RNC hard handoff
 target RNC will become mobile’s new serving RNC
 this requires RNC side of mobile’s Iu Bearers to be
relocated from source RNC to target RNC
(combined with S-RNC-RP)
3GPP PS Domain Hard Handoff
(Inter-SGSN Handoff)
(1)
(2)
(3)
(4)
(5)
(7)
(9)
(6)
(8)
(10)
(11)
(12)
(13)
(14)
(15)
(16)
(17)
(18)
(19)
(20)
(21)
(22)
(23)
 [Step 1] Only source RNC can initiate inter-RNC hard
handoff process
 source RNC determines whether to initiate handoff
process based on measurement results of radio
channel qualities
 initiating S-RNS-RP
 source RNC sends a RANAP Relocation
Required message to source SGSN and sets
Relocation Type to “UE Involved”
 “UE Involved” Relocation Type indicates that
mobile will get involved in S-RNS-RP to
relocate its RRC connection to target RNC
 [Step 2] If it is an inter-SGSN handoff
 source SGSN will send a Forward Relocation Request
to target SGSN to ask for starting to relocate mobile’s
RABs between mobile and target SGSN
 [Step 3] Target SGSN sends Relocation Request message to
target RNC to relocate RABs for mobile
 [Step 4] Target RNC proceeds to allocate all the necessary
resources needed to set up Iu Bearers
 [Step 5] Target RNC sends a Relocation Request
Acknowledge message back to target SGSN
 [Step 6] When all the Iu bearers have been established
for the mobile between target SGSN and target RNC
and the target RNC is ready to act as the serving RNC
for mobile
 target SGSN sends a Forward Relocation Response
message to source SGSN
 [Step 7] This message triggers source SGSN to send a
Relocation Command to source RNC to ask source
RNC to hand over the role of serving RNS to the new
RNC
 [Step 8&9] Source RNC takes the following main
actions
 Forwarding user data to target RNC
 forward downlink user data that have already
arrived at source RNC, toward target RNC
 instruct mobile to relocate its RRC connection to
new RNC
 source RNC will send an RRC-layer message
( RRC Message 1) to instruct mobile to relocate
its Radio Bearers to new RNS
 [Step 10-13] Source RNC sends a Forward SRNS
Context message to target RNC (via source SGSN and
target SGSN)
 SRNS Context contains information regarding
mobile’s RABs through source RNC and can be
used by target RNC to establish Iu bearers for
mobile
 [Step 14-16] When target RNC detects that mobile has
connected to target RNC
 target RNC informs target SGSN by sending a
Relocation Detect message
 for inter-SGSN hard handoff, the Relocation Detect
message will also trigger target SGSN to initiate
PDP Context Update procedure to ensure that
GGSN will start to send packets destined to mobile
to target SGSN
 [Step 17] After mobile has reconfigured its Radio
Bearers and established its RRC connection to target
RNC
 it will send a RRC-layer message (RRC Message 2)
to inform target RNC that handoff on mobile side
has been completed
 [Step 18] Handoff process completes when mobile has
connected to target RNS
 mobile’s PDP context on mobile’s serving GGSN
has been updated, and target RNC has received all
the required Serving RNS Context information
from source RNC
 [Step 20-23] Target SGSN informs source SGSN of
handoff completion by sending a Forward Relocation
Complete message
 this message will trigger source SGSN to release
mobile’s Iu Bearers between source SGSN and
source RNC
3.6 Paging Initiated by Packet-Switched
Core Network
 When a SGSN receives downlink user data or
signaling messages destined to a mobile in PMM-IDLE
state
 SGSN initiates paging by sending a RANAP Paging
message to every RNC in the Routing Area in
which the mobile is located
3GPP Paging in Packet Switched Domain
 RANAP Paging message carries the following main
information
 identities of the mobile to be paged
 RANAP Paging message carries mobile’s IMSI
 if mobile is using a P-TMSI, RANAP Paging
message will also contain mobile’s P-TMSI
 CN Domain Identifier
 indicates which CN domain (i.e., PS CN domain
or CS CN domain) initiated this RANAP Paging
message
 area
 the Paging Area in which the mobile is to be
paged
 Depending on the way a paging message is physically
delivered by RNC to mobile, paging inside RAN can
be classified into two types
 Type 1 Paging
 performed when there is no dedicated RRC
connection between RNC and mobile
 RNC will send a Type 1 Paging message to
mobile over Paging Channel, a physical radio
broadcast channel
 Type 1 Paging message may also be initiated by
RAN, i.e., by an RNC in RAN
 Type 1 Paging message will carry a Paging
Originator field that indicates whether the paging
is initiated by CN or RAN
 Type 2 Paging
 used when mobile has a dedicated RRC
connection to RNC
 RNC will deliver a Type 2 Paging message to
mobile over this dedicated RRC connection
 Upon receiving a Type 1 or 2 Paging message
 mobile will start Service Request procedure to
establish the necessary signaling and traffic
connections with CN and use them to send uplink
signaling messages and user packets
3.7 Service Request Procedure
 Service Request Procedure (SRP) used by a mobile in
PMM-IDLE state
 request the establishment of a signaling connection
between mobile and SGSN so that mobile can begin
to exchange signaling messages with SGSN
 SRP used by a mobile in PMM-CONNECTED state
 request resource reservation for mobile’s active
PDP contexts
3GPP Mobile-Initiated Service
Request Procedure
(1)
(2)
(3)
(4)
(6)
(5a)
(7)
(8)
(9)
 [Step 1&2] Mobile has to establish an RRC connection
with RNC, if such a connection does not exist
 mobile sends a Service Request message to SGSN
 [Step 3&4] Upon receiving the Service Request
 SGSN will perform security procedures to
authenticate mobile and check if it is authorized to
use the network
 if the mobile is authorized to use network
 SGSN takes actions based on Service Type in
the received Service Request
 [Step 5a,6&7] If the Service Type indicates DATA
 means that mobile has user data to send (or receive)
over PS CN domain
 a signaling connection between mobile and SGSN
will be established first so that mobile can send
signaling messages to SGSN
 the RABs will be allocated for mobile’s existing
active PDP contexts using RAB Assignment
Procedure, if such RABs do not already exist, to
allow mobile to exchange user data with GGSN
 [Step 5b] If Service Type indicates SIGNALING
 means that mobile has no user data to send (or
receive) over PS CN domain at this moment
 mobile just wishes to exchange signaling messages
with SGSN
 only a signaling connection between mobile and
SGSN will be established
 no RAB will be allocated for any active PDP
context of mobile
 Service Request is acknowledged in different ways
depending on Service Type and mobile’s PMM state
 if mobile is in PMM-CONNECTED state and
Service Type indicates DATA
 SGSN will respond to Service Request message
by returning a Service Accept message to mobile
if SGSN accepts mobile’s service request
 if Service Type indicates SIGNALING or mobile is
in PMM-IDLE state
 SGSN does not send any explicit signaling
message to mobile to indicate the acceptance of
mobile’s Service Request
 mobile will learn that its Service Request was
successfully received by SGSN when mobile
receives certain RRC-layer signaling messages
from RNC
 [Step 8] After a RAB has been re-established
 the QoS profile negotiated for this newly
established RAB may be different from the old
negotiated QoS profile maintained in the PDP
contexts on SGSN, GGSN, and mobile
 SGSN will trigger SGSN-initiated PDP
Modification procedure to inform GGSN and
mobile of the new negotiated QoS profile for
RAB
 SGSN may also use SGSN-initiated PDP DeActivation procedure to delete a PDP context if the
required RABs cannot be set up for this PDP
context
 [Step 9] Mobile may also use the Modification
procedure to request CN to renegotiate the QoS profile
for a RAB, or use Mobile-initiated PDP Context DeActivation procedure to delete an active PDP context
3.8 Handoff and Roaming Between 3GPP
and Wireless LANs
 How Mobile IP (v4 or v6) can be used to support
handoff and roaming between 3GPP and WLAN
 the same approach can also be used to support
handoff/roaming between WLAN and any other
cellular network (e.g., GPRS, EDGE, and 3GPP2)
Handoff between 3GPP and IP
Networks using Mobile IP
 Mobility service provider
 refers to any network provider that provides a
Mobile IP Home Agent to mobile
 may be one of the following
 cellular network provider
 mobile’s home enterprise network
 Internet Service Provider
 Cellular network
 connects to mobility service provider’s IP network
directly or via a standard IP network
 When a mobile moves from a cellular network to a
WLAN
 mobile acquires a local IP address that it can use to
receive IP packets from new network
 mobile uses this new local IP address as its new
Mobile IP CoA and uses Mobile IP to register the
new CoA with its Mobile IP Home Agent
 mobile will continue to receive IP packets
addressed to its Mobile IP Home Address
 user IP packets addressed to mobile’s Home
Address will be routed to mobile’s HA
 HA will tunnel these packets to mobile’s current
CoA
Sample Signaling Message Flow to
support Handoff from WLAN to 3GPP
 Given a mobile moves from a WLAN into a cellular
network, mobile performs standard 3GPP procedures
 attach to 3GPP network
 activate its PDP context
 acquire a local care-of IP address during PDP
Context Activation process
 Mobile registers this CoA with its home agent
 IP packets addressed to mobile’s MIP home address
will be tunneled by HA to mobile’s current CoA
 If the CoA is a co-located CoA
 packets will be tunneled to mobile directly
 mobile will then de-tunnel packets to extract the
original payload packets
 If mobile uses a Foreign Agent (FA) CoA in 3GPP
network and FA is on the mobile’s serving GGSN
 packets will be tunneled to FA/GGSN which will
de-tunnel packets and forward the resulting packets
to mobile
Sample Signaling Flow for Handoff
between 3GPP and IP Networks using MIPv4