On Integrated Location and Service Management for Minimizing Network Cost in Personal Communication Systems Ing-Ray Chen, Baoshan Gu, and Sheng-Tzong Cheng Presented by: Iman Saleh Hardik Patel
Agenda Introduction Problem Specification System Model Integrated Location and Service Management Schemes Cost Models Performance Evaluations Conclusion
Introduction 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.
Personal Communications Service (PCS) Servers Stock Market Weather Info Requests Replies
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.
Cont d 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.
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
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.
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 MU s service proxy with the MU s 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.
PCS Signaling Network Architecture
PCS system: Challenge Managing services in roaming environment Server HLR VLR VLR VLR How to find new VLR? Overhead by VLR in contacting HLR!!
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 MU s current location through the HLR and then the call is delivered.
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.
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.
Integrated Location and Service Management Schemes Centralized Fully Distributed Dynamic Anchor Static Anchor
Parameters
Parameters (Cont d)
Parameters (Cont d)
Centralized Scheme Service proxy and HLR centralized and colocated MU moves across a VLR boundary => location update operation to the HLR/proxy Call placed by MU => search operation at the HLR/proxy database MU requests service =>send request to the server through the service proxy => high communication cost Server replies to MU request => send reply to the MU through the service proxy => high communication cost Cupdate = T; Csearch = T; Cservice = T + T; CTotal = T*σ + T *λ + 2T * γ
Fully Distributed Scheme MU moves into a new VLR => location and service handoffs The location handoff location update operation to the HLR and proxy (same as in the centralized scheme) service proxy migrated to new VLR HLR and Server updates with new location 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 * γ
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
Dynamic Anchor Scheme (Cont d) 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
Dynamic Anchor Scheme (Cont d) 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
Dynamic Anchor Scheme (Cont d)
Dynamic Anchor Scheme (Cont d) Call delivery Call arrives and Cs is filled with a token If mark(flag) > 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 MU s 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 MU s location immediately
Dynamic Anchor Scheme (Cont d) 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) > 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
Dynamic Anchor Scheme (Cont d) Service request MU sends a service request and token is placed in Ss If mark(flag) > 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 MU s current location C If mark(flag) = 0 ServNonCvdS = T +τ 1 ServCvdS is enabled and current VLR is the anchor VLR Service proxy is co-located with anchor VLR C ServCvdS = T
Dynamic Anchor Scheme (Cont d) System costs Expected search cost C da search = N i= 1 P i C da i, call Expected location update cost C da update i= 1 Expected service request cost = N P C i da i, update C da service = N i= 1 P i C da i, service
Dynamic Anchor Scheme (Cont d)
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
Static Anchor Scheme (Cont d)
Static Anchor Scheme (Cont d) 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 ( τ1 ) C ServC = T +τ 1 Location update If movement is intra-anchor with probability InA ServInM is enabled and a local anchor update is performed C ServInM = τ 1 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 CServInM = T + M cs *τ 2 + N T s
Static Anchor Scheme (Cont d) 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 C ServS = T +τ 1
Static Anchor Scheme (Cont d)
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.
Performance Evaluation Cost rate under different CMR and SMR values.
Performance Evaluation Cost rate under different Call to Mobility Ratio (CMR) values
Performance Evaluation Cost rate under different Service to Mobility Ratio (SMR) values
Performance Evaluation Cost rate under different context transfer cost values
Performance Evaluation Integrated versus decoupled location and service management: best cost rate under different SMR values.
Performance Evaluation Cost rate under different SMR values.
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.
Thank You