Mobility management in ip based wireless networks
Download
1 / 572

Mobility Management in IP-Based Wireless Networks - PowerPoint PPT Presentation


  • 116 Views
  • Uploaded on

Mobility Management in IP-Based Wireless Networks. Basic issues in mobility management Mobility management in IP networks Mobility management in 3GPP packet networks. 1. Basic Issues in Mobility Management . 1.1 Impact of naming and addressing on mobility management

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Mobility Management in IP-Based Wireless Networks' - carver


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript


1 basic issues in mobility management
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
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 servicesregardless of where the user is


Basic mobility management requirements
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
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 differentoperators’ 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
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 namesindependent 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 nameshave 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 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
1.2.1 Location Update Strategies

  • When a mobile should perform location updatesand 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
Location Update frequently,

  • 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 frequently,

    • update whenever it has traveled a predefined distancethreshold 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 frequently,

    • update whenever the value of any preselected parameter changes

    • these strategies are sometimes referred to as profile-based strategies

    • this strategy is used, for example, as an option in 3GPP2


  • Implicit update frequently,

    • 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 othersignaling or user data from the mobile


  • Probabilistic update frequently,

    • 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
Movement-Based vs. Distance-Based frequently, Location Update Strategies


  • Assumptions frequently,

    • 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 distance-based update strategy is three cells


  • Movement-based update strategy frequently,

    • 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
1.2.2 Location Discovery frequently, (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
Issues with Paging frequently,

  • 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 constructpaging areas?

    • paging areas do not have to be identical to location areas

  • How to search a paging area to locate a mobile?


Paging strategies
Paging Strategies frequently,

  • Blanket paging

  • Sequential paging

  • Geographic paging

  • Group paging


Blanket paging
Blanket Paging frequently,

  • 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


Page every cells within the LA frequently,

Blanket Paging


Sequential paging
Sequential Paging frequently,

  • 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


Page the cells sequentially until the user is found frequently,

8

9

2

7

1

10

3

4

6

5

Sequential Paging


  • Issues frequently,

    • 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 Paging vs. Sequential Paging frequently,

sequential group paging may be used if there is a constraint on paging cost


Geographic group paging strategies
Geographic & Group frequently, 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
1.2.3 Interactions between Location frequently, 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
1.3 Packet Delivery frequently, Strategiesto 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 frequently,

    • 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 frequently,

    • 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 frequently,

    • 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
1.4 Handoffs frequently,

  • 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
Layers of Handoff frequently,

  • 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 differentIP access router


Scopes of handoff
Scopes of Handoff frequently,

  • 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 frequently,

    • 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
Types of Handoff Processes frequently,

  • 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 frequently,

    • 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
Data Distribution and Selection frequently,

  • 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
Data Content Synchronization frequently,

  • Mobile’s radio system should combine copies of the same data arriving from multiple base stations


Selection and distribution unit sdu
Selection and Distribution Unit (SDU) frequently,

  • 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
1.5 Roaming frequently,

  • 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 frequently,

    • 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 frequently,

    • when a user moves into a domain with which it does not have an account


Extra capabilities needed to support roaming
Extra Capabilities Needed to frequently, 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
Network Access Control for frequently, 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
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 Domainshome 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
Roaming Broker Domains

  • 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 Domains

    • each network provider only needs to establish a roamingagreement 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. Mobility Management in DomainsIP 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) Domains

    • standard protocol defined by IETF for mobility management in IPv4 networks

    • enables an IP terminal to maintain a permanent IPaddress 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 Domains management protocols

    • IP-layer mobility protocols that provide enhancedmobility 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 Domains

    • 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
2.1 Naming and Addressing of DomainsIP 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 Domainsmultiple 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 Domains:Network Access Identifier (NAI)

    • IETF defined NAI that can identify a mobileterminal (or user) regardless of either the terminal’s current location or how many IP addresses the terminal may have


  • NAI form Domains

    • [email protected]

      • username:identifies the terminal

      • realm:identifies the Internet domain name of a Network Access Server (NAS)


