On Integrated Location and Service Management for Minimizing Network Cost in Personal Communication

1
On Integrated Location and ServiceManagement for
Minimizing Network Cost inPersonal Communication
Systems

• Ing-Ray Chen, Baoshan Gu, and Sheng-Tzong Cheng

Presented by Iman Saleh Hardik Patel
2
Agenda

• Introduction
• Problem Specification
• System Model
• Integrated Location and Service Management
  Schemes
• Cost Models
• Performance Evaluations
• Conclusion

3
Introduction
Personal Communication System (PCS)
4
Introduction (Contd)

• Personal Communications Service (PCS) provides a
  wide range of information services, such as
  personal banking service, personalized stock
  market information, location dependent travel
  information, etc. for which a mobile user (MU)
  sends requests to a server and the server sends
  replies to the mobile user.
• Constraints User is not static
• How to tackle problem of personal mobility of MU
  in PCS.
• Suggestions Create per-user service proxy for
  each mobile user to tackle the problem of
  personal mobility.
• Objective Reduce communication cost for service.

5
Approaches to tackle problem of PCS

• The service proxy
• Performs tasks such as tracking locations of the
  MU
• Maintaining service context information for the
  service engaged
• Accepting service requests from the MU
• Transforming requests into proper formats and
• Forwarding server replies to the MU.
• The personal proxy
• Explicitly tracks the MU location
• Eliminates the overhead for the server
  application to first check with the underlying
  location management system to know the current MU
  location before data delivery.

6
Contd

• Shortcomings
• Since all client-server communications must go
  through the personal proxy, if the personal proxy
  is static in location, it is likely that
  inefficient server-proxy-MU triangle routes may
  be used for data delivery, resulting in high
  communication costs.
• If the proxy is mobile to stay closer to the MU,
  extra network costs will be incurred to inform
  the server applications of the address change
  whenever the proxy changes its location.

7
Alternative

• Divided the problem in two sets
• Location Management
• the most popular scheme in PCS networks is the
  basic Home Location Register/Visitor Location
  Register (HLR/VLR)
• Each MU has an HLR. Whenever an MU enters a VLR,
  the system updates its HLR location database so
  that, when a call arrives, the HLR location
  database knows exactly which VLR contains the MU.
• Service management
• Allows an MU to maintain ongoing connections
  while roaming among different VLRs and enables
  the MU to inform its HLR.
• The proxy used to forward messages to an MU must
  explicitly track the location of the MU.
• The extra communication costs are incurred to
  notify the proxy when the MU moves across a
  location registration area boundary

8
Problem Specification

• Investigate the notion of integrated location and
  service management for minimizing network cost
  without making the assumption of fully replicated
  servers in VLRs in the PCS network.
• Investigate and identify the best integrated
  location and service management scheme that can
  be applied on an individual user basis to
  minimize the overall cost incurred to the PCS
  network per time unit for servicing location and
  service operations of all users.

9
Approach to the solution Key concepts

• Use a per-user service proxy as a gateway between
  the MU and all client-server applications engaged
  by the MU concurrently.
• The proxy keeps track of service context
  information such as the current state of the
  execution for maintaining service continuity.
• We always co-locate the MUs service proxy with
  the MUs location database that stores the
  current location of the MU, so that the service
  proxy knows the current location of the MU all
  the time.
• Location handoff Whenever the MU moves across a
  registration area boundary, a location handoff
  occurs for the location management system to
  update the location database.
• Service handoff Updating the service proxy when
  location handoff occurs.

10
PCS Signaling Network Architecture
11
PCS system Challenge

• Managing services in roaming environment

• How to find new VLR?
• Overhead by VLR in contacting HLR !!

12
Basic HLR/VLR scheme

• A mobile user is permanently registered under a
  location register HLR.
• When the mobile user enters a new VLR area, it
  reports to the new VLR, which, in turn, informs
  the HLR by means of a location update operation.
• When a call is placed, the system first searches
  the MUs current location through the HLR and
  then the call is delivered.