Note network access server nas
Note: Network Access Server (NAS) Domains

  • 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


  • 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
    2.2 Mobile IPv4 or what credentials are valid

    • Mobility issues in IP Networks

      • once a mobile terminal moves to a new subnet, a correspondent node needs to use the mobile’s newIP 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 or what credentials are valid

      • ensure on-going TCP connection does not break

      • restore quickly if TCP connection breaks


    Home network
    Home Network or what credentials are valid

    • 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 or what credentials are valid

    24

    A:

    0

    Network

    Host

    14

    16

    B:

    1

    0

    Network

    Host

    21

    8

    C:

    1

    1

    0

    Network

    Host

    Note: Network Prefix

    Class A Network (/8 Prefixes)

    Class B Networks (/16 Prefixes)

    Class C Networks (/24 Prefixes)


    • IP addresses are divided into three different classes or what credentials are valid

      • 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


    7 or what credentials are valid

    24

    A:

    0

    Network

    Host

    14

    16

    B:

    1

    0

    Network

    Host

    21

    8

    C:

    1

    1

    0

    Network

    Host

    IP addresses: (a) class A; (b) class B; (c) class C


    • the class of an IP address is identified in the or what credentials are validmost 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


    • Class A addresses or what credentials are valid

      • 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


    • Class C addresses or what credentials are valid

      • 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)


    • IP addresses are written as or what credentials are validfour 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


    Foreign network
    Foreign Network or what credentials are valid

    • 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) or what credentials are valid

      • 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
    Two Types of CoAs in MIPv4 or what credentials are valid

    • 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 HAtunnels 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 or what credentials are valid

      • 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 HAtunnels 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
    Main Phases of MIPv4 Operation or what credentials are valid

    • 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 or what credentials are valid

    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
    2.2.1 Agent Discovery or what credentials are valid

    • 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
    Agent Advertisement Message (ICMP) Router Discovery Messages

    • 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
    Structure of Mobile IP Agent (ICMP) Router Discovery MessagesAdvertisement Message


    Mipv4 mobility agent advertisement extension to icmp router advertisement message
    MIPv4 Mobility Agent Advertisement (ICMP) Router Discovery MessagesExtension to ICMP Router Advertisement Message


    Fields and flags
    Fields and Flags (ICMP) Router Discovery Messages

    • 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) (ICMP) Router Discovery Messages

      • 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 (ICMP) Router Discovery Messages - 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) (ICMP) Router Discovery Messages

      • 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
    MIPv4 Prefix-Length Extension (ICMP) Router Discovery Messagesto ICMP Router Advertisement message


    Fields
    Fields (ICMP) Router Discovery Messages

    • 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
    Agent Solicitation Message (ICMP) Router Discovery Messages

    • 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
    2.2.2 Movement Detection (ICMP) Router Discovery Messages

    • 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 (ICMP) Router Discovery Messages

      • 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 (ICMP) Router Discovery Messages

      • 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
    2.2.3 Leaving the Home Network (ICMP) Router Discovery Messages

    • 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 (ICMP) Router Discovery Messages

      • 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



    Issues resolutions
    Issues & Resolutions ARP REPLY message including its IP address and hardware address

    • 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) ARP REPLY message including its IP address and hardware address

      • 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 ARP REPLY message including its IP address and hardware address

      • 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 ARP REPLY message including its IP address and hardware address

      • 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) ARP REPLY message including its IP address and hardware address

      • 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



    2 2 4 entering and staying in a visited network
    2.2.4 Entering and Staying in a the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectivelyVisited 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 the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

      • Registration Request

      • Registration Reply

      • Registration Request and Registration Reply messages are transported over UDP to a port number 434


    • Registration request & reply the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

      • 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 the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

      • 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 the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

      • HA authenticates all Registration Requests it receives

      • mobile authenticates all Registration Reply messages it receives


    • protections against a range of security attacks the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

      • 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
    MIPv4 Registration Request the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectivelyMessage Format


    Fields and flags1
    Fields and Flags the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

    • Type

      • 1, indicate whether this is a MIPv4 Registration Request

    • S (Simultaneous bindings)

      • set, if a mobile requests its HA to maintain multiplecare-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) the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

      • 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) the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

      • set, if the mobile requests that its HA use MinimalEncapsulation for datagrams tunneled to the mobile

    • G (GRE encapsulation)

      • set, if the mobile requests that its HA use GREencapsulation for datagrams tunneled to the mobile node

    • r

      • set to zero and ignored on reception

      • not used for any other purpose


    • T the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

      • 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 the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

      • if a mobile has a preconfigured home address

        • it may put its home address in the Home Address field


    • if the mobile does the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectivelynot 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 the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

      • 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 Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

      • 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 the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

      • 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
    MIPv4 Registration Reply Message Format the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively


    Fields1
    Fields the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

    • Type

      • 3, indicate whether this is a MIPv4 Registration Reply message

    • Code

      • indicate the result of the corresponding Registration Request


    • Lifetime the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

      • 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 Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

      • 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 the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

      • 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
    2.2.5 Returning to the Home Network the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

    • 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 IP-to-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
    2.2.6 Mobile-Home Authentication Extension the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

    • Used to authenticate Registration Request and Registration Reply messages


    Mobile home authentication extensions to mobile ip messages
    Mobile-Home Authentication the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectivelyExtensions to Mobile IP Messages


    Fields2
    Fields the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

    • 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 the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectively

      • 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 Mobile-Home Authentication Extension

        • the Type, Length, and SPI fields of this Mobile-Home Authentication Extension


    Fields protected by mip mobile home authentication extension
    Fields Protected by MIP the Sender Hardware Address of this ARP REPLY message to the HA’s own IP and hardware addresses, respectivelyMobile-Home Authentication Extension


    2 2 7 vendor organization specific extensions to mobile ip messages
    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




    Cvse fields
    CVSE Fields defined in IETF RFC 3115

    • 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 defined in IETF RFC 3115

      • 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 defined in IETF RFC 3115

      • vendor/organization-specific data

      • it may contain zero or more octets



    Nvse fields
    NVSE Fields defined in IETF RFC 3115

    • 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 defined in IETF RFC 3115

      • 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 defined in IETF RFC 3115

      • vendor/organization-specific data

      • it may contain zero or more octets


    2 2 8 reverse tunneling
    2.2.8 Reverse Tunneling defined in IETF RFC 3115

    • 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 defined in IETF RFC 3115

      • 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 tunneling by deliver packets to FA

      • direct delivery style

        • the mobile

          • designate the FA as its default router

          • send packets directly to the FA withoutencapsulation


    • the FA tunneling by

      • intercept these packets

      • tunnel them over the reverse tunnel to the mobile’s HA


    • encapsulate tunneling by 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



    2 2 9 limitations of mipv4
    2.2.9 Limitations of MIPv4 tunneling by

    • [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 tunneling by 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 tunneling by 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 tunneling by 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 mobility management requirementspaging 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
    2.2.10 MIPv4 Route Optimization mobility management requirements

    • 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
    MIPv4 Route Optimization mobility management requirements


    2 3 mipv4 regional registration
    2.3 MIPv4 Regional Registration mobility management requirements

    • 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 mobility management requirements

      • 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
    MIPv4 Regional Registration mobility management requirements


    • Each network domain consists of a two-level hierarchy of FAs mobility management requirements

      • 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 mobility management requirements

      • 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 Registration Request message and then relay this message with the added extensions to the GFA

      • 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
    2.4 Paging Extensions to Mobile IPv4 Registration Request message and then relay this message with the added extensions to the GFA

    • 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 Registration Request message and then relay this message with the added extensions to the GFA

      • 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 Registration Request message and then relay this message with the added extensions to the GFAActive 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 Registration Request message and then relay this message with the added extensions to the GFA

      • 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 Registration Request message and then relay this message with the added extensions to the GFA

      • 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 Registration Request message and then relay this message with the added extensions to the GFA

      • 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
    Paging Extensions to Mobile IPv4 Registration Request message and then relay this message with the added extensions to the GFA


    • P-MIP procedure ( Registration Request message and then relay this message with the added extensions to the GFAdeliver 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 Registration Request message and then relay this message with the added extensions to the GFAactive

      • 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 Registration Request message and then relay this message with the added extensions to the GFA: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 Registration Request message and then relay this message with the added extensions to the GFA

      • 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 Registration Request message and then relay this message with the added extensions to the GFA 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 Registration Request message and then relay this message with the added extensions to the GFA

      • 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
    2.5 Mobile IPv6 Registration Request message and then relay this message with the added extensions to the GFA

    • 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 Registration Request message and then relay this message with the added extensions to the GFA

      • 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 Registration Request message and then relay this message with the added extensions to the GFA

      • 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
    MIPv6 Address Binding with Registration Request message and then relay this message with the added extensions to the GFAHome Agent


    • Address binding Registration Request message and then relay this message with the added extensions to the GFA

      • 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 Registration Request message and then relay this message with the added extensions to the GFA

      • 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) Registration Request message and then relay this message with the added extensions to the GFA

      • 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 Registration Request message and then relay this message with the added extensions to the GFAsecurity protocols, authentication and encryption algorithms, security associations, and key management

    • IPsec is optional for IPv4 but mandatory in IPv6


    • Security protocols Registration Request message and then relay this message with the added extensions to the GFA

      • 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
    Family of IPsec Protocols Registration Request message and then relay this message with the added extensions to the GFA


    Note security
    Note: Security Registration Request message and then relay this message with the added extensions to the GFA

    • 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 Registration Request message and then relay this message with the added extensions to the GFA

      • 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 Registration Request message and then relay this message with the added extensions to the GFA

      • 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) Registration Request message and then relay this message with the added extensions to the GFA

      • 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 Registration Request message and then relay this message with the added extensions to the GFA

      • 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 Registration Request message and then relay this message with the added extensions to the GFAdivert 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, Registration Request message and then relay this message with the added extensions to the GFAan 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 Registration Request message and then relay this message with the added extensions to the GFA

      • 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
    MIPv6 Bi-directional Tunneling Mode Registration Request message and then relay this message with the added extensions to the GFA

    • 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 mobile’s home networkcorrespondent 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
    MIPv6 Route Optimization Mode mobile’s home network

    • 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 mobile’s home networkbinding 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 mobile’s home networkroute 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
    2.5.1 Movement Detection mobile’s home network

    • 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 mobile’s home network

      • 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 may use other means to help movement detection routers by broadcasting Neighbor Solicitation messages

      • 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 routers by broadcasting Neighbor Solicitation messages

      • 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
    2.5.2 Sending Packets Directly to Mobile’s Care-of Address routers by broadcasting Neighbor Solicitation messages

    • 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 routers by broadcasting Neighbor Solicitation messagesrouting header is inserted between the IPv6 header and the header of upper layer protocol (e.g., UDP or TCP)


    Ipv6 packet
    IPv6 Packet routers by broadcasting Neighbor Solicitation messages傳送架構


    Next header 8 bits
    Next Header (8 bits) routers by broadcasting Neighbor Solicitation messages


    IPv6 routers by broadcasting Neighbor Solicitation messages封包延伸標頭的例子


    IPv6 header routers by broadcasting Neighbor Solicitation messages

    Routingheader

    CoA

    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 destinationmobile’s CoA

      • it will process the routing header and know where is the mobile’s home address


    IPv6 header routers by broadcasting Neighbor Solicitation messages

    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
    MIPv6 Routing Header Format routers by broadcasting Neighbor Solicitation messages


    Fields3
    Fields routers by broadcasting Neighbor Solicitation messages

    • 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 eight-octect units, not including the first eight octets

    • Routing Type

      • type of the routing header


    • Segments left routers by broadcasting Neighbor Solicitation messages

      • 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 routers by broadcasting Neighbor Solicitation messages

      • 32-bit field

      • reserved for future use

    • Home Address

      • home address of the destination mobile


    2 5 3 sending packets while away from home
    2.5.3 Sending Packets while Away routers by broadcasting Neighbor Solicitation messagesfrom 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 routers by broadcasting Neighbor Solicitation messages

      • 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 routers by broadcasting Neighbor Solicitation messagesHome 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



    Fields4
    Fields IPv6 Home Address Option

    • 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 IPv6 Home Address Option

      • 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 IPv6 Home Address Option

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



    Fields5
    Fields Messages

    • 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 Messages

      • 8-bit value

      • identifies the type of mobility message in the Message Data field

    • Reserved

      • 8-bit field

      • reserved for future use


    • Checksum Messages

      • 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
    Format of Mobile MessagesIPv6 Binding Update message


    Fields6
    Fields Messages

    • 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) Messages

      • 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 Messages

      • 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) Messages

      • 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 Messages

      • reserved for future use

    • Lifetime

      • 16-bit unsigned integer

      • indicates the number of time units remaining before the binding expires


    • Mobility Options Messages

      • 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 Messages

      • 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 Messages

      • 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
    Formats of Mobile IPv6 Alternative CoA MessagesOption and Binding Authorization Data Option


    Alternative coa option format
    Alternative CoA Option Format Messages

    • 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
    Binding Authorization Data Option Format Messages

    • 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



    Format of mobile ipv6 binding acknowledgement message
    Format of Mobile IPv6 MessagesBinding Acknowledgement Message


    Fields7
    Fields Messages

    • 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 Messages

      • 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 Messages

      • a variable-length field that

      • one or more Mobility Options in a Type-Length-Value format



    • Binding Refresh Advice option Messages

      • 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
    2.5.5 Hierarchical Mobile IPv6 Registration Messages

    • 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
    Mobile IPv6 “Forwarding from Previous MessagesCare-of Address" Mechanisms


    • Assumptions on a mobile Messages

      • 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 Messages

      • 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 care-of 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



    One approach to support hierarchical mobile ipv6 registration
    One Approach to Support Hierarchical support hierarchical registrationMobile IPv6 Registration


    • Upon entering subnet D support hierarchical registration

      • 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
    2.6 SIP-Based Mobility Management support hierarchical registration

    • 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 support hierarchical registration

    • 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 on-going session such as a conference


    • SIP messages could contain support hierarchical registrationsession 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



    • manage a session multimedia communications

      • modify the parameters of a session

      • invoke service functions to provide services to a session

      • terminate a session


    • SIP is a multimedia communicationsclient-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)


  • SIP redirect server

    • a redirect server is a UAS that generates a response to redirect a request to other location


    • SIP proxy server multimedia communications

      • 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 multimedia communications

      • 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 Redirect Mode multimedia communications


    Sip in proxy mode
    SIP in Proxy Mode multimedia communications


    2 6 1 movement detection
    2.6.1 Movement Detection multimedia communications

    • 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 multimedia communicationssame 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
    2.6.2 Pre-session Terminal Mobility multimedia communications

    • 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
    SIP-Based Pre-session Terminal multimedia communicationsMobility Management


    • Scenario multimedia communications

      • 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 multimedia communicationsnew 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 in tracking current locations of mobiles

      • 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
    Location Update for Supporting in tracking current locations of mobilesSIP-based Terminal Mobility


    • SIP in tracking current locations of mobilesRedirect 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 in tracking current locations of mobiles

      • 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
    2.6.3 Mid-Session Terminal Mobility Support in tracking current locations of mobiles

    • 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 in tracking current locations of mobilesreceiving 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
    SIP-Based Mid-Session in tracking current locations of mobilesTerminal Mobility Management


    2 6 4 limitations of ip mobility using sip
    2.6.4 Limitations of IP Mobility Using SIP in tracking current locations of mobiles

    • 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 in tracking current locations of mobiles

      • hierarchical registration is used to reduce the registration latency


    • Limitation-2 in tracking current locations of mobiles

      • 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 in tracking current locations of mobiles

      • 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 SIP in tracking current locations of mobilesEYE 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 SIP in tracking current locations of mobilesEYE 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 in tracking current locations of mobiles 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 in tracking current locations of mobileschanges 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 SIP in tracking current locations of mobilesEYE 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 in tracking current locations of mobilesapplication 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 SIP in tracking current locations of mobilesEYE 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 in tracking current locations of mobiles

      • 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


    • SIP in tracking current locations of mobilesEYE 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
    2.7 Cellular IP in tracking current locations of mobiles

    • 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 in tracking current locations of mobileschange 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 in tracking current locations of mobileshost-specific routing

      • network nodes perform routing and packetforwarding 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
    Cellular IP in tracking current locations of mobiles


    • Two types of network nodes in Cellular IP network in tracking current locations of mobiles

      • 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 in tracking current locations of mobiles

      • 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
    2.7.1 Cellular IP Routing in tracking current locations of mobiles

    • 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 in tracking current locations of mobiles

      • records the interface on which the beacon packet is received

      • uses reverse path to forward uplink packets to router


    • Downlink packets in tracking current locations of mobiles

      • 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 in tracking current locations of mobilesnext-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 “ in tracking current locations of mobilessoft 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 in tracking current locations of mobileslocation 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 up-to-date host-specific downlink route to the mobile



    • example router and to each mobile suggests that the

      • 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
    2.7.2 Handoffs Inside a Cellular IP Network router and to each mobile suggests that the

    • Cellular IP supports two types of handoffs

      • hard handoff

      • semi-soft handoff


    Hard handoff
    Hard Handoff router and to each mobile suggests that the

    • 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 router and to each mobile suggests that the 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 router and to each mobile suggests that the

      • if mobile moves from BS 3 to BS 4, the cross-over node will be BS 1

      • if mobile moves from BS 5 to BS 6, the cross-over node will be BS 2


    • When route-update packet reaches a cross-over node router and to each mobile suggests that the

      • this node will update mobile's downlink host-specific 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
    Semi-Soft Handoff router and to each mobile suggests that the

    • 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 host-specific route to new BS


    • Semi-soft handoff packet router and to each mobile suggests that the

      • triggers nodes on its path to set up a downlink host-specific 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
    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 Cellular IP and Regular IP Networks 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 Cellular IP and Regular IP Networks

      • 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 Cellular IP and Regular IP Networks

      • 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 host-specific route to mobile directly without encapsulation or tunneling


    2 7 4 paging
    2.7.4 Paging Cellular IP and Regular IP Networks

    • 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-state-timeout

      • 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 and Regular IP Networks

      • 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 Cellular IP and Regular IP Networks 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
    Paging in Cellular IP Networks Cellular IP and Regular 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





    • 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



    2 8 hawaii
    2.8 HAWAII caches

    • 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 cachesrouting 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



    Hawaii
    HAWAII caches


    • Base Station caches

      • 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 caches

      • 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 cachessame 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 cachesinside 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



    • 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
    2.8.1 Mobile Powers Up in its Home HAWAII Domain packets

    • 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 host-specific forwarding route from DRR to mobile for packets delivering



    P ower u p p rocedure
    P packetsower-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 mobileindicating that the mobile is reachable over its air interface


    • Mobile IP may be used to support packetshandoff 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 packets

      • 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 host-specific forwarding entry points to BS A


    • Step 3 packets

      • 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 packets

      • 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
    2.8.2 Handoffs Inside a HAWAII Domain packets

    • HAWAII provides two basic path setup schemes to support handoff

      • Forwarding Path Setup Scheme

      • Non-Forwarding Path Setup Scheme



    Forwarding path setup scheme
    Forwarding Path Setup Scheme packets

    • 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 packets

      [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] packets

    • 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



    [Step 3] mobile

    • 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 host-specific 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] mobile and set the

    • 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] mobile and set the

    • 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
    Nonforwarding Path Setup Scheme mobile and set the

    • 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 unicast non forwarding path setup schemes
    HAWAII Unicast Non-Forwarding SchemesPath Setup Schemes


    • Procedure Schemes

      [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] Schemes

    • 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] Schemes

    • 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] Schemes

    • 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] Schemes

    • this process continues until BS A receives a HAWAII message (Message 5)


    [Step 6] Schemes

    • 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
    2.8.3 Moving into Foreign HAWAII Domains Schemes

    • 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
    Handoff between HAWAII Domains SchemesUsing Mobile IP


    Interdomain handoff procedure using mobile ip
    Interdomain Handoff Procedure Schemesusing 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 Schemesack 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
    2.8.4 Paging domain as its

    • 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 domain as its 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 domain as its 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



    • To page a mobile domain as its

      • 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 domain as its 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



    • a paging initiator initiates paging only when it (ensuring paging initiator knows mobile’s latest paging area)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 (ensuring paging initiator knows mobile’s latest paging area)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
    3. Mobility Management in 3GPP Paket Networks (ensuring paging initiator knows mobile’s latest paging area)

    • 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 Conceptual Network Architecture (Release 5) (ensuring paging initiator knows mobile’s latest paging area)



    Components
    Components (Release 5)

    • 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 (Release 5)

    • GERAN

      • divided into Base Station Subsystems (BSS)

    • BSS

      • consists of one or multiple Base Transceiver Stations (BTSs) and Base Station Controllers (BSCs)


    • BSC (Release 5)

      • 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 (Release 5)

    • UTRAN

      • divided into Radio Network Subsystems (RNS)

    • RNS

      • consists of one or multiple Node Bs controlled by a Radio Network Controller (RNC)


    • RNC (Release 5)

      • 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
    Core Network (Release 5)

    • CN

      • support both circuit-switched (CS) and packet-switched (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 point-to-point CS calls

        • basic PS services

          • routing and transport of user IP packets


    • advanced CS services (Release 5)

      • 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 (Release 5)

      • 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 (Release 5)

      • 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)



    Protocol reference model for 3gpp ps domain
    Protocol Reference Model for entities3GPP PS Domain


    Packet data protocols bearers and connections for packet services
    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 Services

      • 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



    Traffic bearers structure supporting packet switched services
    Traffic Bearers Structure Supporting ServicesPacket-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 Services

      • 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



    • The Servicessignaling 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 Services and traffic connections between mobile and SGSN

      • Radio Resource Control (RRC) connection

      • Radio Access Network Application Part (RANAP) connection


    • Radio Resource Control (RRC) connection Services

      • 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




    Mobility management in 3gpp packet networks
    Mobility Management in 3GPP ServicesPacket 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 Services

      • 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 Servicesexchange 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 Services

      • 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 in 3GPP ServicesPacket-Switched Domain

    • Scope of mobility

      • Inter-Node B handoff

      • Inter-RNC handoff

      • Inter-SGSN handoff

      • Inter-GGSN handoff


    • Inter-Node B Handoff Services

      • 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 Services

      • change Radio Bearers

      • change Iu Bearers

      • update mobile's PDP context

      • establish a new CN Bearer


    • Inter-GGSN Handoff Services

      • 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
    3.1 Packet Mobility Management (PMM) Context and States Services

    • 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 Services

      • 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 Services

      • not directly involved in location tracking

      • does not need to know any mobile’s PMM context or PMM state



    Pmm detached state
    PMM-DETACHED State following states (for UMTS)

    • 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
    PMM-CONNECTED State following states (for UMTS)

    • 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 following states (for UMTS) 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
    PMM-IDLE State following states (for UMTS)

    • 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
    3GPP PMM State Transition Machines following states (for UMTS)


    Pmm detached state to pmm connected state
    PMM-DETACHED State to following states (for UMTS)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
    PMM-CONNECTED State to following states (for UMTS)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
    PMM-IDLE State to following states (for UMTS)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
    PMM-CONNECTED State to following states (for UMTS)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
    PMM-IDLE State to following states (for UMTS)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
    Discussions following states (for UMTS)

    • PMM context cannot change from PMM-DETACHED to PMM-IDLE directly

      • before a mobile’s PMM context can be in PMM-IDLE 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 1 location concepts
    3.2.1 Location Concepts following states (for UMTS)

    • 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 following states (for UMTS)

      • 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
    3GPP Location Management following states (for UMTS)for Packet Services


    • LA following states (for UMTS)

      • 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)



    • RA perform location update with CN CS domain

      • 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)



    • LAI Identifier

      • 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 Identifier

      • 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
    3.2.2 Location Tracking Identifier

    • 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 IdentifierRRC 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 Identifier

      • 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
    Location Tracking Depends on Mobile’s RRC Connection Mode Identifier

    • 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 IdentifierRA Update toward CN upon receiving MM system information, indicating that it moved into a new RA


    • When a mobile is in RRC-CONNECTED mode Identifier

      • 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 IdentifierMM 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





    • Serving RNS a Relocation Procedure

      • the process for relocating RNC side of endpoint of an Iu bearer from one RNC to another


    3 3 routing area update
    3.3 Routing Area Update a

    • 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 a

      • 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 a RA update when

      • mobile enters a new RA

      • mobile’s periodic routing area update timer expires


    • Types of RA update a

      • 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
    3.3.1 Intra-SGSN Routing Area Update a

    • 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




    • Old RAI main information

      • 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 main information

      • 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 non-radio-related capability

      • it includes, for example, information needed for performing ciphering and authentication


    Footnote
    Footnote main information

    • 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) main information

      • 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



    3gpp intra sgsn routing area update procedure
    3GPP Intra-SGSN Routing Area main informationUpdate Procedure


    • [Step 1] Mobile initiates RA update by sending a main informationRAUR 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)



    • [Step 2] main informationTarget 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 P-TMSI Signature for P-TMSI) to validate P-TMSI


    • as target SGSN is main informationidentical 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 requires 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 requires acceptance of new P-TMSI by returning a Routing Area Update Complete (RAUC) message to SGSN, which completes RA Update procedure


    3 3 2 inter sgsn routing area update
    3.3.2 Inter-SGSN Routing Area Update requires

    • [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) requires

    (3)

    (2)

    (4)

    (5)

    (6)

    (7)

    (8)

    (9)

    (10)

    (11)

    (12)

    (13)

    (15)

    (14)

    (16)

    (17)

    (18)

    (19)

    (20)

    (21)

    (22)

    3GPP Inter-SGSN Routing Area Update Procedure


    • for an inter-SGSN RA update requires

      • 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 requires SGSN Context Requestmessage 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 follows

      • 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



    Footnote1
    Footnote follows

    • 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
    Footnote (cont.) follows

    • 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 cont1
    Footnote (cont.) follows

    • PDP Context Activation

      • MS可藉由此程序和GGSN間建立PDP Context

      • MS將依據使用者的服務需求,要求與網路端建立符合QoS的傳輸通道

      • 網路端若接受MS的QoS需求,則可完成PDP Context的建立,內容將分別記錄於MS、SGSN及GGSN中



    • upon followsnegative 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 follows

      • 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



    • [Step 7] message

      • 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] message

      • 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



    • [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 source SGSN

      • 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 G source SGSNr interface to interact with HLR for location update by sending an Update Locationmessage

  • [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 I source SGSNu 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 Datamessage

    • [Step 19] Target SGSN records mobile’s service subscription information and responds to HLR with an Insert Subscriber Data ACKmessage


    • [Step 20] Now, HLR will send source SGSNUpdate Location ACKmessage 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


  • [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
    3.4 Serving RNS Relocation source SGSN

    • 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



    • When a mobile connects to a target RNC RA Update

      • 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 RA UpdateIu 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 RA Update

      • 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 RA Update

      • 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) RA Update

    (2)

    (3)

    (4)

    (5)

    (6)

    (7)

    (8)

    (9)

    (10)

    (13)

    (11)

    (14)

    (12)

    (15)

    (16)

    (17)

    (18)

    (19)

    (20)

    3GPP Serving RNS Relocation


    • [Step 1] When source RNC decides to initiate S-RNS-RP RA Update

      • it sends a RANAP Relocation Requiredmessage 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 S-RNS-RP


    • if relocation Type is “UE not Involved” RA Update

      • 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 S-RNS-RP


  • if relocation Type is “UE Involved”

    • mobile will also need to get involved in S-RNS-RP to relocate its RRC connection to target RNC


    • source ID RA Update

      • identifier of source RNC

    • target ID

      • identifier of target RNC


    • source RNC to target RNC transparent container RA Update

      • 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 RA Updatedetermines 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 RANAPForward Relocation Requestmessage to target SGSN to request target SGSN to establish Iu connection for mobile


    • target SGSN will then send a RANAP RA UpdateRelocation 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 RA Update

      • 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 RA Updatetarget RNC has allocated all necessary resources for all required RABs

      • target RNC will send a RANAPRelocation Request Acknowledgemessage 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 RA UpdateRANAPForward Relocation Responsemessage 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 RA Updatesource 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 Commitmessage, 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 to target RNCRANAPRelocation Detectmessage 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 to target RNCRelocation Detect message

      • target RNC will start to serve as serving RNC for mobile and will start to send RAN Mobility Informationmessages 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 to target RNCuplink 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 Confirm messagestarts 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
    3.5 Hard Handoffs Confirm message

    • 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 Confirm message

      • 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) Confirm message

    (2)

    (3)

    (4)

    (5)

    (6)

    (7)

    (8)

    (9)

    (10)

    (11)

    (12)

    (13)

    (14)

    (15)

    (16)

    (17)

    (18)

    (19)

    (20)

    (23)

    (21)

    (22)

    3GPP PS Domain Hard Handoff (Inter-SGSN Handoff)


    • [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 RANAPRelocation Requiredmessage to source SGSN and sets Relocation Type to “UE Involved”



    • [Step 2] If it is an inter-SGSN handoff get involved in S-RNS-RP to relocate its RRC connection to target RNC

      • 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 I get involved in S-RNS-RP to relocate its RRC connection to target RNCu 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 10-13] Source RNC sends a get involved in S-RNS-RP to relocate its RRC connection to target RNCForward 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





    3 6 paging initiated by packet switched core network
    3.6 Paging Initiated by Packet-Switched Core Network completion by sending a

    • When a SGSN receives downlink user data or signaling messages destined to a mobile in PMM-IDLE state

      • SGSN initiates paging by sending a RANAPPaging message to every RNC in the Routing Area in which the mobile is located


    3gpp paging in packet switched domain
    3GPP Paging in Packet Switched Domain completion by sending a



    • CN completion by sending a 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 completion by sending a 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 2 Paging an RNC in RAN

      • 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
    3.7 Service Request Procedure an RNC in RAN

    • 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) an RNC in RAN

    (2)

    (3)

    (4)

    (5a)

    (6)

    (7)

    (8)

    (9)

    3GPP Mobile-Initiated ServiceRequest Procedure


    • [Step 1&2] Mobile has to establish an an RNC in RANRRC 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 an RNC in RANDATA

      • 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 an RNC in RANSIGNALING

      • 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 an RNC in RANacknowledged 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 statere-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 stateSGSN-initiated PDP De-Activation 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 De-Activation procedure to delete an active PDP context


  • 3 8 handoff and roaming between 3gpp and wireless lans
    3.8 Handoff and Roaming Between 3GPP and Wireless LANs state

    • 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
    Handoff between 3GPP and IP stateNetworks using Mobile IP


    • Mobility service provider state

      • 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 state

      • 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 statereceive 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
    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 to 3GPPregisters 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 to 3GPPForeign 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
    Sample Signaling Flow for Handoff to 3GPPbetween 3GPP and IP Networks using MIPv4


    ad