13
Integrating location and service management.

• The VLR which performs the last registration
  operation with the HLR will become the anchor in
  an anchor area.
• Within an anchor area, we use a local anchor to
  maintain a location management database to keep
  track of the location of the MU within the anchor
  area.
• Anchor area may cover a large geographic area
  spanning several VLRs, when an MU crosses a VLR
  boundary, it may still be in the anchor area.
• Advantage A location update operation within the
  anchor area is only processed by the anchor
  without going to the HLR database, thus reducing
  the communication cost for update operations.

14
Integrating location and service management.

• Service handoff Migrates the service proxy and
  involves two operations
• an address-change operation to inform all
  application servers of the location change
• a service context transfer
• A service handoff occurs when a location handoff
  occurs as a location boundary area is crossed by
  the MU.
• A location handoff and a service handoff would
  occur when the MU crosses an anchor boundary in
  the integrated scheme.

15
Integrated Location and Service Management Schemes

• Centralized
• Fully Distributed
• Dynamic Anchor
• Static Anchor

16
Parameters
17
Parameters (Contd)
18
Parameters (Contd)
19
Centralized Scheme

• Service proxy and HLR centralized and colocated
• MU moves across a VLR boundary gt location update
  operation to the HLR/proxy
• Call placed by MU gt search operation at the
  HLR/proxy database
• MU requests service gtsend request to the server
  through the service proxy gt high communication
  cost
• Server replies to MU request gt send reply to the
  MU through the service proxy gt high
  communication cost
• Cupdate T
• Csearch T
• Cservice T T
• CTotal T? T ? 2T ?

20
Fully Distributed Scheme

• MU moves into a new VLR gt location and service
  handoffs
• The location handoff
• location update operation to the HLR and server
  (same as in the centralized scheme)
• service proxy migrated to new VLR
• The search request
• HLR database is accessed to know current VLR
• MU found within current VLR
• Cupdate T Mcs ?3 NsT
• Csearch T
• Cservice T
• Ctotal (T Mcs ?3 NsT)? T ? T ?

21
Dynamic Anchor Scheme

• Location Update
• If (this is an anchor boundary crossing movement)
• A location update message is sent to the HLR
  through the new VLR
• The service context is moved to the new VLR who
  now serves as the new anchor
• A location update message is sent to all
  application Servers
• Else
• The new VLR sends location update message to the
  anchor

22
Dynamic Anchor Scheme (Contd)

• Call Delivery
• If (the local anchor is the current serving VLR)
• The anchor sends a response to the HLR that the
  MU is found
• Else
• The local anchor forwards the request to the
  current serving VLR
• The current VLR sends a location response to the
  HLR
• The HLR updates its record such that the current
  VLR becomes the new anchor
• The service context is moved to the current VLR
  (who is the new anchor)
• A location update message is sent to all
  application servers

23
Dynamic Anchor Scheme (Contd)

• Service Request
• If (the current VLR is the local anchor)
• The request is sent to the server and then a
  response is sent back to the MU
• Else
• The current VLR forwards the request to the
  anchor
• The anchor forwards the service request/response
  to the server/MU

24
Dynamic Anchor Scheme (Contd)
25
Dynamic Anchor Scheme (Contd)

• Call delivery
• Call arrives and Cs is filled with a token
• If mark(Flag) gt 0
• ServNonCvdC is enabled and current VLR is not
  same as anchor VLR
• HLR is queried to locate the anchor anchor
  queries the current serving VLR and MUs location
  is returned
• Anchor is moved to current VLR
• If mark(Flag)0
• ServCvdC is enabled and current VLR is same as
  anchor VLR
• HLR is queried to locate the anchor anchor
  returns the MUs location immediately

26
Dynamic Anchor Scheme (Contd)

• Location update
• When MU moves, token is placed in Ms
• If movement is intra-anchor with probability InA
• ServInM is enabled and a local anchor update is
  performed
• mark(Flag) gt 0 indicating current VLR ! anchor
  VLR
• If movement is inter-anchor with probability OutA
• ServOutM is enabled and the HLR is updated with
  current VLR (new anchor)
• service context is transferred from old anchor to
  new anchor and,
• application servers are updated with new address
  of proxy
• mark(Flag) 0 indicating current VLR anchor
  VLR

27
Dynamic Anchor Scheme (Contd)

• Service request
• MU sends a service request and token is placed in
  Ss
• If mark(Flag) gt 0
• ServNonCvdS is enabled and current VLR is not
  anchor VLR.
• Request is sent to service proxy colocated with
  local anchor to forward to server
• Service proxy is co-located with anchor, so no
  extra cost to obtain MUs current location
• If mark(Flag) 0
• ServCvdS is enabled and current VLR is the anchor
  VLR
• Service proxy is co-located with anchor VLR

28
Dynamic Anchor Scheme (Contd)

• System costs
• Expected search cost
• Expected location update cost
• Expected service request cost

29
Dynamic Anchor Scheme (Contd)
30
Static Anchor Scheme

• Same as the Dynamic Anchor scheme except that the
  anchor will remain at a fixed location as long as
  the MU stays in the same anchor area.
• The anchor moves only when the MU moves across an
  anchor boundary

31
Static Anchor Scheme (Contd)
32
Static Anchor Scheme (Contd)

• Anchor is fixed in an anchor area until the MU
  departs from that area
• Call delivery
• Cost from the HLR to the anchor (T) anchor to
  the current VLR ( )
• Location update
• If movement is intra-anchor with probability InA
• ServInM is enabled and a local anchor update is
  performed
• If movement is inter-anchor with probability OutA
• ServOutM is enabled and HLR is updated with new
  anchor information
• Service context is transferred from old to new
  anchor
• Application servers are informed of the new
  anchor

33
Static Anchor Scheme (Contd)

• Service request
• MU sends a service request and a token in placed
  in Ss
• ServS is enabled and service request is routed
  from the MU, to the proxy co-located with the
  anchor VLR and to the server

34
Static Anchor Scheme (Contd)
35
Performance Evaluation - Parameterization
Where Cvl Cost of transmitting a message (round
trip) between a VLR and its LSTP. Clr Cost of
transmitting a message (round trip) between an
LSTP and its RSTP. Cpstn Communication cost
(round trip) to pass through a PSTN. The
communication between a VLR and the HLR will
traverse through a VLR-LSTP-RSTP-PSTN path
sequence.
36
Performance Evaluation - Parameterization
Dynamic Anchor Scheme
Static Anchor Scheme
Where Cvl Cost of transmitting a message (round
trip) between a VLR and its LSTP. Clr Cost of
transmitting a message (round trip) between an
LSTP and its RSTP. Cpstn Communication cost
(round trip) to pass through a PSTN. The
communication between a VLR and the HLR will
traverse through a VLR-LSTP-RSTP-PSTN path
sequence.
37
Performance Evaluation
Cost rate under different CMR and SMR values.
38
Performance Evaluation
Cost rate under different Call to Mobility Ratio
(CMR) values
39
Performance Evaluation
Cost rate under different Service to Mobility
Ratio (SMR) values
40
Performance Evaluation
Cost rate under different context transfer cost
values
41
Performance Evaluation
Integrated versus decoupled location and service
management best cost rate under different SMR
values.
42
Performance Evaluation
Cost rate under different SMR values.
43
Conclusion

• The dynamic anchor scheme performs the best in
  most conditions except when the context transfer
  cost is high (when the server is heavy).
• The centralized scheme performs the best at low
  SMR and high CMR.
• The fully distributed scheme performs the best at
  high SMR and high CMR.
• The static anchor scheme is a relatively stable
  scheme, performing reasonably well under a wide
  range of parameter values examined in the paper.
• Different users with vastly different mobility
  patterns should adopt different integrated
  location and service management methods to
  optimize system performance.

44

• Thank You