Transaction Management in Mobile Database Systems

Transaction Management in Mobile Database Systems
Mobile Database Systems
Vijay Kumar
Computer Science and Informatics
University of Missouri-Kansas City
Mobile Database Systems
Mobile Database Systems
Vijay Kumar
Computer Science and Informatics
University of Missouri-Kansas City
Copyright 02006 by John Wiley & Sons, Inc. All rights reserved.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey.
Published simultaneously in Canada.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form
or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as
permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior
written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to
the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax
(978) 750-4470, or on the web at Requests to the Publisher for permission should
be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ
07030, (201) 748-601 1, fax (201) 748-6008, or online at
Limit of LiabilityiDisclaimer of Warranty: While the publisher and author have used their best efforts in
preparing this book, they make no representations or warranties with respect to the accuracy or
completeness of the contents of this book and specifically disclaim any implied warranties of
merchantability or fitness for a particular purpose. No warranty may be created or extended by sales
representatives or written sales materials. The advice and strategies contained herein may not be
suitable for your situation. You should consult with a professional where appropriate. Neither the
publisher nor author shall be liable for any loss of profit or any other commercial damages, including
but not limited to special, incidental, consequential, or other damages.
For general information on our other products and services or for technical support, please contact our
Customer Care Department within the United States at (800) 762-2974, outside the United States at
(317) 572-3993 or fax (317) 572-4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may
not be available in electronic format. For information about Wiley products, visit our web site at
Zibray of Congress Cataloging-in-Publication Data:
Kumar, Vijay, 1946Mobile database systems / %jay Kumar
p. cm.
ISBN-13 978-0-47 14-6792-2
ISBN-I0 0-471-46792-8 (cloth)
1. Mobile communication systems. 2. Mobile computing. I. Title
TK6570.M6K87 2006
Printed in the United Statcs of America
1 0 9 8 7 6 5 4 3 2 1
1 Mobile Database System
1.1 introduction
1.1.1 Fully Connected information Space
1.2 Types of Mobility
1.3 Summary
2 Wireless Network Communication
2.1 Introduction
2.1.1 Radio Frequency - Spectrum and Band
2.1.2 Cellular Communication
2.2 Continuous Connectivity
2.2.1 Structure of a Channel
2.2.2 Absence of Free Channel
2.2.3 Signal Fading
2.2.4 Frequency Reuse
2.2.5 PCS andGSM
2.2.6 PCS - Personal Communication Service
2.2.7 Interface
2.2.8 Call Processing
2.2.9 GSM - Global System for Mobile Communication
2.3 Summary
3 Location and Handoff Management
3.1 Introduction
3.1.1 Location Management
3.1.2 Handoff Management
3.1.3 Roaming
3.2 Summary
Fundamentals of Database Technology
4.1 Conventional Database Architecture
4.1.1 Database Partition and Distribution
4.2 Database Processing
4.2.1 Transaction Structure
4.3 Serialization of Transactions
4.3.1 Serializability-Based Correctness Criteria
4.3.2 Serializability Theory
4.3.3 Degree of Isolation
4.4 Advanced Transaction Models
4.4.1 Nested Transaction Model
4.4.2 SAGA
4.4.3 Cooperative Transaction
4.4.4 ConTract
4.4.5 Flex Transaction
4.5 Summary
5 Introduction to Concurrency Control Mechanisms
5.1 Introduction
5.1.1 Ways of Locking Data Items
5.1.2 The Phantom Problem
5.1.3 Multigranularity Locking
Heuristic Approach in Locking Schemes
Non-Locking-Based Schemes
Mixed Approaches
Multiversion Approach
Optimistic Concurrency Control Mechanisms
Two-Phase Locking for Distributed Database
6 Data Processing and Mobility
6.1 Introduction
6.2 Effect of Mobility on the Management of Data
6.2.1 Data Categorization
6.2.2 Location Dependent Data Distribution
6.3 Summary
7 Transaction Management in Mobile Database Systems
7.1 Mobile Database System
7.2 Transaction Execution in MDS
7.3 Mobile Transaction Model
7.4 Execution Model based on ACID Transaction Framework
7.4.1 Execution Model with Reporting Transaction
7.4.2 Two-Level Consistency Model
7.4.3 Pro-Motion: Proactive management of Mobile
7.5 Pre-write Transaction Execution Model
7.5.1 Pre-write Execution in Mobile Database Systems
7.6 Mobile Transaction Model
7.6.1 HiCoMo: High Commit Mobile Transaction Model
7.6.2 Moflex Transaction Model
7.6.3 Kangaroo Mobile Transaction Model
7.6.4 MDSTPM Transaction Execution Model
7.6.5 Mobilaction-A Mobile Transaction Model
7.6.6 Atomicity for Mobilaction
7.6.7 Isolation for Mobilaction
7.6.8 Consistency and Durability for Mobilaction
7.7 Data Consistency in Intermittent Connectivity
The Consistency Model
7.8.1 The Extended Database Operation Interface
7.8.2 Data Correctness
7.9 Weak Connectivity Operation
7.9.1 Correctness Criterion
7.9.2 The Serialization Graph
7.9.3 Protocols
7.10 A Consistency Restoration Schema
7.10.1 Correctness Criterion
7.10.2 The Serialization Graph
7.10.3 Protocol
7.11 Discussion
7.12 Related Work
7.13 Concurrency Control Mechanism
7.13.1 Locking-Based CCMs
7.13.2 CCM Based on Epsilon Serializability
7.13.3 Relationship with ESR
7.14 Transaction Commit
7.14.1 Two-Phase Commit Protocol - Centralized 2PC
7.14.2 Node Failure and Timeout Action
7.14.3 Decentralized 2PC
7.14.4 Linear or Nested 2PC
7.15 Commitment of Mobile Transactions
7.15.1 Commit Protocols for Mobilaction
7.16 Transaction Commitment in Mobile Database Systems
7.16.1 TCOT Steps-No Failure
7.16.2 Node Failure-Fragment Compensation
7.16.3 TCOT with Handoff
7.16.4 Special Cases
7.16.5 An Alternate TCOT Protocol
7.16.6 Correctness
7.17 Summary
8 Mobile Database Recovery
8.1 Introduction
8.2 Log Management in Mobile Database Systems
8.2.1 Where to Save the Log?
Mobile Database Recovery Schemes
8.3.1 A Three-Phase Hybrid Recovery Scheme
8.3.2 Low-Cost Checkpointing and Failure Recovery
8.3.3 A Mobile Agent-Based Log Management Scheme
8.3.4 Architecture of Agent-Based Logging Scheme
8.3.5 lnteraction Among Agents for Log Management
8.3.6 Forward Strategy
8.3.7 Forward Log Unification Scheme
8.3.8 Forward Notification Scheme
8.4 Summary
9 Wireless Information Broadcast
9.1 Introduction
9.1.1 Data Broadcast Mode
9.1.2 Push Advantages and Disadvantages
9.2 Broadcast Disk
9.3 Broadcast Infrastructure
9.3.1 Data Access Frequency
9.3.2 Data Access Time
9.3.3 Broadcast Indexing
9.3.4 Nonclustering Index
9.3.5 Multiple Indexes
9.3.6 Dynamic Organization
9.4 Exponential Index
9.4.1 Generalized Exponential Index
9.5 Location-Based Indexing
9.5.1 Location Index Scheme
9.6 On-Demand Data Scheduling
9.7 Data Dissemination System
9.7.1 Data Staging with Surrogates
9.8 Summary
21 1
25 8
26 1
28 1
29 1
List of Figures
A fully connected information space.
Terminal mobility.
Personal mobility.
Cell coverage through circles and hexagons.
Location of cell site.
Communication link.
Downlink and uplink channels.
Channel structure.
Alternate representation of channel structure.
Strength of signal received by a mobile unit from the base
A typical mulipath absorption scenario.
A typical handoff scenario.
2.10 A typical handoff initiation.
2.11 Clusters of different sizes.
2.12 Frequency reuse distance.
2.13 Properties of a regular hexagon.
2.14 Identification of frequency reuse cell.
2.15 Computation of frequency reuse distance D.
2.16 Cluster replication.
2.17 Reuse cell identification.
2.18 Generic PCS architecture.
2.19 A reference architecture of PCS.
2.20 Home Location Register (HLR) database.
2.21 Mobile-to-land call setup. (Reproduced with permission
from Wireless PCS, McGraw-Hill.)
2.22 Land-to-mobile call setup. (Reproduced with permission
from Wireless PCS, McGraw-Hill.)
2.23 A reference architecture of GSM.
Location search steps.
Location update steps.
Transient loop in forward pointer scheme.
Location search using forward pointer.
Cell overlap region.
Nonprioritized scheme steps. (Reproduced from Wireless
and Mobile Network Architectures under written permission
of John Wiley & Sons.)
Reserved channel scheme steps. (Reproduced from Wireless
and Mobile Network Architectures under written permission
of John Wiley & Sons.)
Queuing priority scheme steps. (Reproduced from Wireless
and Mobile Network Architectures under written permission
of John Wiley & Sons.)
Subrating scheme steps. (Reproduced from Wireless and
Mobile Network Architectures under written permission of
John Wiley & Sons.)
3.10 Channel transfer in intracell handoff.
3.11 Channel transfer between two BSs with one BSC.
3.12 Channel transfer between two BSs connected to two BSCs.
3.13 Channel transfer between two BSs with two BSCs connected
to two MSCs.
Architecture of centralized database systems.
Architecture of distributed database systems.
Lost update problem.
Inconsistent retrievals.
Correct executions of T7 and T8.
A serialization graph.
A nested transaction model.
Cooperative transaction structure.
Simultaneous locking and simultaneous release protocol.
Incremental locking and simultaneous release protocol.
Simultaneous locking and incremental release protocol.
Incremental locking and incremental release protocol.
A bank database.
Lock instance graph and compatibility matrix.
Conflict resolution of Krishna.
Database partition for LDD.
Database replication restriction.
Reference architecture of a mobile database Ssystem.
Different replication types.
Change of coordinators due to mobility.
Adjacent and nonadjacent cells.
An example of LDD processing.
Transaction execution during mobility.
An example of location inconsistency.
An example of location consistency.
Compact object structure.
7.10 Execution of transactions with pre-read and pre-write.
7.11 Lock compatibility matrices. A X entry indicates that the
lock modes are compatible. (a) Eventual and conservative
h. (b) Eventual and best effort h. (c) Immediate and
conservative h. (d) Immediate and best effort h.
7.12 Execution of transactions under this CCM.
7.13 Intermediate state in CCM.
7.14 Linear ordering of participants and coordinator.
7.15 An entry of a token list.
7.16 Relationship between Et and S,, abort, and compensation.
An example of snapshot generation.
Traditional mobile data access from a broadcast.
Broadcast data access model.
A simple broadcast disk setup.
Access and tuning times in a broadcast.
Three broadcast schedule samples.
Computation of ignore factor for a data item.
Simple broadcast composition.
Indexed broadcast composition.
24 1
Organization of (1, rn) indexing scheme.
24 1
9.10 The organization of relevant index.
9.11 Organization of a file for broadcast.
9.12 Nonreplicated distrjbution.
9.13 Entire path replication.
9.14 Partial path replication-distributed indexing.
9.15 Control index.
9.16 Example of nonclustered indexing.
9.17 Example of multiple attribute indexing.
9.18 Structure of exponential index.
9.19 A simple exponential index.
9.20 A generalized exponential index with T = 2 and I = 2.
9.2 1 Information contents and location hierarchy sets.
26 1
9.22 Broadcast location tree.
9.23 Broadcast composition with LBIS.
9.24 On-demand broadcast setup.
9.25 Transaction response time.
27 1
9.26 DAYS - DAta in Your Space.
9.27 Data staging in DAYS.
9.28 Data staging in DAYS.
List of Tables
Important events in mobile communication
Electromagnetic spectrum and its applications
ECM bands
General mobile frequency table
Broadband spectrum
European mobile systems
Comparison of data distribution schemes
Compatibility matrix of read and write operations
Summary of data replication
Compatibility matrix
Summary of previous mobile transaction models and ACID
Variations of the translation function
Maintaining bounded inconsistency
Message and time complexity in various 2PC
Expected delay with access probabilities [4]
Transactions and data items they need
Dedicated to the One who
taught me the wisdom of
selfless action
It gives me a great pleasure in acknowledging the help I received from my students,
co-researchers, and friends in composing this book. The book is a result of a graduate
course in mobile database systems which I offer every year and my collaborative
research activities. A large portions of the work of my Ph.D. students Nitin Prabhu
and Debopam Acharya’s was included in the book.
I am highly thankful to NSF program directors Maria Zemankova and Bhavani
Thuraisingham for research grants I received from National Science Foundation,
without which I would not have been able to learn about Mobile Database Technology
and conduct some useful research.
A large number of my friends and co-researchers provided me with useful material. I appreciate the generous help I received from Panos Chryanthis, University of Pittsburgh; Evi Pitoura, University of Ionnina; Sanjay Madria, University of
Missouri-Rolla; Margaret Dunham, Southern Methodist University; Karl Abrer, EPL,
Switzerland; Tom Farley (; Krithi Ramamritham, IIT Bombay, India;
Kyong-I Ku and Yoo-Sung Kim, INHA University; and Nam-gu Incheon, Korea. I
wantr to thanks for allowing me to use the terms for preparing
the Glossary.
I am grateful to John Wiley & Sonsfor accepting to publish the book. Val Moliere
was the editor of the book, and she was very helpful in setting up the stage for
launching the book. Thank you Val. I thank Whitney Lesch for her help in bringing
this project to a successful end. 1 thank Amy Hendrickson of Texnology Inc. for
highly needed help in preparing the manuscript.
I am also thankful to IEEE for allowing me to use material from some published
articles free of charge.
This book presents useful information about the management of data on a system
where processors and the entire database or portions of it are moving around in geographical space. The entire mobile database processing paradigm is relatively new
born out of the needs of highly mobile workers. In the beginning the workforce
satisfied their data processing needs by filling their laptops with relevant parts of
the database before they set on a trip. At the end or sometime in the middle of
the trip also then refreshed the main database with up to date data values. However, very soon this intermittent connectivity approach became inadequate to satisfy
global consistency requirements. In addition, the persistent background nagging of
cell phone users for ubiquitous access to desired data added additional urgency for
the development of a system which came to be known as Mobile Database Systems
(MDS).This stimulated database and wireless communities to join forces to look into
this new discipline. Members of these communities-from academia as well as from
industries-accepted the challenge and created a new research direction with several
names such as pervasive computing, ubiquitous computing, nomad computing, anywhere anytime computing. Since mobile data processing became an important area of
research and significant progress has been made in research and development areas.
Along with this a few more new names have been used to identify this discipline and
many more will continue to appear as the area gets more and more matured. One
consoling factor, however, is that everybody has a clear notion of this new discipline
and these names addresses the same concept.
The excitement to write this book morphed into a lot of difficulties. A central problem is the immaturity of research findings. Most of these, such as mobile database
transaction models, concurrency control mechanisms, recovery protocols, location
dependent data, etc., have not been fully deployed and validated in real world. However, there are clear indications that in near future they will become available on most
mobile devices. As mobile database technology is deployed, a plethora of useful
applications will be developed and deployed making MDS an essential gadget for
most of us.
The contents of this book are, therefore, a combination of useful research results
and well-tested schemes and protocols. It contains necessary fundamental database
topics which set the background for transition to mobile database domain. The mobile database chapters contains a good mixture of fundamental topics and research
finding. My main effort has been to illustrate how nicely database technology and
wireless mobility have mingled together and produced this new exciting area. Thus,
this book is a good example of text and edited volume.
The first exciting conversion took place where E-commerce became M-commerce
and pervaded day to day activities of every user. Thus, instead of sitting in front of
their desk tops, they just began to turn on their mobile devices (e.g., cell phones,
laptops, PDAs, etc.) to shop turning conventional “window shopping” into exciting
“mobile internet shopping”. However, our fascination with M-commerce was not
without a lot of traffic hazards. I am not sure now how to distinguish between “Drunk
drivers” and “Internut drivers”. Fortunately this did not deter researchers and developers continued to create complete mobile database systems leaving the traffic police
to deal with “Internut drivers”.
The book begins with a history of wireless and mobile discipline and converges on
topics important for the development of mobile database systems. It then discusses
some basic concepts of database processing with reference to mobility whenever appropriate. It explains why conventional approaches to data processing on mobile
systems would not work satisfactorily and makes a strong case for the development
of new schemes. The book then covers mobile transaction models where execution of
conventional transactions on mobile platforms and new transaction models for mobile
database systems are discussed. None of these models have been implemented and
validated in the real world mainly because at present commercial mobile database
systems do not exist.
All other topics such as concurrency control, database recovery, data broadcast,
broadcast disks, etc., have been discussed in a similar style. I believe that most
instructors will find this book useful in introducing the mobile discipline to their students. I believe that the readers will find that their understanding about the current
status of mobile database systems and this discipline’s future research directions will
be greatly improved as a result of reading this book. Some readers may rightly criticize it for its highly research oriented coverage. I agree with them and present my
apologies and promise that the next edition of this book, if it reaches to that level,
would be the first to cover the launch of a complete mobile database system in the
real world. I hope that these readers would waive the punishment this time and give
me one more chance to make the book more useful and to their liking.
University of Missouri-Kansas City
[email protected]
Mobile Database System
The objective of this chapter is to highlight the current trends in information management discipline. It begins with a brief history of mobile and wireless communication
technology and reviews a number of milestones.
Mobility -The Most Desirable Environment
Information retrieval by users with mobile devices such as cell phones, PDA (Personal
Digital Assistant), MP3 music players, etc., has become a common everyday activity.
Navigational systems in vehicles are now a standard accessary like music system.
These gadgets are quite useful and user-friendly because they can retrieve desired
information from databases from anywhere through wireless channels. However,
they have a serious limitation: The information flow in these systems is only from
the server to users. This limitation does not allow users to query or manipulate the
database which can be located anywhere in the world. Consequently, users just have
to contend with what the server sends them, which may not always be accurate or up to
date. In database terminology these system are not capable of managing transactional
Database researchers, practitioners, and commercial organizations have a common
vision of building an information management system on a mobile platform which
is capable of providing full transaction management and database functionality from
anywhere and anytime. The recent advances in mobile discipline clearly indicate that
reaching this ambitious goal is around the corner.
Traditionally, database is processed by immobile processing units: servers or
clients. The spatial coordinates of these processing units are fixed, and users go
to them with their data processing requests. Under this information management
model, both the processing units and their users are immobile at the time of data
processing. This way of managing information has some inherent efficiency problems leading to unacceptably low productivity, and it is not scalable because it is
unable to grow with the present-day information processing needs. Recent changing
social structure, necessity to have stronger connectivity among national and international communities, increasing spatial mobility, and fear of isolation have generated
a very different class of information processing needs and demands. One of the
important aspects of these demands is that a user must be free from temporal and
spatial constraints in processing the desired information which can only be achieved
by geographical mobility during data processing. The inherent immobility of processing units of legacy systems was a serious impediment in achieving the desired
objective. A restricted type of mobility is possible to achieve in conventional systems (TV, music systems, etc). For example, a remote control unit can be connected
to the system with a longer cable to turn the system on and off from anywhere in
the room. Such arrangement did work and was used in many audio systems. However, such cable-assisted mobility was quite troublesome rather than a convenience
and the kind of mobility which is free from visible connecting cables was urgently
The introduction of mobility actually happened through remote control units. A
glance at the history of remote controllers reveals interesting facts [I, 21. The first
remote control unit to activate remote machines was used in Germany, where the
German navy used it to ram enemy ships in World War I. In World War I1 remote
control units were used to detonate bombs and and activate weapons. In the United
States, at the end of the wars, engineers experimented with household activities and
in the late 1940’s introduced automatic garage door openers, which actually marks
the beginning of wireless era in the United States.
In 1952 Zenith developed a remote control called Lazy Bones, but it was not a
mobile device. It was rather connected to the TV set with a long cable. In 1955 a
unit called Flash-o-Matic was introduced, which activated units by throwing light on
light-sensitive cells connected toTV sets. In 1957 Zenith introduced a wireless remote
controller called Space Command, which used ultrasonic as an activation medium.
The partial success achieved through ultrasonic motivated the use of infrared to activate TV sets through remote control unit, which is now an integral part of a large
number of consumer electronics products such as VCRs, stereo systems, electronic
toys, and computer keyboards, to name a few.
On the communication arena, the history of mobility is equally interesting. The
first mobile radio, capable of one-way communication, was developed by Detroit
Police in 1928 [3]. Police passenger cars, referred to as cruisers, were equipped with
radio receivers, which were used to carry detectives and patrol officers. In 1933 two-
way radio communications were introduced, which was first used by the Bayonne,
N.J. police department.
The use of mobile radio systems spread fast, and it became necessary to control
the use of radio frequencies. In 1934 the United States Congress created the Federal Communications Commissions (FCC), which, in addition to regulating land-line
telephone systems, also managed the use of these frequencies. In 1935 Frequency
modulation was invented and developed by a Columbia University professor Maj.
Edwin H. Armstrong, which was used to improve the mobile radio communication.
In 1940 new frequencies between 30 and 40 MHz were made available by the FCC,
which provided the necessary resources to companies and individuals to operate their
own mobile units. In the same year the Connecticut State Police at Hartford and the
majority of police systems around the country converted to FM technology. This
marked the birth of mobile telephony.
On June 17, 1946 in St. Louis, AT&T together with Southwestern Bell made
available the first commercial mobile radio-telephone service to private customers
where mobile users were connected to a public switched telephone network (PSTN).
Their system operated on six channels in the 150-MHz band with a 60-kHz channel
spacing, but undesirable channel interference (e.g., cross-talk in a land-line phone)
soon forced Bell to use only three channels.
Cellular concept originated at Bell Laboratories in 1947 and AT&T began operating a radio telephone that provided service referred to as Highway service between
New York and Boston. This service operated in the 35- to 44-MHz band. This was a
very basic mobile service where a subscriber was given one specific channel for communication. In the same year, the Bell company requested FCC for more frequencies,
which was granted in 1949. However, the FCC distributed these frequencies among
a number of companies, thus creating a competition among them for improving the
quality of service. This helped to increase the number of mobile units significantly
and set the need for automatic dialing capability.
The first fully automatic radiotelephone service started in Richmond, Indiana, on
March 1 , 1948, which eliminated human operator intervention for placing calls. In the
same year (July 1, 1948) the Bell System introduced transistors (a joint invention of
Bell Laboratories scientists William Shockley, John Bardeen, and Walter Braqttain),
which revolutionized every aspect of telephone and communication industries.
By 1950s the Paging systems began to appear and the first phone-equipped car
glided on the road in Stockholm, Sweden - the home of Ericsson’s corporate headquarters. The first user of this system was a doctor-on-call and a bank-on-wheels.
Tom Farley [3] narrates “The apparatus consisted of receiver, transmitter and logic
unit mounted in the trunk of the car, with the dial and handset fixed to a board
hanging over the back of the front seat. It was like driving around with a complete telephone station in the car. With all the functions of an ordinary telephone,
the telephone was powered by the car battery. Rumor has it that the equipment
devoured so much power that you were only able to make two calls - the second
one to ask the garage to send a breakdown truck to tow away you, your car, and
your flat battery. These first car phones were just too heavy and cumbersome and too expensive to use for more than a handful of subscribers. It was not until
the mid-1 960’s that new equipment using transistors were brought into the market. Weighing a lot less and drawing not so much power, mobile phones now left
plenty of room in the trunk-but you still needed a car to be able to move them
In 1956 the Bell System began offering manual radio-telephone service at 450
MHz, a new frequency band assigned to relieve overcrowding. In 1958 the Richmond Radiotelephone Company improved their automatic dialing system by adding
new features to it, which included direct mobile to mobile communications. Other
independent telephone companies and the Radio Common Carriers made similar advances to mobile-telephony throughout the 1950s and 1960s.
In 1964 the Bell System introduced Improved Mobile Telephone Service (IMTS),
which consisted of a broadcast system equipped with a higher-power transmitter.
IMTS succeeded by the badly aging Mobile Telephone System. It worked in full
duplex so people didn’t have to press a button to talk. Talk went back and forth
just like a regular telephone. It finally permitted direct dialing, automatic channel
selection, and reduced bandwidth to 25-30 kHz.
In 1970 the Federal Communication Commission (FCC) allocated spectrum space
for cellular systems and by 1977 AT&T and Bell Laboratories together developed and
began testing of a prototype cellular system. In 1978 public trials of the new system
were started in Chicago with over 2000 trial customers, and in 1979 the first commercial cellular telephone system became operational in Tokyo. In 1981, Motorola and
American Radio telephone started a second U.S. cellular radio-telephone system test
i n the Washington/Baltimore area. By 1982, the slow-moving FCC finally authorized
commercial cellular service for the USA. A year later, the first American commercial analog cellular service or AMPS (Advanced Mobile Phone Service) was made
available in Chicago for public use (41.
In 1985 Total Access Communication System (TACS) was introduced in the United
Kingdom. It is the European version of AMPS and occupies the 900-MHz frequency
band with an RF channel spacing of 25-kHz. ETACS was an extended version of
TACS with more channels. TACS and ETACS are now obsolete and are replaced by
the more scalable and all-digital Global System for Mobile communications (GSM).
TACS was the first real vehicle-mounted mobile communications system, but later
developed into mobile units. In the same year, CNETZ was introduced in Germany
and Radiocom 2000 was deployed in France.
Until now, all system were based on analog communication, which had a number of
limitations. To eliminate some of these limitations in 1987 to 1995, new air interface
protocols such as TDMA (Time-Division Multiple Access), CDMA (Code-Division
Multiple Access), etc., were introduced. Today’s mobile systems are mainly based
on digital technology, but analog systems are in use too. The Table 1.1 chronology
lists important events in mobile communication.
The mobile phones and communication managed to establish apartially connected
informution space, which was free from spatial and temporal constraints. Thus, the
“anytime and any place” connectivity paradigm for voice became very common.
Table 7.1 Important events in mobile communication
L 887
Maxwell speculated the existence of electromagnetic waves.
Hertz showed the existence of electromagnetic waves.
Marconi awarded patent for tuned communication.
Wireless telegraphic connection between England and France established.
Marconi successfully transmits radio signal from Cornwall to Newfoundland.
Marconi received Nobel prize in physics for Voice over Radio system.
Branly developed technique for detecting radio waves.
Marconi demonstrated wireless telegraph.
Marconi patented wireless telegraph.
Detroit police installed mobile receivers police patrol cars.
Mobile transmitters were deployed in most cars.
Armstrong demonstrated Frequency modulation (FM) scheme.
Mobile systems were connected to Public Switched Telephone Network
FCC recognizes mobile radio as new class of service.
Number of mobile users increased more than 500,000.
Number of mobile users grew more than 1.4 million.
Majority of police systems converted to FM.
1960 Improved Mobile Telephone Service (IMTS) introduced.
1976 Bell Mobile used 12 channels to support 543 customers in New York.
1979 NTT/Japan deploys first cellular communication system.
1983 Advanced Mobile Phone System (AMPS) deployed in the United States.
1989 GSM appeared as European digital cellular standard.
1991 US Digital Cellular phone system introduced.
1993 IS-95 code-division multiple-access (CDMA) digital cellular system deployed in the United States.
1994 GSM Global System for Mobile Communications deployed in the United
1995 FCC auctioned band 1.8-GHz frequencies for Personal Communications
System (PCS).
1997 Number of cellular telephone users in the United States increased to 50
2000 Third-generation cellular system standards'? Bluetooth standards?
Fully Connected Information Space
Figure 1.1 introduces the concept of a fully connected information space that people
envision today. Each object of this real world with some functionality is connected
to other object through wireless link. For example, a bank or a person is connected to
conference, bus, submarine, shark, and so on, with bidirectional wireless link. Thus
at any moment a person or a bank or a scuba diver can have complete information
about all other objects. Such wireless link has become essential for this highly mobile and dynamic society. Consider the case of a working parents. Their children
are in different schools, and each parent works at a different place. Each member
of the family would like to have instant access to the situation of their children to
reach them at the time of need. Similarly, the president of a company would like
to have complete information about all activities of his company to manage it efficiently.
Fig, 7.7 A fully connected information space
However, this paradigm could not allow “anytime and any place” data processing
capability, which is an outstanding demand from users and industries alike. Users
desire that a mobile unit (cell phone, PDA, etc.) should have transaction management
capability, which will allow a user to perform everyday activities such as fund transfer,
seat reservation, stock trading, etc., and in addition to this they should be able to access
any information form anywhere in any state: mobile or static. Thus, a user should be
able to access his or her account information, be able to pay bills, be able to buy and
sell shares, etc., and allow a CEO to access his company’s database and offer salary
raises to its employees while traveling on a car or on a plane.
These demands and creative thinking laid down the foundation of “Ubiquitous
Information Management System” or “Mobile Database System (MDS)” which in
essence is a distributed clientherver database system where the entire processing
environment is mobile. The actual database may be static and stored at multiple sites
but the data processing nodes, such as laptop, PDA, cell phones, etc., may be mobile
and can access desired data to process transactions from anywhere and at any time.
The fully connected information space, in addition to wireless communication,
needs transactional services. Today each individual likes to have facility to inanage
information related to him. For example, a user would like to change his personal
profile for adding new call option on his cell phone service. The user would prefer
to have editing capability to edit his profile to incorporate new option himself instead
of reaching to the service provider. A customer would prefer to have facility to execute a fund transfer transaction himself from anywhere to pay for his purchases or
to transfer money among his multiple accounts instead of requesting his bank to do
The mobile discipline defines two types of mobility: (a) terminal mobility and (b)
personal mobility. Each mobility type addresses a different set of mobility problems.
A mobile framework is composed of wired and wireless components and human users.
Its wireless part implements terminal mobility and personal mobility to eliminate some
of the spatial and temporal constraints from data processing activities.
Terminal Mobility: It allows a mobile unit (laptop, cell phone, PDA, etc.) to access
desired services from any location while in motion or stationary, irrespective of who
is carrying the unit. For example a cell phone can be used by its owner and it can also
be borrowed by Tome one else for use. In terminal mobility, it is the responsibility of
the wireless network to identify the communication device. Figure 1.2 illustrates the
notion of terminal mobility. A person at location C (IongitudeAatitude = C) uses the
mobile unit to communicate with the car driver at location A. He can still establish
communication with the driver from a new location D irrespective of the movement
of the car from A to B. The use of a phone card works on this principle. It can be used
from different locations and from different machines such as pay phones, residential
phones, etc.
Fig. 1.2 Terminal mobility
In terminal mobility, from a telecommunication viewpoint, the network connection
point (referred to as a network access/termination point) is identified as not the called
party. Thus, the connection is established between two points and not between the
two persons calling each other. This type of connection in a session allows the use of
communication devices to be shared among anybody.
fig, 1.3 Personal mobility.
Personal Mobility.' In terminal mobility the mobility of a terminal is supported;
that is, the same terminal can be used to connect to the other party from anywhere
by any user. In personal mobility this capability is provided to a human being.
Thus, a user does not have to carry any communication equipment with him; he
can use any communication device for establishing communication with the other
party. This facility requires an identification scheme to verify the person wishing
to communicate. Figure 1.3 illustrates the notion of personal mobility. A person at
location C communicates with the car at location A using his PDA, and from location
D also h e can communicate with the car at location A using his laptop. At present,
personal mobility is available through the web. A user can log on to the web from
different machines located at different places and access his e-mail. The mobile
system extends this facility so that the user can use any mobile device for reaching
the internet. In personal mobility each person has to be uniquely identified, and one
way to do this is via a unique identification number.
There is no dependency relationship between terminal and personal mobility; each
can exist without the other. In personal mobility the party is free to move, and in
terminal mobility the communication unit is free to move.
Voice or data communication can be supported by either types of mobility. However, to visualize a complete mobile database management system both types of
mobility are essential.
This chapter covered historical facts and the emergence of mobile and wireless disciplines and wireless gadgets starting from remote control units. It discussed the
types of mobility necessary to visualize mobile infrastructure and envisioned the
development of a fully connected information space where all functional units are
fully connected with each other through wireless links. It presented the rationale for
the development of a mobile database system necessary to manage all information
management tasks in the information space.
The entire development can be looked at in terms of analog and digital transmission
and data transmission aspects also. The first-generation wireless technology which
was basically analog is usually referred to as First Generation (1G). 1G systems were
deployed only in the business world in the 1980’s. Mobile and cordless phones were
introduced and analog standards were defined. A number of wireless communication
companies such as Nokia (Finland), Motorola (USA), and Ericsson (Sweden), to
name a few, established their firm hold in the communication market.
The popularity of analog wireless technology motivated users to present new demands on the system and soon the limitations of 1G infrastructure became known.
In early 1990’s,therefore, the second generation (2G) wireless technology was introduced which was based on digital transmission. Digital technology provided higher
communication capacity and better accessibility. This marked the introduction of
Global System for Mobile Communication - Groupe SpecialMobile (GSM). Initially
GSM was confined to Europe gradually its standard spread to most other countries
of the world. The 2G mobile units could send not only voice but limited amount of
data as well.
The limited amount of data comniunication capability became one of its serious
limitations of2G system. A number of more powerful mobile phones were introduced
in early 2000’s, which allowed higher voice and data transmission rates and improved
connectivity. This was only a partial enhancement to 2G systems, so it was referred
to as “2.SG” technologies. This allowed e-mails to be received and sent through
2.SG mobile phones which could be connected to laptop or PDA (Personal Digital
2 3 3 technology and system was not quite capable of handling multimedia data
transfer, unrestricted internet access, video streaming, etc. These kind of transfers
became very important for M-commerce community. The Third-Generation (3G)
technology made it possible to achieve these capabilities. 3G made it possible to
provide variety of services through internet and the emphasis moved from voicecentric to data-centric environment. It also helped to establish a seamless integration
of business and user domains for the benefit of the entire society. Thus, 3G technology
made it possible to visualize f u l l y connected injormation space.
The next chapter further discuses mobility and wireless communication technology
necessary to build the desired mobile database system.
1. What is the difference between wireless communication and mobile communication? Explain your answer and give some real-life example to illustrate the
2. Explain the differences between personal mobility and terminal mobility. How
do they affect the scope of wireless communication?
1. R. C. Goertz, “Fundamentals of General-Purpose Remote Manipulators,” Nucleonics, Vol. 10, No. 1 I, Nov. 1952, pp. 36-45.
2. R. C. Coertz, “Electronically Controlled Manipulator,” Nucleonics,Vol. 12, No.
1 1, Nov. 1954, pp. 46-47.
Wireless Network
This chapter deals with the architecture of cellular communication and identifies
essential hardware and software components to build a Mobile Database System
In wireless communication, users communicate without wires. The communication link is established through radio frequencies (RF). The telecommunication system
has to perform a number of steps and go through a number of wired segments for
setting up a wireless communication session between two users. The current wireless
technology is not advanced enough to eliminate these wired segments in setting up
the link to make the process entirely wireless. The future wireless technology, such
as iridium [5, 61, aims to extend the wireless connectivity to mobile systems to cover
remote and sparsely populated areas. It also aims to provide emergency services in
the event of failure of terrestrial wireless services due to natural events such as flood,
earthquake, flood, etc. It is possible that an iridium system may be successful in
reducing the dependency on wired components, but it is highly unlikely that they
could be completely eliminated. However, from the user side it matters little how the
wireless communication is set up; users will continue to enjoy complete mobility in
talking to their partners possibly with increased subscription cost.
Radio Frequency - Spectrum and Band
All forms of wireless communication use electromagnetic waves to propagate information from one place to another. To understand better the management of radio
frequencies (RF), a number of terms are defined below.
Spectrum: The entire range of waves is referred to as a spectrum. Theoretically,
the range of this spectrum spans from zero to infinity. However, only a portion of this
spectrum is suitable for voice or data communication.
Band: Band refers to a range of RFs usable for a particular task which can be
transporting data or voice or something else. To describe the size of this band, the
term bandwidth is used. For example, if a particular device can use RF between 80
and 180 MHz to perform a task, then it is said that the device has a bandwidth of
180 - 80 MHz = 100 MHz. Sometimes, bandwidth is expressed in percentage. For
example, if some device can handle RFs from 80 MHz to 180 MHz, then the device
can handle a 50% bandwidth. The percentage is calculated as follows:
i Calculate the bandwidth: 180 - 80 = 100 MHz.
ii Compute the average: (80 + 180)/2 = 130 MHz.
iii Divide the bandwidth by the average frequency and multiply the result by 100:
(100 t 130) x 100 = 76.92%.
Theoretically, the range of a spectrum spans from zero to infinity. The usable
radio frequencies, however, begin from 3 Hz (hertz) to 3000 GHz (gigahertz). Higher
frequencies ranging from 3 THz (terahertz) to 3000 THz are under consideration for
some use. This spectrum was originally categorized into 26 different bands, each
representing some specific domain of use. The International Telecommunication
Union (ITU) identified 11 bands for radio frequencies ranging from 3 Hz to 300 GHz.
Table 2.1 identifies different frequency bands and their usage. The term electronic
countermeasures (ECM) refers to those bands with a different set of letters. Table
2.2 lists ECM band identification.
This defines the upper limit of RF range. One important consideration is the
selection of a subset of frequencies from this range for developing a wireless communication system. The selection of suitable communication frequencies is based on (a)
health safety, (b) how far they can go without losing their energy to an unacceptable
level, (c) the cost of their management, and (d) their availability for public use. Too
high frequencies such as X-rays, gamma rays, etc., have very high energy and could
serve as excellent communication frequencies. Unfortunately, they present serious
health hazards and can damage the ecosystem. In addition to this, they can be absorbed quickly by objects on their path. Low-frequency waves such as ultrasound,
infrared, etc., have poor immunity to interference and low data rate. They may be
acceptable for short-distance communication such as activating radio, televisions, and
other home appliances, but they require that the communication path should be free
from any obstacle. The optical waves have similar constraints. They can provide
Table 2.1 Electromagnetic spectrum and its applications
Frequency range
ELF (extremely low frequency)
3-30 HZ
Metal detectors
SLF (super-low frequency)
30-300 HZ
Submarine communication
ULF (ultra-low frequency)
300-3000 HZ
Audio, telephone
VLF (very low frequency)
3-30 kHz
Navigation, sonar
LF (low frequency)
30-300 kHz
Aeronautical, maritime,
radionavigation, and radio
MF (medium frequency)
300-3 MHz
AM radio, direction finding,
maritime, short-wave radio
H F (high frequency)
3-30 MHz
Amateur SW radio, citizen
band radio, meter amateur
VHF (very high frequency)
30-300 MHz
Aircraft, amateur radio,
cordless phones, FM radio,
pagers, weather radio, etc.
UHF (ultra-high frequency)
300 MHz-3 GHz
Amateur radio, biomedical
telemetry, pager, citizen
band radio, walkie-talkie,
TV, public, service,
mobile phone (AMPS,
GSM, military, radar,
wireless, headphones,
paging, PCS, etc.
SHF (super-high frequency)
3-30 GHz
Microwave oven, Wi-Fi,
Bluetooth, cordless phone,
public safety, radar, etc.
EHF (extremely high frequency)
30-300 GHz
Automotive radar, LEOS
(low earth orbiting satellites),
LMDS (local multipoint
distribution system)
Table 2.2 ECM bands
I Band
Frequency range
30-250 MHz
250-500 MHz
500 MHz-1 GHz
1-2 GHz
2-3 GHz
3-4 GHz
4-6 GHz
6-8 GHz
8-10 CHI,
10-20 GHz
20-40 GHz
40-60 GHz
60- 100 GHz
relatively high data rates but require a line-ofsight communication path. They cannot be used reliably in the presence of foliage, dust, and fog. Then the question of
suitable antenna to capture and transmit necessary frequencies arises. The wireless
industries, therefore, identified a RF spectrum from 100 MHz (UHF) to about 30
GHz for wireless communication. Out of this range, most wireless communication
today use a frequency range of 800 MHz to 3 GHz, which is allowed by Federal
Communication Commission (FCC).
The selection of 800 MHz for cellular communication is based on a number of
factors. Initially this band had not been used for a long time, but industries, especially
TV stations, did not want to relinquish their hold on this band because of its benefits,
some of which are:
It has a wavelength of about 12 inches (= 12 x 2.54 = 30.48 cm), which is very
It can be easily reflected by the objects such as buildings, moving objects, etc.
Unlike short-wave radio. it does not easily skip or bounce off the ionosphere.
The signal absorption is high, which allows us to achieve efficient frequency
reuse. On the other hand, this absorption creates problems in major coverage
points such as city centers, heavily wooded areas, etc.
Cellular Communication
No matter what frequencies are used they suffer with the above problems to some
degree. There is no radio frequency which can carry data or voice to long distances
without serious attenuation. The entire communication is, therefore, achieved in
multiple “communication slots” to overcome this limitation. A communication slot
is a geographical area within which the RF can be used to set up communication. In
cellular terminology this communication slot is referred to as a cell, and thc entire
communication infrastructure is known as cellular communication. The size of a cell
is defined, keeping in mind the energy level of RF to be used and the power of the
To provide communication over a geographical area of any shape- for example, a
city- it is logically divided into a set of cells [ 1,2,3,4J. This logical division helps to
identify the best position to install the transceiver for achieving the “best coverage,”
which means that a mobile device is able to receive communication from any point
of a cell. A mathematical model is used to identify the “best coverage” pattern. To
understand the meaning of the best coverage, let us use a circle to develop a coverage
pattern. Figure 2.1 a illustrates an example of covering an area using circles. It is
obvious that the entire area cannot be fully covered by using circle of any size. The
space at the junction of three circles will always remain uncovered. Figure 2. I b
illustrates the coverage using hexagons which has no uncovered space anywhere.
A cell in real life is highly amorphous, and its actual radio coverage is referred to
as jbotprint. A real footprint is determined with some field measurement or through
wave propagation prediction models, but in theory a well-defined regular shape is
required to compute the necessary parameter values.
A geographical area coverage by circles
A geographical area coverage by hexagons
Fig. 2.1 Cell coverage through circles and hexagons.
A cell must have a wireless component for managing the communication. One of
the important coverage factors is the location of its “cell site,” which is the point in the
cell where the transceiver is installed. The main objective here is to cover maximum
number of calls efficiently. Figure 2.2a shows the arrangement used in practice. The
cell site is the smaller circle at the junction of three hexagons which represent cells.
The transceiver covers a portion, referred to as “sector” of each cell, and provides
each sector with its own set of channels. This arrangement can also be visualized as
shown in Figure 2.2b. It appears here that a cell site is located at the center of a cell.
These architectural details are not that important for the topic of this book, so it is not
further elaborated here. A useful site to visit for more up-to-date information is Ref.
Cell site at the junction of three cells
Cell site located at the center of a cell
Fig. 2-2 Location of cell site.
In a cellular architecture a number of wireless and wired components are required to establish the desired point-to-point or point-to-multipoint communication.
A Mobile Database System (MDS) is interested in the components that are directly
connected through wireless channel with mobile devices. One such component is
the transceiver, which is usually referred to as a base station (BS). A BS functions
under the supervi5ion of a telecommunication switch called Mobile Switching Center
(MSC) and connected to it through wired line. It is the MSC which connects the
entire mobile system with PSTN (Public Switched Telephone Network). Figure 2.3
illustrates a communication path. These components are discussed in detail later in
this chapter.
Actual communication link:
Users perception of the link:
fig. 2-3 Communication link.
Continuous connectivity during communication is highly desirable for voice communication but essential for data exchange. A momentary disruption in voice communication is acceptable because the communicating parties can decipher the missing
word. This is, however, not acceptable in data communication because it threatens
the accuracy of the data.
A communication session uses a channel to exchange information. Continuous
connectivity is affected by a variety of reasons such as the absence of free channel,
signal fading and interference.
Structure of a Channel
A channel is a communications path between any two devices such as computers,
mobile units, base stations, etc. In mobile discipline two frequencies are required to
establish communication; one from mobile to base station and one from base station
to mobile. For this reason a channel is defined as a pair of radio frequencies, one to
receive and one to transmit. The frequency which is used by mobile unit for transmission to base station is called uplink channel (reverse channel) and the frequency used
by the base station to transmit to the mobile unit is calledforward channel (downlink
channel). Figure 2.4 illustrates the use of a channel for communication.
Mobile transmits at 825.030 MHz and the BS transmits at 870.030 MHz.
Channel seperaion is 45 MHz. Each voice channel has a 30 kHz bandwidth
Fig. 2.4 Downlink and uplink channels.
Table 2.3 lists the frequencies which are commonly used by different systems. The
list does not contain additional channels which have been released by FCC.
Figure 2.5 organizes the available frequencies in AMPS (Advanced Mobile Phone
Service), and Figure 2.6 presents the same distribution in a different way. In these
figures, A represents wireless carrier and B represents wireline carrier. Channels
repeat themselves but frequencies do not because a channel is composed of two
frequencies which are 45 MHz apart to avoid interference between them. For example,
frequencies 832.470 MHz and 877.470 MHz make up channel 249, which appears
at two places in the band. Cellular channels take up a total of 50 MHz, whereas the
AM broadcast band takes up only 1.17 MHz. However, the difference is that cellular
provides thousands of frequencies to carry voice and data while an AM band provides
only 107 broadcast frequencies [7].
Absence of Free Channel
A cell has a fixed number of voice channels available for communication. The Mobile
Switching Center (MSC) allocates on demand a channel through the base station to the
mobile unit when it tries to make a call. During peak hours there may not be any free
voice channel for allocation to a new request which results in dropping the request. In
some situations the MSC may borrow a channel from the neighboring cell for use, but
this is a temporary solution and besides these two cells must be under the management
of the same MSC. The lack of channels is caused by the limited bandwidth of cellular
communication, and a solution could be to increase the available bandwidth, but
Table 2.3 General mobile frequency table
Frequency range
American cellular
D-AMPS (IS-1 36) CDMA)
824 to 849-MHz mobile unit to base station
869 to 894-MHz base station to mobile unit
American PCS narrowband
90 I to 941-MHz
American PCS broadband
1850 to 191 00-MHz mobile unit to base station
1930 to 1990 -MHz base station to mobile
872 to 905-MHz mobile unit to base station
9 I7 to 950-MHz base station to mobile unit
890 to 9 15-MHz mobile unit to base station
930 to 960-MHz base station to mobile unit
8 10 to 826-MHz mobile unit to base station
940 to 956-MHz base station to mobile unit
1429 to I44 1-MHz mobile unit to base station
1477 to 1489-MHx base station to mobile
again the problem is likely to persist because of the continuously increasing ratio of
the number of cell phones to available number of channels.
Signal Fading
The strength of the communication channel reduces as the mobile unit moves away
from the base station. Figure 2.7 shows how the strength (expressed in decibels (dB))
falls as the distance between the base station and the mobile unit increases. Signal
fading affects speech audibility, video reception, and data loss.
Fading occurs mainly due to (a) absorption, (b) free-space loss, and (c) multipath
fading (Kayleighfading). Absorption occurs when radio frequency hits obstacles such
as buildings, trees, rain, hills, etc. Different materials exhibit different absorption
power, for example, organic material exhibit relatively higher absorption effect. A
good example is the absorption by heavy rain, where it is possible that the radio
frequency may completely be absorbed and signal from the broadcasting station may
not reach at all to home television. The signal fading can be minimized to some extent
by utilizing higher gain antennas and smaller size cells.
Channels structure for cellular communication
Channels for Base station
Channels for Mobile unit
824 825
845 846.5 849
869 870
890 891.5 894
20 MHz
(1.5 MHz)
50 Channels
of 30 KHz
(1 MHz)
33 Channels
of 30 KHz
(1.5 MHz)
50 Channels
of30 KHz
(1 MHz)
33 Channels
of 30 KHz
(1.5 MHz)
83 Channels
of 30 KHz
(1.5 MHz)
83 Channels
of 30 KHz
Fig. 2.5 Channel structure.
Channels structure for cellular communication
Mobile transmission frequencies (MHz)
Base station transmission frequencies (MHz)
991 1023 1
991 1023 1
Fig. 2.6 Alternate representation of channel structure.
Free-space loss describes the absorption of signal power over a given distance
between the source and the destination units. This information plays an important
role on defining the size of a cell in cellular communication.
The reflection of a radio signal from the objects of its path of travel gives rise to
multipath or Rayleigh fading. A radio signal may be divided into the main signal
(direct) and a number of reflected signals (indirect). These direct and indirect signals
travel different distances and reach at different times at the receiving antenna where
indirect signals could be out of phase with the direct signal. This situation affects
the reception, and in satellite communication it creates ghost images in television
reception. Figure 2.8 illustrates a typical multipath fading.
The decrease in the strength due to fading is not easy to compute precisely because it
depends on a number of factors including the unpredictable movement of the mobile
unit. When a mobile unit crosses its cell boundary and enters a neighboring cell,
the system (MSC - Mobile Switching Center) transfers the ongoing communication
session to a new channel which belongs to the new base station. The migration of a
mobile unit from one cell to another is managed by a process referred to as hand08
A handoff makes sure that the mobile unit gets the necessary channel in the new
Fig. 2.7 Strength of signal received by a mobile unit from the base station.
Fig. 2.8 A typical mulipath absorption scenario.
cell to continue its communication and relieves the channel it was using without any
interruption. Figure 2.9 illustrates a typical handoff situation. The car from the cell
of base station 1 enters the cell of base station 2 while actively communicating with
somebody, or in a doze mode or in a power off mode.
Fig. 2.9 A typical handoff scenario.
One of the important points in a handoff is that it must be initiated and completed
before the ongoing call is lost due to reduction in signal strength. To achieve this, an
optimal signal level is defined; and when this level is detected, the system initiates
the handoff. This optimal level is higher than the minimum usable signal level, which
is usually between -90 and -100 dBm. Thus, the difference between the handoff
threshold signal level and the minimum level should not be either too large or too
small. If it is too small, then calls will be dropped before handoff is complete; and if it
is too large, then there will be too many handoffs. Figure 2.10 illustrates the initiation
of handoff. Point H1 identifies the handoff threshold for base station BS 1 and H2
for base station BS2, where handoffs are initiated for BSI and BS2, respectively.
The region covered by H1 and H2 is a handoff region, and to maintain continuous
connectivity the handoff process must be completed in this region. In particular,
handoff initiated at points H1 and H2 should be completed at the point H.
Base Station 1
Fig. 2.70 A typical handoff initiation.
The system has to cope with a situation called "false handoff," which occurs when
the signal strength reaches the handoff threshold due to momentary fading caused by
reflection or absorption by intermediate objects. To detect that the fading is actually
due to mobile unit moving away from the base station, the system measures the
signal strength for a certain period of time and obtains a running average that is used
to initiate the necessary handoff.
There are two types of handoff: hard handqff and sofr handoff. In hard handoff
the mobile unit does experience momentary silence in voice communication when it
relives the old channel and acquires the new channel in the new cell. In soft handoff, no
such silence is experienced. The entire process of handoff, hard and soft, is discussed
in detail in Chapter 3. There are excellent books and reports available on these topics
[2, 7, 81 for further information.
Frequency Reuse
The continuous connectivity may also be affected by interlference, which can be
defined as interaction between two signals. The interference not only affects the
communication but also is a major limiting factor in the performance of the entire
system. Two communication sessions may interfere with each other if the frequencies
they use are quite close to each other or even identical. It can also occur if the base
stations of two communicating mobile units are located closely or if there is another
active mobile unit in the vicinity or if there is an active call in a nearby cell. The
presence of an interference could give rise to cross talk, where one party can hear
the communication of the other party in the background. It may also occur between
two control channels, which may lead to blocked or missed calls. Theoretically, it is
possible to have a total silence if these frequencies are completely out of phase.
To avoid co-channel interference, two frequencies are kept apart at least by 45 Hz,
but in the case of higher frequencies the separation may be less. Each cell is usually
assigned 25 to 30 channels for communication, which depends on the expected traffic
volume in the cell. This will support only 25 to 30 communication sessions. The
number of channels for a cell is determined by a number of factors such as: the density
of callers, which indicates the number of callers per square meter; the average activity
factor, which relates to the average use of phone in an hour; the probability of blocked
calls; and so on.
In cellular communication the system has to deal with co-channel interjkrence
and adjacent channel interference. Co-channel interference occurs when the same
frequency is used for communication in two nearby cells. Co-channel interference
could be tolerable in a voice communication because humans can guess reasonably
accurately the words in the presence of noise. This is not acceptable in data communication because it can corrupt the data to an extent which cannot be recovered by the
receiver. Co-channel interference is solved by keeping the cells, which plan to use
the same set of frequencies, apart by a distance called frequency reuse distance. A
frequency reuse distance is the minimum safe distance between two cells which can
reuse the same frequencies without interference. This distance is expressed in terms
of intervening cells between the two cells where same frequencies are reused.
Frequency reuse is implemented through cell clustering. A cell cluster is made up
of a number of same size cells and the cluster size depends on the entire coverage
area, the frequency plan, acceptable co-channel interference, and mobile commerce
(M-commerce) strategies. In M-commerce it is important for a mobile user to know in
which cluster he or she is currently residing. A cluster may be made up of 3,4,7,9, 12,
13, 16, etc., cells; but out of these, 7-cell and 4-cell clusters are most commonly used
to cover an area. Figures 2.1 1a through 2.1 1d illustrate the composition of clusters
of sizes. In reality, an area is covered by a number of clusters, each one composed
of different size cells as illustrated by Figure 2.1 1 e. This cluster organization was
in fact used by the Vodafone company to provide communication service around the
area covered by M25 ringroad [ 11 in England. The inner area was populated by
smaller-size cells to manage high communication traffic from highly populated user
To reuse the same set of frequencies in another cell, it must be separated by
frequency reuse distance, which is usually denoted by D. Figure 2.12 illustrates the
separation of cells by frequency reuse distance in a cluster of seven cells. In order to
Fig. 2.7 7 Clusters of different sizes.
derive a formula to compute D , necessary properties of regular hexagon cell geometry
are first discussed.
A regular hexagon can be split into 6 equilateral triangles as shown in Figure
2.13. It has reflective symmetry about each of its three diagnols d l , d2, and d3 and
about lines joining the midpoints of opposie sides. It also has rotational symmetry
about its center. A regular hexagon has inradius ( T ) and circumradius ( B )as shown
in Figure 2.13. The height H (apotham) of an equilateral triangle can be computed
using Pythagoras theorem as follows:
Figure 2.14 illustrates the process of computing D. The initial cell is identified as
"Start" and its corresponding reuse cell is identified as "End." To reach "End," multiple
Fig. 2.12 Frequency reuse distance.
Circumradius = R, lnradius = r, and the Height of a triangle (apothem) = H
Fig. 2.13 Properties of a regular hexagon.
cell clusters are traversed always in direction of H. So from the "Start" cell, travel
on i coordinate to some number of cells and then turn clockwise or counterclockwise
and travel some number of cells on j coordinate. How to get the correct value of i and
j will be discussed later.
D is identified through the use of i and j coordinates. Thus the computation of D ,
X and Y coordinates must be represented in terms of i and j . Figure 2.15 shows how
this representation is achieved and gives the following values x and y for
Fig, 2.74 Identification of frequency reuse cell.
Fig. 2.75 Computation of frequency reuse distance D .
+ (T
+ &jq2
n J 3 { (i
R2 + 3 R 2 ( - + i j + j 2 )
Distance D is closely related to the cell radius R and the cluster size N (number
of cells in a cluster). Consider a cluster with C number of duplex channels for use
which are equally divided among N cells . Each cell of this cluster then will have
C = eN
where e is the number of channels allocated to the cell.
Fig. 2.16 Cluster replication.
The idea is to replicate this cluster a number of times to enhance the capacity of the
system, which refers to the number of users it can satisfactorily support. The degree
of replication, which refers to the number of times a cluster is replicated, depends
significantly on the cluster size. If the cluster size N is reduced without reducing the
cell size, then more number of clusters will be required to cover the area. On the other
hand, if it is increased, then less number of cluster will be needed to coverage. A high
degree of replication is able to support a larger number of users, but the probability of
interference increases. Voice communication may be able to tolerate such interference
but will not be acceptable for data communication. Figure 2.16 illustrates how degree
of replication affects the coverage when cluster size is changed. In Figure 2.16a the
area is covered by one replication of a 7-cell cluster, and in Figure 2.16b it is covered
by two replications of a 4-cell cluster. In Figure 2 . 1 6 ~the cluster size is reduced to
three; consequently, three replication5 of a 3-cell cluster are required. This provides
a total of C x 3 number of effective channels for communication, assuming that each
cell is separated by frequency reuse distance. This illustrates how the value of N
depends on the degree of interference the base station can tolerate without affecting
the quality of communication. In reality, from a system design viewpoint a smallest
value of N which can support largest number of users is used. This also means that
only specific values of N can be used effectively, and these values of can be computed
+ i j +12
= (i
+ j )2
where i and j are non-negative integers and refer to as shijtpurumeters. They identify
the direction of movement to find the cells which are located at frequency reuse
distance in the replication. Equation (2.5) indicates that the cluster can be constructed
only with N = I , 3,4, 7, 9, 12, 13, 16, 19, ..., the most common value being 4 and 7.
It is easy now to identify the cells for frequency reuse using Formula (2.5). The
steps of the identification process can be illustrated using Figure 2.17, which is constructed with a cluster size of N = 7 using i = 2 and j = I . (a) Identify a starting cell;
(b) from this cell move i = 2 cells in a straight line to reach the center of the third cell;
(c) turn counterclockwise 60" in this cell,; and (d) movej = I cell in a straight line to
reach to the frequency reuse cell.
Fig. 2.17 Reuse cell identification.
Adjacent channel inte$erence occurs in the region where energies of two adjacent
channels overlap. The region between the points H1 and H2 (Figure 2.10) indicates
a channel overlap area. The interference may become quite serious if multiple transmitters of different powers transmit close to each other. It becomes quite difficult in
this scenario for the bases stations to identify the right mobile user.
These interferences can be minimized by careful channel allocation to neighboring
cells. The power of the BS of a cell is carefully controlled to make sure that the energy
of its channels is confined to the cell and does not spill over to the adjacent cells. The
main purpose of this control is to be able to reuse the same frequencies in nearby cells.
A wireless channel, therefore, has a limited communication range, and mobile units
(cell phones, laptops, etc.) are free to move from one cell to another during a wireless
session. When a mobile unit leaves its initial cell and enters a neighboring cell, it
must also relinquish the frequency it was using and acquire a new frequency in the cell
it enters. It is not possible to increase the number of channels to support increasing
number of mobile users because of bandwidth limitations. The idea of frequency
reuse is used to support more number of users. The frequency reuse allows the same
frequency to be used in multiple cells, provided that the problems of co-channel and
adjacent channel are taken care of.
The cellular system was based on analogue transmission. It experiences a rapid
growth in Europe and in North America. However, because of its inherent limitations,
it could not cope with rapidly growing number of subscribers. This gave rise to the
evolution of two mobile communication systems commonly known as PCS- Personal
Communication System and GSM - Global Systemfor Mobile Communication. PCS
evolved in North America and GSM in Europe. Both systems are based on digital
transmission; however, PCS continued to support analogue transmission mainly to
service existing subscribers. GSM system on the other hand is purely digital. As
these systems evolved, they offered advanced services and operational differences
between them became somewhat blurred. In fact, NPAG (North American PCS 1900
Action Group) developed the American version of GSM, which is called PCS 1900.
Since their deployment, GSM was adopted by most of the countries of the world
capturing 75% of the world communication market and PCS remained confined
mostly to North America.
PCS - Personal Communication Service
Interim Standard-41 (IS-41) is a standard protocol for managing the voice communication in mobile telecommunication network. It is produced by the Telecommunication Industry Association (TIA) as Revision 0 and since then has gone through three
revisions: Revision A (IS-41A), Revision B (IS-41-B), and Revision C (IS-41-C).
IS-41-C describes components, protocols, and management of cellular technology,
which has been introduced earlier in this chapter.
The IS-41 -C cellular system was originally introduced for use in moving vehicles,
mainly cars, using analog communication. It had a number of limitations related
to coverage size, clear reception, interference, and the degree of mobility. Very
soon subscribers of IS-41 -C cellular system found these to be severe impediments in
their working environment. Subscriber demands for improved services and facilities
motivated investigation into Personal Communications Services (PCS), leading to its
deployment in 1996.
PCS is a more sophisticated and powerful wireless phone service which emphasized personal service and extended mobility. Unlike cellular system, it used digital
communication and smaller size cells to enhance the quality of services and to support larger number of subscribers. However, PCS did not reject the analog system
completely and continued to support it. Thus an older analog system can still work.
FCC vaguely defines PCS as a mobile and wireless service that can be integrated with
a variety of different networks to provide a wide variety of mobile and wireless services to individuals and business organizations. The commission allocated spectrum
to PCS in three major categories: (a) broadband, (b) narrowband, and (c) unlicensed.
Broadband category is designed to offer two-way voice, data, and video communications. It has been referred to as “the next generation of mobile telephone service.”
Broadband PCS is allocated spectrum ranging from 1 850 to 1910 MHz and 1930
to 1990 MHz. This 120 MHz of spectrum was divided into six frequency blocks A
through F where blocks A, B, and C are 30 MHz each, and blocks D, E, and F are 10
MHz each. Different wireless services are provided under each of these bands.
Some C block were further divided into twv sets: (a) C-1 (15 MHz) and C-2 (15
MHz) or (b) C-3 (10 MHz), C-4(10 MHz), and C-5 (10 MHz). These frequency
blocks are used mainly for licensing. Table 2.4 lists the allocated frequencies in
broadband category [ 3 ] .
Narrowband category is designed to offer advanced voice paging and messaging,
acknowledgment paging, data and electronic messaging, two-way paging and other
text-based services, and fax service. Narrowband PCS uses a smaller portion of the
spectrum than broadband and operates in the 901 to 902-MHz, 930 to 93 1-MHz, and
940 to 941 -MHz bands. There are 32 channels, and channel size is 12.5 kHz. to I50
UnI icensed
Frequency spectrum 1910-MHz to 1930-MHz band has been allocated to unlicensed
PCS. It is designed to provide data networking within office buildings, wireless private
branch exchanges, personal digital assistants, laptop computers, portable facsimile
machines, and other kinds of short-range communications. An unlicensed system is
particularly suitable for office-wide and campus-wide services. One of the advantages
of this is that equipment manufacturers do not have to wait for the development of
standards since they can design proprietary products for their clients.
Architecture of PCS
Figure 2.18 shows a generic architecture of PCS. It has two sets of components:
(a) functional components, which are represented as rectangles, and (b) interfaces,
which are represented as small circles between two functional components. The set
of components in bold represent the standard as defined in IS-41-C. Since this is a
reference architecture, it can be implemented and deployed in many different ways.
In one implementation, multiple components may be integrated into a single physical
unit without affecting their modularity.
A reference architecture of PCS is given in Figure 2.19, which shows the cellular
components. This reference architecture is the basic platform for the development of
Mobile Database System (MDS) introduced later in the book.
Table 2.4 Broadband spectrum
Frequency block
Frequency range
1850.0 - 1865.0
The functional components of PCS are discussed below. The GSM system, which
is discussed later. uses nearly the same set of components but with some difference
in spectrum allocation.
Functional Components
Mobile Unit (MU): This is also called as Mobile Host ( M H )or Mobile Station (MS).
It is a wireless device which is composed of (a) antenna, (b) transceiver, and (c) user
interface. The antenna captures the signal, and the transceiver is responsible for
receiving and sending signals. The user interface is responsible for interacting with
Fig- 2.18 Generic PCS architecture.
the user by displaying graphics and text and receiving texts from the user. The audio
interface component handles voice conversation.
A mobile unit is classified into Class I, which operates at 6 dBW (decibels); Class
TI, which operates at 2 dBW; and Class 111, which operates at -2dBW. The unit has
its own permanent memory where it stores (a) Mobile Identification Number (MIN),
(b) Electronic Serial Number (ESN), and (c) Station Class Mark (SCM). MIN is a
10-digit subscriber’s telephone number. When a call arrives to a mobile unit a paging
message is sent by MSC with the subscriber’s MIN to all base station. When the
mobile unit receives the page on a forward control channel, it sends a response with
its own MIN using the reverse control channel. When MSC receives mobile units
response with its MIN, it then directs the BS to assign a voice channel for setting up
the communication. The ESN is a unique 32-bit number which is used by the cellular
system to identify the unit. This number is hardwired, and any attempt to temper
with it makes the unit inoperable. SCM identifies the power-handling capability of a
mobile unit, and it is a 4-bit number.
Base Station (BS): The BS consists of a pair of transmitter and receiver. Each cell
is managed by one BS only, and the size of the cell is determined by its power. In
PCS architecture the activities of a BS such as setting up a communication, allocating
a channel for communication, etc., are directly managed by the MSC. When a mobile
subscriber dials a number, the BS of that cell reaches its MSC for a voice channel for
establishing the call. At the end of the call, it returns the channel to the MSC. Some
Fig. 2.79 A reference architecture of PCS.
BS are for indoor and some are for outdoor use. In GSM architecture a BS is referred
to as BTS (Base Transceiver Station).
Base Station Controller-BSC: This is a GSM component which manages the activities of a number of BS or BTS. Its main functions are RF frequency administration,
BTS, and handover management. At one end a BSC is connected to many BTSs and
to a MSC on the other end.
Mobile Switching Center (MSC): It is a switch and is referred to by many names
such as MTSO (MobileTelephone Switching Office), mobile switch (MS), or Mobile
Switching Center (MSC). They all process mobile telephone calls. Large systems
may have two or more MSCs and are connected with one or many base stations
through wired line.
Home Location Register (HLR): It is a large database which stores necessary
information such as geographical location of a subscriber, call processing, billing,
service subscription, service restrictions, etc. Its contents and structure are vendor
specific but the schema developed by Lucent Technologies is used by almost all network companies. Lucent refers to their HLR as stand-alone HLR because it is maintained at a central location and shared among all network elements. In a centralized
scheme, HLR is usually stored at one MSC, and in proposed distributed approaches
it is distributed to multiple MSCs. Figure 2.20 illustrates a very small portion ofthe
HLR as define by Lucent Technologies.
Mobile Identification Number
Directory number
International Mobile SubscriberlD
Electronic Serial Number
Home service area
Traveler Service Area
Primary Dialing Class
Secondary Dialing Class
Primary Rate Center
Routing Class
Mobile Type
Billing Type
Primary Last Seen Location
Secondary Last Seen Location
91 35555555
91 35555500
Fig. 2.20 Home Location Register (HLR) database.
Visitor Location Register (VLR): AVLR is acurrent subset of HLR for a particular
cell. Whenever a subscriber enters a new cell, its current location is stored in VLR
representing that cell. The entry is removed when the subscriber leaves that cell.
The information about a subscriber is replicated in HLR and VLR to achieve faster
location search which begins from VLR and ends in HLR if the entry is not found in
the VLR. The VLR data are not used for any administrative purpose; it merely serves
as a location identifier.
HLR and VLR are huge databases maintained by high-power servers, often a Unix
workstation. Tandem, which is part of Compaq (a part of HP), made the server and
called it HLR when used for cellular system. A large number of mobile units use
the same HLR, and there are usually more than one HLR for nationwide cellular
system. For example, Motorola uses more than 60 HLRs nationwide. The processing
of HLR is not complex, so it does not need sophisticated database functionality. The
recent trends is to distribute HLRs and use distributed processing approaches for its
Authenticating Center (AC orAUC): The AC is a processor system, which authenticates subscribers. AC needs to access user information for authentication process
so it is co-located with HLR. Thus AC and HLR together are stored in MSC or somewhere nearby it. An AC may serve more than one HLR. A complete authentication
process is performed only when the first call is made. In all subsequent calls from the
same subscriber, if made within a system defined time period, the stored information
is used for authentication. The authentication steps are as follows:
a. AC sends a random number to the mobile unit from where the call originates.
b. Authentication algorithm stored in SIM (Subscriber Identity Module) manipulates this random number using a Subscriber Authentication Key, which is also
stored in SIM.
c. The result of this manipulation is sent to AC along with an encryption key
(secured communication).
d. Concurrent with the authentication computation at the mobile unit, AC performs
identical computation using the random number and information stored in HLR.
e. AC compares the result of its own computation and the result received from the
mobile unit. In the case of a successful comparison, it permits the subscriber
to access the network and stores and sends the encryption key to BS to enable
ciphering to take place.
Equipment Identify Register (EIR): It is a database which stores information for
the identification of mobile units. For example, it maintains a database of Electronic
Serial Number which is unique to a mobile unit which prevents its theft and malicious
use. It helps the network to deny any service to stolen mobile unit. To handle use
of questionable equipment (stolen or fraudulent), GSM maintains three types of list
identified as white, black, and gray. A white list stores all clean equipments’ identities
which are allowed to use the network, a gray list contains clean but semi-functional
units (malfunctioning) that have difficulty in making a call, and the black list contains
the identities of stolen or fraudulent units. Any call originating from a black list unit
is blocked by the network.
Public Switched Telephone Network (PSTN): This component refers to the regular wired line telecommunication network which is commonly accessed by landline
Integrated Service Digital Network (ISDN): It is a wired line network which
provides enhanced digital services to subscribers.
Short Message Entity (SME): This unit is added in the IS-41-C to manage short
text messages (200 bytes or less). This is a part of the System Message Service
(SMS), which looks after text messages.
Message Center (MC): This unit stores and forwards short messages to mobile
destination. If the destination is unavailable for any reason, it stores the message for
later dispatch.
A number of interfaces are required to establish link among functional units. This
is especially true when components from different vendors with varied formats and
structure are integrated together. These links could be one to one, one to many, many to
many, and one to zero. As shown in Figure 2.18, the M, N, and Q interfaces were added
to IS-41 -C and they provide necessary signaling and bearer service communication to
handle short messages. The A interface standards enable us to integrate the MSC and
radio systems from different manufacturers and make sure that they function correctly.
The A, (Analog) and D, (Digital) interfaces link the mobile side (cellular network)
and wireline sides (PSTN and ISDN). The H interface links HLR and AC functionality
and supports the authentication functions and the D interface links HLR and VLR.
This enables to integrate and to support their multiple formats. The interfaces G links
VLRs, B MSC and VLR, F MSC and EIR, and C MSC and HLR.
Call Processing
When a mobile unit is switched on, it goes through a set of validation steps before a
call can be made and then a channel is assigned to a mobile unit to initiate the call.
The following list presents only a few essential steps, and the detail can be found in
Refs. [2,4, 81:
a. Determine the type of home system from the stored parameter. The system
types are referred to as A (A-license) and B (B-license), which are based on
the number of assigned channels. Channels 1-333 (825.030 to 834.990-MHz)
belong to A, and channels 334-666 (835.020 to 844.980-MHz) belong to B.
Some new frequencies (667 to 799 and 991 to 1023)have been added to these
types. If type A is identified, then the mobile unit begins scanning type A
channels and tunes to the strongest signal. The mobile unit stores System
Identification (SID), which is a 15-bit number assigned to a cellular system by
the FCC, and stores paging channels and their range. It tunes to the strongest
paging channel and receives an overhead message train. The mobile based on
SID being transmitted on the paging channel determines its status (roaming or
not) and sets the roam indicator accordingly.
b. The mobile enters the idle mode, where it periodically receives an overhead train
message and captures system access information, system control information,
and system configuration information. This information is used by the mobile
unit for subsequent network access and for diagnostic purposes. The unit also
monitors station control messages for page messages; if a page is received, it
matches the received and locally stored MIN (Mobile Identification Number).
A successful match indicates that the page is for the unit and enters the system
access task with page response indicator. It also enters the system access mode
for user-initiated call origination, registration, and other relevant information.
c. The mobile starts a timer for each operation. For example, it sets 12 seconds
for call origination, 6 seconds for page response, and so on.
Mobile-to-Land Call: Figure 2.2 1 illustrates the message flow in call establishing.
The following steps are performed to establish communication between a mobile and
a land user.
Base Station
Request access
(including dialed digits) .
Request access
Assign voice channel
Ring phone
Mobile Unit
Assign voice channel
Send SAT
Dial digits and
press SEND
Tune to voice
_ _Return
__ _ _< ~ _SAT
< Status tone
Answer phone
and talk
i - 3 c
Dial tone t-
Release channel
Channel available
+ +-
Status tone
Release channel
Send ST 1 8 Sec
S e n d S T l BSec
Ring/Busy tone
> +-Talk
> 1conversation
fig. 2.21 Mobile-to-land call setup. (Reproduced with permission from Wireless PCS,
a. The mobile user is in idle mode.
b. It dials the number which is stored in the memory. When the caller presses the
SEND key, then only the numbers are transmitted.
c. The mobile unit goes into the system access mode as the call originator.
d. The mobile unit tunes to the strongest control channel and attempts to send an
origination message through this channel.
e. The base station receives the message, validates it, and sends a subset of fields
for further validation to MTSO (Mobile Telephone Switching Office). MTSO
validates user subscription type, service profile, etc., to make sure that the user
is allowed to make this call.
f. After a successful validation, the MTSO sends a message to the BS to assign
a voice channel to the user. In this assignment the base station sends channel
number to the mobile unit via an IVCD (Initial Voice Channel Designation)
g. The base station transmits the SAT (Supervisory Audio Tone) to the mobile
unit. The unit tunes to the voice channel and returns the SAT on the reverse
voice channel back to the base station.
h. The base station receives the SAT from the unit and sends it to the MTSO,
which then dials the called number via PSTN.
i. The mobile user receives the ringing tone and begins conversation.
j. At the end of the session, it sends an ST (Signaling Tone) for 1.8 seconds and
terminates the session.
k. The base station detects the ST and sends a disconnect message to MTSO. The
MTSO releases the connection with PSTN and the land user.
1. If the land user terminates the call, then PSTN initiates the release process.
The MTSO sends the base station a release message, and the base station sends
a release message to the mobile unit. The mobile unit transmits ST for 1.8
seconds, and at the end of this time the base station sends a channel available
message to the MTSO.
Dial digits
Dial phone
Route to MTSO
Validate MIN/ESN ;
Page request at
all cell sites
Paging signal
Request access
Page request
Assign voice channel
Assign voice channel
Send SAT
Ring phonf
Send ringback
Confirm alert
Return SAT
Send alert
Send ST
Remove ST
Hang UI
. ...Channe!ava.i!?!?!e
Dial ton
] Access system
Tune to voice
Transpond SAT
Ring phone
Answer phone
SendSTl 8Sec
] conversation
Send ST 1 8 Sec
- Disconnect
Fig. 2.22 Land-to-mobile call setup. (Reproduced with permission from Wireless PCS,
Land-to-Mobile Call: Figure 2.22 illustrates the message flow in call establishing.
The following steps are performed to establish communication between a land and a
mobile user.
a. The land user keys in the mobile telephone number.
b. MSC (Mobile Switching Center) receives this number. First it has to make
sure that the mobile unit is available to take this call, and also it must know
the location. The MSC may have some information about the location of the
unit from its recent registration in which case it sends a page request to the BS
of the registration area. The BS, after receiving this page request, pages the
MU through the paging channel. If the location of MU is not known, then the
location manager is invoked.
c. The MU acknowledges the receipt of this page.
d. The BS informs the MSC that it has received the acknowledgement from the
e. The MSC validates user subscription type, service profile, etc., to make sure
that the MU is allowed to take this call.
f. After a successful validation, the MSC sends a message to the BS to assign a
voice channel to the mobile unit. In this assignment the base station sends a
channel number to the mobile unit via an IVCD (Initial Voice Channel Designation) message and asks MU to tune to the channel.
g. The base station transmits the SAT (Supervisor Audio Tone) to the MU. The
unit tunes to the voice channel and returns the SAT on the reverse voice channel
back to the base station.
h. The base station receives the SAT from the unit and sends it to the MSC and
sends an alert order to MU.
i. In response to this alert order, the MU begins ringing to inform the user about
the incoming call.
j. The MU generates a signaling tone on the reverse channel which BS detects
and informs MSC that MU has been alerted.
k. The MSC generates a ring-back tones for the land user.
1. The MU connects to the voice channel and answers the phone.
m. The MSC stops ringing the land user and the conversation begins.
GSM - Global System for Mobile Communication
In many European countries by the early 1990’s the cellular communication system
was widely used. However, each country had their own system; for example, the
TACS system, which was based on the AMPS system, was deployed in United Kingdom in 1985. As of 1993, Austria had NETZ,; Belgium, Cyprus, Estonia, Hungry,
Luxembourg, etc., had NMT (Nordic Mobile Telephone); Denmark, Finland, etc’,
had GSM and NMT; and so on. System compatibility across multiple platforms was
a major problem. Table 2.5 gives a summary of most of the European countries’ mobile systems which were in use as early as 1992. Handheld mobile gadgets began to
appear around 1988, and only in 1990 did pocket-size devices appear. At that time a
mobile gadget weighed about 400 g. These systems were based on analog technology
and they covered the entire country.
Table 2.5 European mobile systems
Deployed in
RF Band
Norway, Sweden,
Denmark, Finland
900 MHz
450 MHz
900 MHz
I Radiocom 2000 I 450,900MHz 1
450 MHz
450 MHz
900 MHz
450 MHz
900 MHz
The Netherlands
450 MHz
450 MHz
900 MHz
450 MHz
900 MHz
To address the problem of compatibility and establish some standard in 1982 the
Conference of European Posts and Telegraph (CEPT) created a study group called
Groupe Spe'cial Mobile (GSM}.This was the beginning of a digital wireless system
which later became known as GSM. Thus, right from the beginning, unlike in the
United States, digital technology was used to develop a uniform European wireless
communication infrastructure. With time, GSM became the most commonly deployed system across the world; at present, GSM accounts for 75% of the world's
digital and 64% of world's wireless market.
A reference architecture of GSM is shown in Figure 2.23. The architecture is
basically similar to PCS. The main differences are that in GSM a base station is
connected to MSC through BSC (Base Station Controller). Thus, the task of channel
allocation, channel borrowing, etc., are divided between BSC and MSC.
The BSC performs channel management for one or more base stations. In particular
it handles radio-channel, frequency hopping, and other activities like handoff. The
introduction of BSC between base stations and MSC is to ease the traffic through
MSC for improving its performance. The MSC communicates to BSCs, which, in
turn, routes calls to about 50 to 100 base stations.
The mobile unit of GSM has two components: (a) system hardware and software
and (b) subscriber. The system hardware and software components are specific to the
radio interface and deal with frequency allocation tasks. The subscriber component
holds customer profile information which is called SIM (Subscriber Identity Module).
Fig. 2.23 A reference architecture of GSM.
SIM is a small device (smaller than a credit card in dimension) and is highly potable,
which offers personal and terminal mobility. A customer can remove the SIM card
from his mobile device and carry it with while mobile. He can plug this card into
another device and continue to use it as if it were his own mobile device. In addition
to storing the customer profile, it can also support a PIN (Personal Identification
Number, a 4- to 8-digit number), which is used to validate the owner of the SIM card.
When the SIM card is removed from a mobile unit, then the unit can only make calls
to emergency service providers such as police, hospitals, etc.
GSM uses a combination of FDMA (Frequency Division Multiple Access) and
TDMA (Time Division Multiple Access). The updated version of GSM is known as
DCS 1800, which is also referred to as PCN. It works in microcell environment and
uses 1710 to 1785 MHz for uplink channels and 1805 to 1880 MHz for downlink
channels. In the United States, the PCS 1900 system is deployed; this system is
structurally similar to DCS 1800 system but uses 1850 to 1910 MHz for uplink and
1930 to 1990 for downlink channels with frequency separation of 80 MHz.
The FDMA part of GSM uses two 25-MHz frequency bands in the 900-MHz range.
The mobile unit uses 890-915 MHz, and the base station uses 935960 MHz. Here
also the uplink and downlink frequencies are separated by 45-MHz frequency. Thus,
the transmit frequency of the base station can be calculated just by adding 45 MHz
to mobile transmit frequency.
The enhanced version of GSM is known as DCS 1900 (also as PCN - Personal
Communication Network), which is mainly used in a microcell environment. This
version uses two 75-MHz frequency bands and are separated by 95 MHz. The uplink
channel range is 1710-1785 MHz, and the downlink range is 1805-1880 MHz. This
provides 374 channels, each with 200 KHz. As mentioned earlier, PCS 1900, which is
deployed in the United States is architecturally similar to DCS 1800 but uses different
frequency bands for communication. In PCS 1900 the uplink frequency ranges from
1850 to 1910 MHz and the downlink frequency ranges from 1930 to 1990 MHz with
a frequency separation of 80 MHz.
The TDMA part of a GSM frequency spectrum is not broken down into individual
radio channels; rather, a channel is shared among multiple users residing in the same
cell. To share a radio channel among multiple users, it is divided into eight different
time slots. These time slots are referred to as a TDMAfrume. Each time slot supports a
user communication; consequently, each radio channel now can support eight different
users. Each user is assigned a time slot for transmission, which is usually referred to
as a burst. Each burst lasts for 577 p, which makes it 4.615 ms (8 x 577 ps) in a
frame. As soon as the time slot is over, a second user begins transmitting in that time
slot. In this way a round-robin scheduling is enforced and the first user gets the time
slot again after the seventh user finishes.
The call processing, channel asignment, etc., are similar to PCS described earlier.
Further technical and working details can be found in Ref. 141.
This chapter covered radio frequency management, architecture and cellular systems,
movement, and management of mobile units. The cellular architecture was the basis
for a number of mobile communication systems which were deployed in many countries of the world. These different systems had a severe compatibility problem which
was recognized by telecommunication companies and by subscribers. However, this
compatibility issue did not arise in North America, but the limited capability and
range of existing system was a major concern. This issue was handled by migrating
from analog to digital transmission. This marked the evolution of PCS (Personal
Communication System). In Europe, on the other hand, a committee called GSM
(Groupe SCrvice Mobile) was formed to tackle the system compatibility problem.
The committee initiated the development of GSM (Global System for Mobile Communication). This chapter discussed in detail the development and architecture of the
PCS and GSM systems.
The next chapters focus on location management and handoff topics which are
essential component of continuous connectivity discipline.
1. What is channel interference and how does it arise'? How can you deal with
the adjacent channel interference and cochannel interference? Explain your
2. In real life the actual radio coverage area is calledfootprinr, which is highly
amorphous. In theory, however, a well-defined regular shape is used to iden-
tify the necessary parameter for mobility. Explain why such regular shape is
necessary and how does it help to define coverage areas.
3. Define the following terms (a) spectrum, (b) band, (c) frequency, (d) downlink
and uplink channels, and (e) frequency reuse. Establish a working relationship
among them.
4. A cell size defines the reach of a wireless channel. The strength of a channel
depends on the power of its base station. First explain clearly the relationship
among a base station, its cell size and its channel strength and develop a rule-ofthumb which can quantify the value a parameter (channel strength, base station
power, or cell size) if the values of the other two parameters are given. (Hint:
Assume the power of a base station and proceed to define the cell size.)
5 . Experiment with difference size cell clusters and discover why some cluster
sizes are used more commonly than other sizes. In your investigation explain
the advantages and disadvantages of different cell sizes.Derive the relationship
D = R m ,where D is frequency reuse distance, R is the cell radius, and N
is cell cluster size (number of cells in a cluster).
6. Create different size clusters with different R and find the frequency reuse
distance for each sample.
+ +
7. Prove hat N = i2 ij j 2 ,where N is the cell cluster size, i is the number of
cells to be traversed in i coordinate, j is the number of cells to be traversed in
.j coordinate from the originating cell. j coordinate is 60' from i coordinate.
8. Explain the difference between the structure and functionality of PCS and GSM.
1. D. M. Balston and R. C. V. Macario (Eds.), "Cellular Radio Systems," Artech
House, Norwood, MA, 1993.
2. D. Agrawal and Q.-A. Zhang, "Introduction to Wireless and Mobile Systems,"
Cole and Brooks Publishers, Pacific Grove, CA, 2003.
4. Rajan Kuruppillai, Mahi Dontamsetti and Fil J. Cosentino, "Wireless PCS,"
McGraw-Hill, New York, 1997.
5. Ra.j Panda, "Mobile and Personal Communication Systems and Services," Prentice Hall India, 2000.
6. John Walker (Ed.), "Advances in Mobile Information Systems," Artech House,
Norwood, MA, 1999.
8. Wireless Intelligent Network (WIN), Lucent Technologies.
Location and Handof
The handoff process in mobile communication system was briefly introduced in Chapter 2. In this chapter, further details of the handoff process is provided and the topic
of location management is introduced. It first explains how these processes work
and then discusses their relevance to transaction management in mobile database
systems. Quite a few location management schemes have been proposed recently,
but none of them have been implemented in any commercial system, so they are not
discussed. The working of existing handoff and location mechanisms given in IS-41
is explained 171.
Location Management
In cellular systems a mobile unit is free to move around within the entire area of coverage. Its movement is random and therefore its geographical location is unpredictable.
This situation makes it necessary to locate the mobile unit and record its location to
HLR and VLR when a call has to be delivered to it. Thus, the entire process of the
mobility management component of the cellular system is responsible for two tasks:
(a) location management- that is, identification of the current geographical location
or current point of attachment of a mobile unit which is required by the MSC (Mobile
Switching Center) to route the call- and (b) handoff- that is, transferring (handing off)
the current (active) communication session to the next base station, which seamlessly
resumes the session using its own set of channels. The entire process of location
management is a kind of directory management problem where locations are current
locations are maintained continuously.
One of the main objectives of efficient location management schemes is to minimize the communication overhead due to database updates (mainly HLR) [6,9, 151.
The other related issue is the distribution of HLR to shorten the access path, which
is similar to data distribution problem in distributed database systems. Motivated
by these issues, recently a number of innovative location management schemes have
appeared in the research world [ 141.
The current point of attachment or location of a subscriber (mobile unit) is expressed in terms of the cell or the base station to which it is presently connected. The
mobile units (called and calling subscribers) can continue to talk and move around in
their respective cells; but as soon as both or any one of the units moves to a different
cell, the location management procedure is invoked to identify the new location.
The unrestricted mobility of mobile units presents a complex dynamic environment, and the location management component must be able to identify the correct
location of a unit without any noticeable delay. The location management performs
three fundamental tasks: (a) location update, (b) location lookup, and (c) paging.
In location update, which is initiated by the mobile unit, the current location of the
unit is recorded in HLR and VLR databases. Location lookup is basically a database
search to obtain the current location of the mobile unit and through paging the system
informs the caller the location of the called unit in terms of its current base station.
These two tasks are initiated by the MSC.
The cost of update and paging increases as cell size decreases, which becomes
quite significant for finer granularity cells such as micro- or picocell clusters. The
presence of frequent cell crossing, which is a common scenario in highly commuting
zones, further adds to the cost. The system creates location areas and paging areas
to minimize the cost. A number of neighboring cells are grouped together to form a
location area, and the paging area is constructed in a similar way. In some situations,
remote cells may be included in these areas. It is useful to keep the same set of
cells for creating location and paging areas, and in most commercial systems they
are usually identical. This arrangement reduces location update frequency because
location updates are not necessary when a mobile unit moves in the cells of a location
area. A large number of schemes to achieve low cost and infrequent update have been
proposed, and new schemes continue to emerge as cellular technology advances.
A mobile unit can freely move around in (a) active mode, (b) doze mode, or (c)
power down mode. In active mode the mobile actively communicates with other
subscriber, and it may continue to move within the cell or may encounter a handoff
which may interrupt the communication. It is the task of the location manager to
find the new location and resume the communication. In doze mode a mobile unit
does not actively communicate with other subscribers but continues to listen to the
base station and monitors the signal levels around it, and in power down mode the
unit is not functional at all. When it moves to a different cell in doze or power down
modes, then it is neither possible nor necessary for the location manager to find the
The location management module uses a two-tier scheme for location-related tasks.
The first tier provides a quick location lookup, and the second tier 4earch is initiated
only when the first tier search fails.
Location Lookup
A location lookup finds the location of the called party to establish the communication
session. It involves searching VLR and possibly HLR. Figure 3.1 illustrates the entire
lookup process IS], which is described in the following steps.
Fig. 3.1 Location search steps.
Step 1: The caller dials a number. To find the location of the called number (destination), the caller unit sends a location query to its base station source base
Step 2: The source base station sends the query to the S-LS (source location server)
for location discovery.
Step 3: S-LS first looks up the VLR to find the location. If the called number is a visitor
to the source base station, then the location is known and the connection is set
Step 4: If VLK search fails, then the location query is sent to the HLR.
Step 5 : HLR finds the location of D-LS (destination location server).
Step 6: The search goes to D-LS.
Step 7: D-LS finds the address of D-BS (destination base station).
Step 8: Address of D-BS is sent to he HLR.
Step 9: HLR sends the address of D-BS to S-LS (source location server).
Step 10: The address of D-BS is sent to the source base station, which sets up the
communication session.
Location Update
The location update is performed when a mobile unit enters a new registration area. A
location update is relatively expensive, especially if the HLR is distributed. The frequency of updates depends on the intercell movement pattern of the mobile unit such
as highly commuting subscribers. One of the tasks of a good location management
scheme is to keep such updates to a minimum.
In the new registration area the mobile unit first registers with the base station, and
the process of location update begins. Figure 3.2 illustrates the basic steps of location
Fig. 3.2 Location update steps.
Step 1: The mobile unit moves to a new registration area which is serviced by a new
location server (New LS). The mobile unit informs the new base station about
its arrival.
Step 2: The new base station sends the update query to New LS.
Step 3: The New LS searches the address of the HLR in its local database.
Step 4: The new location of the mobile unit is sent to HLR.
Step 5: The old location of the mobile unit is replaced by the new location.
Step 6: The HLR sends user profile and other information to New LS
Step 7: The New LS stores the information it received from HLR.
Step 8: The New LS informs the new base station that location update has been completed.
Step 9: The HLR also sends a message about this location update to the Old LS. The
Old LS deletes the old location information of the mobile unit stored in its
Step 10: The Old LS sends a confirmation message to the HLR.
Fig. 3.3 Transient loop in forward pointer scheme.
The current location management scheme has very high search and update costs,
which increase significantly in the presence of frequent cell crossing because every
'This is a part of registration process.
registration area crossing updates HLR. These issues motivated researchers to find
efficient and cost effective schemes. A number of new location management schemes
have been proposed recently, and a partial list is given here [ 1,2,3,4,5,10, 11, 131. A
good survey of some these schemes can also be found in [8,12]. Instead of presenting
a particular scheme a general description of forwarding pointer approach is discussed
here to present the main idea [ 5 , 81.
Forwarding Pointer Location Management Scheme
The objective of the forwarding pointer scheme is to minimize network overhead due
to HLR updates. Unlike conventional scheme, this scheme uses a pointer to the next
location of the mobile user. Thus instead of updating HLR, the scheme just sets a
pointer at the previous location of the mobile unit which points to its current location.
The pointer is a descriptor which stores mobile unit identity and its current location.
A mobile unit movement is unpredictable, and it is possible that the unit may visit
a registration area multiple times during a live communication session. If forward
pointers are continuously created and maintained, then a revisit to a registration area
creates a transient loop. Figure 3.3 illustrates the formation of transient loop in
forward pointer strategy. Initially, mobile units MU 1 and MU2 were communicating
in registration area R1. Unit MU2 makes its first move to R2, and then it moves back
to RI through R3 and R4. This type of movement creates a transient loop where the
communication path is R1 --+ R2 R3 4R4 + R 1 . However, even in the worst-case
scenario the transient loop does last for long.
Updates Using Forward Pointers: When MU2 leaves registration area R1 and
moves to R2 then (a) the user profile (MU2 profile) and the number of forward
pointers created so far by MU2 is transferred from R1 to R2 and (b) a forward pointer
is created at R1 which points to R2. This forward pointer can be stored in any BS
data structure.
At some point the current location of the MU needs to be updated in HLR. Usually,
heuristic based update approach is used. One scheme could be based on the number
of pointers created [S]. In this scheme an upper limit of pointers can be predefined;
and once this threshold is reached HLK is updated. Another scheme can be based
on the number of search requests, yet another can be based on constant update time.
Thus the HLR is updated after so many hours or minutes have elapsed since the last
update. The performance of these update schemes will very much depend on the user
Location Search Using Forward Pointers: The search scheme is illustrated in
Figure 3.4. A user in "Source" registration area wants to communicate with a user in
"Destination" area. The following steps describes the location discovery.
Step I : The caller dials the number of destination user. To find the location of the called
number (destination), the caller unit sends a location query to its base station
source base station.
Fig. 3.4 Location search using forward pointer.
Step 2: The source base station sends the query to the Source LS (source location
server) for location discovery.
Step 3: Source LS first looks up the VLR to find the location. If the called number is a
visitor to the source base station, then the location is known and the connection
is set up.
Step 4: If VLR search fails, then the location query is sent to the HLR.
Step 5: The Destination HLR finds the location of destination location server (DestLS).
Step 6: The Destination HLR sends the location of destination location server (DestLS) to the Source LS.
Step 7: The Source LS finds the first forward pointer (8) and traverses the chain of
forward pointers (9, 10, 11, . . .) and reaches the Destination location server
(Current LS).
Step i: The location of current base station is forward to the Source LS.
e p i + 1: Source LS transfers the address of current base station to the source base station
and the call is set up.
Forward Pointer Maintenance: Pointer maintenance is necessary to (a) remove
pointers which have not been used for some time and (b) delete dangling pointers.
During movement a mobile unit may create a number of pointers including transient
loops. In Figure 3.3 when the MU2 returns to R1, the forward pointers R2 + R3,
R3 --+ R4, and R4 i R2 will not be referenced to locate MU2, so they can be
safely removed from the search path. The identification of candidates for removal
can be achieved in a number of ways. One way is to associate a timestamp with each
forward pointer and define a purge time slots. At a purge slot ifpurge slot > apointer
timestamp then this pointer can be a candidate for removal. The another way is to
keep a directed graph of pointers. If a loop is found in the graph, then all edges except
the last one can be removed. It is possible that in a long path there may be a small
loop. For example, in path R2 -t R3, R3 + R4, R4 --f R3, and R3 + R5, the small
loop R3 + R4 and R4 -+ R3 can be replaced by R3 --f R5. In further refinement,
path R3
R5, with R5 being the current location, can be replaced by R2 R5.
Dangling pointers occur if redundant pointers are not removed in a correct order.
In the above removal process, if the path R2 + R3 is removed first, then the path
R2 + R5 cannot be set and paths R3
R4, R4 + R3, and R3 + R5 will create
dangling pointers. This is classical pointer management problem with a different
effect in mobile scenario.
The entire pointer management process must be synchronized with HLR update.
Note that HLR may have been updated many times during the creation of forward
pointers. Any reorganization must maintain the location consistency in HLR. Further
information about the performance of pointer maintenance schemes can be found in
Ref. [S].
Handoff Management
The process of handoff was briefly discussed in Chapter 2. This section discuses
how a handoff is managed to provide continuous connectivity. Figure 3.5 illustrates
the presence of an overlap region between Cell 1 and Cell 2. A mobile unit may
spends some time in this overlap area and the value of this duration depends upon the
movement speed of the mobile unit. The duration a mobile unit stays in this area is
called the degradation interval [ 101. The objective is to complete a handoff process
while the mobile unit is still in the overlap area. This implies that the handoff must not
take more than the degradation interval to complete he process. If for some reason
the process fails to complete in this area or within degradation interval, then the call
is dropped.
Fig. 3.5 Cell overlap region.
A handoff may happen within or outside a registration area. If it happens within a
registration area, then it is referred to as intra-system handoff where the same MSC
manages the entire process. An intersystem handoff occurs between two separate
registration areas where two MSCs are involved in handoff processing. In each of
these cases the handoff processing is completed in three steps:
Handoff detection: The system detects when a handoff process needs to be
Assignment of channels: During handoff processing the system identifies new
channels to be assigned for continuous connectivity.
Transfer of radio link: The identified channels are allocated to the mobile
Handoff Detection
Handoff processing is expensive, so the detection process must correctly detect a
genuine and False Handoff (see Chapter 2) which also occurs because of signal
fading. There are three approaches for detecting handoff effectively and accurately.
A brief description of these approaches, which are applied on GSM system but also
used in PCS, is presented here and further details can be found in Ref. [lo]. They
are called:
Mobile-Assisted Handoff (MAHO)
Mobile-Controlled Handoff (MCHO)
Network-Controlled Handoff (NCHO)
Mobile-Assisted Handoff (MAHO): This scheme is implemented in second-generation
systems where TDMA technology is used. In this approach, every mobile unit continuously measures the signal strength from surrounding base stations and notifies the
strength data to the serving base station. The strength of these signals are analyzed,
and a handoff is initiated when the strength of a neighboring base station exceeds the
strength of the serving base station. The handoff decision is made jointly by base
station and Mobile Switching Center (MSC) or base station controller (BSC). In case
the Mobile Unit (MU) moves to a different registration area, an intersystem handoff
is initiated.
Mobile-Controlled Handoff (MCHO): In this scheme the Mobile Unit (MU) is
responsible for detecting a handoff. The MU continuously monitors the signal strength
from neighboring base stations and identifies if a handoff is necessary. If it finds the
situation for more than one handoff, then it selects the base station with strongest
signal for initiating a handoff.
Network-Controlled Handoff (NCHO): In this scheme, Mobile Unit (MU) does
not play any role in handoff detection. The BS monitors the signal strength used by
MUs and if it falls below a threshold value, the BS initiates a handoff. In this scheme
also BS and MSC are involved in handoff detection. In fact the MSC instructs BSs to
monitor the signal strength occasionally, and in collaboration with BSs the handoff
situation is detected. The MAHO scheme shares some detection steps of NCHO.
Necessary resources for setting up a call or to process a handoff request may not
always be available. For example, during a handoff the destination BS may not have
any free channel, the MU is highly mobile and has requested too many handoffs,
the system is taking too long to process a handoff, the link transfer suffered some
problem, and so on. In any of these cases the handoff is terminated and the mobile
unit loses the connection.
Assignment of Channels
One of the objectives of this task is to achieve a high degree of channel utilization
and minimize chances of dropping connection due to unavailability of channel. Such
failure is always possible in a high traffic area. If a channel is not available, then the
call may be blocked (blocked calls);and if a channel could not be assigned, then call
is terminated (forced termination). The objective of a channel allocation scheme is
to minimize forced termination. A few schemes are presented here [ 101.
Channel assigned
Ongoing call + [ C c a__.
r d
Fig. 3.6 Nonprioritized scheme steps. (Reproduced from Wireless and Mobile Network
Architectures under written permission of John Wiley & Sons.)
Nonprioritized Scheme: In this scheme the base station does not make any distinction between the channel request from a new call or from a handoff process. If a free
channel is not available then the call is blocked and may subsequently be terminated.
Figure 3.6 shows the entire channel assignment process.
Reserved Channel Scheme: In this scheme a set of channels are reserved for
allocating to handoff request. If a normal channel is available, then the system assigns
it to a handoff request; otherwise the reserved channel is looked for. If no channels
are available in either set, the call is blocked and could be dropped. Figure 3.7shows
the entire channel assignment process.
,’ \\
4 Call blocked 1
-1 Channel
- assigned 1
I -
O n g o i n g ~ ~ - - ~ I C h a n n e lreleased
’ Reserved
(Channel available;d!%,_Channel,
Fig. 3.7 Reserved channel scheme steps. (Reproduced from Wireless and Mobile Network
Architectures under written permission of John Wiley & Sons.)
Queuing Priority Scheme: In this scheme a channel is assigned based on some
priority. If a channel is available, then the handoff request is process immediately;
otherwise the request is rejected and the call is dropped. There is a waiting queue
where requests are queued. When a channel becomes available, then one of the
requests from the waiting queue is selected for proccssing. The queuing policy may
be First in First Out (FIFO) or it may be rneasured-based or some other scheme. In
the measured-based approach the request which is close to the end of its degradation
interval is asGgned a channel first. In the absence of any free channel the call is
terminated. Figure 3.8 shows the entire channel assignment process.
, \
Insert call into the waiting queue
call channel released
I New
Is a
before the call ,,
\ ,expires?,/
Is the waiting
Fig. 3.8 Queuing priority scheme steps. (Reproduced from Wireless and Mobile Network
Architectures under written permission of John Wiley & Sons.)
Subrating Scheme: In this scheme a channel in use by another call is subrated,
that is, the channel is temporarily divided into two channels with a reduced rate. One
channel is used to serve the existing call and the other channel is allocated to a handoff
request. Figure 3.9 shows the channel assignment process.
Handoff call
Channel assigned
New call
Call blocked
Each channel of
the subrated pair is
upgraded to fullrate channel
of the subrated pair
The channel is idle
Fig. 3.9 Subrating scheme steps. (Reproduced from Wireless and Mobile Network Architectures under written permission of John Wiley & Sons.)
Radio LinkTransfer
The last phase of handoff is the transfer of the radio link. The hierarchical structure
of cellular system (PCS and GSM) presents the following five-link transfer cases for
which handoff has to be processed.
Intracell handoff Link or channel transfer occurs for only one BS. In this
handoff a MU only switches channel. Figure 3.10 illustrates the scenario.
Intercell or Inter-BS handoff The link transfer takes place between two BSs
which are connected to the same BSC. Figure 3.11 illustrates the scenario.
Inter-BSC handoff: The link transfer takes place between two BSs which are
connected to two different BSCs and the BSC is connected to one MSC. Figure
3.12 illustrates the scenario.
Intersystem or Inter-MSC handoff The link transfer takes place between
two BSs which are connected to two different BSCs. These two BSCs are
connected to two different MSCs. Figure 3.13 illustrates the situation.
As discussed in Ref. [ 101, typical call holding time is around 60 seconds. Some
real-life data indicates that there could be around 0.5 inter-BS handoff, 0.1 inter-BSC
Fig. 3.10 Channel transfer in intracell handoff.
Fig. 3.11 Channel transfer between two BSs with one BSC.
handoff, and 0.05 inter-MSC handoff. The data also indicate that the failure rate of
inter-MSC handoff is about five times more than inter-BS handoff. It is quite obvious
that efficient processing of handoff is quite important for minimizing the call waiting
There are two ways to achieve link transfer. One way is referred to as Hard
Handofland the other as Soft Handoff.
Fig. 3.72 Channel transfer between two BSs connected to two BSCs.
/-/adHandoff: In this handoff process the user experiences a brief silence or discontinuity in communication which occurs because at any time the MU is attached
to only one BS and when the link is transfer the connection is broken temporarily
resulting in a silence. The steps of the handoff for MCHO link transfer is described
below. Further detail is given in Ref. [lo].
1. MS sends a “link suspend” message to the old BS which temporarily suspends
the conversation (occurrence of silence).
2. The MS sends a “handoff request message“ to the network through the new BS.
The new BS then sends a “handoff acknowledgement“ message and marks the
slot busy. This message indicates the initiation of the handoff process.
3 . This acknowledgment message indicates to MU that the handoff process has
started, and so MU returns to the old channel it was using and resumes voice
communication while network process the handoff.
4. When the new BS receives the handoff request message, then two cases arise:
(a) It is an intra-BS handoff or (b) it is an inter-BS handoff. In the former case
the BS sends a handoff acknowledgment message and proceeds with handoff.
In the later case, since it is between two different BSCs, the BS must complete
some security check. It gets the cypher key from the old BS and associates it
with the new channel.
5. The MSC bridges the conversation path and the new BS.
Fig. 3.13 Channel transfer between two BSs with two BSCs connected to two MSCs.
6. On the command of the network, the MS processes the handoff where it releases
the old channel by sending an “access release” message to the old BS. In this
process the voice communication is briefly interrupted again.
7. The MU sends a “handoff complete” message through the new channel and
resumes the voice communication.
A detailed discussion on hard handoff for other kinds of link transfer and soft
handoff can be found in Ref. [lo].
3.1.3 Roaming
In the presence of multiple wireless service providers the continuous connectivity is
provided through Roaming. Thus when a mobile moves from one GSM to another
system PCS or GSP or some other, the location of MU must be informed by the new
service provider to the old service provider. This facility is called roaming facility.
These two service providers communicates with each other to complete the location
management and the registration process as described earlier.
The other important aspect of roaming is the administrative issues related to billing.
Multiple service providers have to come to some agreement about the charges and
pri vi I eges.
This chapter covered the topics of location management and handoff process. These
processes use a number of subsystems and databases such as HLR and VLR. The
chapter described the structure and use of these subsystems and databases. In location management discussion the role of VLR to speed up the process of location
identification was discussed. Since location management is an important subsystem, a number of efficient schemes were developed and this chapter discussed some
of them. Although these new schemes show high performance, they have not been
deployed in any working system.
This chapter completes the discussion of technology necessary to build a mobile
database system. Subsequent chapters deal with information management issues
beginning with the introduction to the database management discipline.
1. How the geographical location of a mobile unit is expressed? What is the
reference point? Develop a simple scheme for identifying the geographical
location of a mobile unit in a cell.
2. What do you understand by the term “location management“? Describe the
steps of a location manager to identify the location of a mobile unit. Assume
that HLR is stored at a central location.
3. What do you understand by the term “handing over the channel?” When is this
process necessary?
4. Clearly explain the difference between a hard and a soft handoff. Explain
different ways of processing a handoff.
5. In how many different modes a cell phone may enter? Explain the activity of
the cell phone in each of these modes.
6 . Explain different schemes of location management and discuss their advantages
and disadvantages.
1. I. F. Akyildiz and J. S. M. Ho, “Dynamic Mobile User Location Update for
Wireless PCS Networks,“ ACM/Baltzer Wireless Network Journal, Vol. 1, No.
2, 1995.
2. B. R. Badrinath, T. Imielinski, and A. Virmani, “Location Strategies for Personal
Communication Networks,“ Proceedings of the 1992 International Conference
on Network for Personal Communications, 1992.
3. G. Cho and L. F. Marshal, “An efficient Location and Routing Schema for Mobile
Computing Environments,“ IEEE Journal on SelectedAreas in Communications,
Vol. 13, No. 5 , June 1995.
4. H. Harjono, R. Jain, and S. Mohan, “Analysis and Simulation of a Cache-Based
Auxiliary User Location Strategy for PCS,“ Proceedings of the 1994 International
Conference on Networks for Personal Communications, March 1994.
5 . R. Jain and Y-B Ling, “An Auxiliary User Location Strategy Employing Forward
Pointers to Reduce Network Impacts of PCS,” Wireless Networks, Vol. 1, 1995.
6. Rajan Kuruppillai, Mahi Dontamsetti, and Fil J. Cosentino, “Wireless PCS,”
McGraw-Hill, New York, 1997.
7. Seshadri Mohan and Ravi Jain, “Two User Location Strategies for Personal Communications Services,“ IEEE Personal Communications, Vol. I,No. 1, 1994.
8. P. Krishna, “Performance Issues in Mobile Wireless Networks,” Ph.D. Dissertation, Texas A&M University, 1996.
9. Wireless Intelligent Network (WIN), Lucent Technologies.
10. Yi-Bing Lin and Imrich Chlamtac, Wireless and Mobile Network Architecture,
John Wiley & Sons, New York, 2001.
1 1. S. Mohan and R. Jain, “Two User Location Strategies for Personal Communication Services,“IEEE Personal Communications, Vol. I , No. 1, 1994.
12. E. Pitoura and G. Samaras, Data Management for Mobile Computing, Kluwer
Academic Publishers, Boston, 1998.
13. S. Rajgopalan and B. R. Badrinath, “An Adaptive Location Management Strategy
for Mobile IP,“ Proceedings of the 1st ACM International Conference on Mobile
Computing and Networking (Mobicom’95),Berkeley, CA, October 1995.
14. C. Rose and R. Yates, “Location Uncertainty in Mobile Networks: A Theoretical
Framework,“ IEEE Communication Magazine, Vol. 35, No. 2, 1997.
15. J. Z. Wang, “A Fully Distributed Locatioin Registration Strategy for Universal
Personal Communication Systems,“ IEEE Journal on Selected Areas in Communications, Vol. 11, No. 6, August 1993, pp. 850-860.
Fundamentals of
Database Processing
The objective of this chapter is to introduce the conventional approach of data processing technology. It describes the fundamentals of database management systems
and reviews available architecture. The limitations of current database technology
to manage new types of information processing requirements are discussed in detail,
which helps to make a case for mobile database systems.
A database is a repository of facts about the organization it models. The state of the
organization continuously changes, and these changes must be incorporated into the
database to preserve the facts. The system uses a transaction mechanism for incorporating these changes into the database in a consistency preserving manner. The
software module which manages transactions is called database management system
(DBMS), which also serves as an interface between users of the database and the
database. A user interacts with the DBMS through a query language such as SQL
(structured query language), which takes the user’s data processing requests to the
DBMS. The DBMS creates a transaction or a set of transactions which executes necessary operations under the concurrency control mechanism to process users request.
At the end of all necessary modification the DBMS sends the user the final results.
There are two basic types of system architecture on which the entire DBMS is
implemented: (a) centralized and (b) distributed.
Fig. 4.1 Architecture of centralized database systems.
Centralized DBMS: In a centralized database management system there is one
processing node (server) and a number of intelligent terminals (clients) connected to
the server through wired network. A client accepts users’ request through a query
language such as SQL. It may process the query (transaction) if it has the resources;
otherwise it sends it to the server for processing. The server sends the results to the
client and the clients formats and sends them to the user. Figure 4.1 illustrates a
reference architecture of a centralized database systems.
Distributed DBS: In a distributed database system a number of centralized database
systems are connected together with a communication network. These servers can
be configured as peers or a set of dependent and independent and homogeneous and
heterogeneous servers. Each configuration identifies a special type of distributed
database system. A detailed categorization of distributed database system is covered
in Ref. [38]. Figure 4.2 illustrates a reference architecture of a distributed database
There are two commonly known categories (a) federated database system or (b)
multidatabase system. This categorization is based on node autonomy, data processing, and distribution mode. In a federated architecturea subset of servers are partially
autonomous in managing their activities. They are members of the federation and
are willing to cooperate and participate with other members (servers) under a set of
mutually agreed protocols. For example, in a big company each department may
have their own servers and may participate among themselves to maintain the consistent view of the entire company in its data warehouse. This federation could be
homogeneous where each server may run the same database management system or
heterogeneous where each have a different system. For example, one server may be
using Oracle, the other may be DB2 or Sybase, and so on.
In a multidatabase architecture, all servers of the distributed database system have
full autonomy. It is up to each server to cooperate or not to cooperate with any
other server in the architecture. This kind of architecture can be found in franchise
Fig. 4.2 Architecture of distributed database systems.
setup. Every vendor under a franchise acts independently with or without mutual
Database Partition and Distribution
In centralized database systems there is only one server, so the question of data distribution does not arise. However, this is quite important in distributed database systems
and must be managed carefully because it significantly affects system performance
and availability.
In distributed systems the database is distributed in three ways: (a) partitioned,
(b) partially replicated, and (c) fully replicated to improve data availability, quality
of service, and performance. The selection of a data distribution scheme depends
on a large number of system and application parameters. One of the most important
consideration is the local availability of necessary data to process user query efficiently
and to minimize communication cost.
Database Partition: Under this scheme the entire database is distinctly divided into
a number of partitions. Usually there are the same number of partitions because there
are a number of processing nodes (servers). These database partitions are allocated
to servers under a set of criteria. Some of the important criteria are as follows:
The partition should support highest database locality. This means that the
majority of queries can be processed by the partition at that server.
It should help to minimize the data communication cost.
It should help to minimize the cost of maintaining global consistency.
It should help to localize the serialization of concurrent transactions.
It should minimize the cost of recovery.
The partition scheme is less reliable and suffer from a center point of failure. If
a server fails then its partition becomes unavailable until it recovers from the failure.
In addition to this because of zero data redundancy, it is unable to provide adequate
reliability. Some of these are taken care of by partial replication of the database.
Table 4.7
Comparison of data distribution schemes
Full Replication
Partial Replication
Data locality
Global consistency
Very high
Very high
Recovery cost
Very high
Partial Replication: Under this scheme the database is partitioned and a subset of
partitions is replicated at more than one servers. The partial replication has all the
properties of partition scheme and it further improves database locality and reliability.
If a server fails then the replicated copy of the partition is still available for processing
queries. The recovery is easier because the replicated partition can be copied entirely
to the server after it recovers from failure.
It is relatively more time consuming to maintain the global consistency because
any change in a partition must be installed to all its replications located at various
servers. To further increase database locality the database is fully replicated.
Full Replication: Under this scheme the entire database is replicated at all servers.
This has maximum locality and it also minimizes data communication cost during
query processing.
The fully replicated scheme provides the highest reliability and availability, but at
the cost of maintaining global consistency, This scheme is not used in reality because
of higher consistency and database storage cost. Table 4.1 summarizes the the merits
of the three data distribution approaches.
The mechanism which facilitates consistency preserving changes is called Transaction. A transaction, therefore, takes the database from an initial consistent state to
the next consistent state applying a set of operations on physical data items. This
constrained transition involves a set of consistency constraints, the database, and an
application program. Thus, a transaction structure can be viewed as
Transaction = <Set of Constraints, Database, Application program>
The set of constraints can be implemented in two ways: (a) programmed in the
application code and (b) included as a part of transaction structure. The first method
is highly inefficient, and unreliable and may not be always possible. Programming
each of thesc constraints in application code is prone to error. The programmer must
have a good knowledge of the system architecture to avoid logical error. It is hard
for any programmer to know when to test for what constraint. For these reasons the
second approach is used where these constraints are associated with the transaction
structure. With this association a transaction acquires a unique position in the database
discipline and presents itself as the only mechanism for database processing.
4.2.1 Transaction Structure
The structure of a transaction is best described in terms of the set of constraints
mentioned earlier. The terms Atomicity, Consistency, Isolation, and Durability were
introduced to represent these constraints and created the appealing acronym ACID
[S, 24, 23, 261. To understand the significance of these properties or constraints, it
is useful to review the types of actions one encounters in real life or in information
management. The discussion given here follows the line of thoughts of Ref. [24].
All possible actions, especially on data, can be categorized into (a) unprotected or
Free action, (b) protected or constrained action, and (c) real action.
Unprotected or Free action: The partial result of a free action may be seen by
other free actions, and the final outcome may not be consistency preserving. An edit
or sorting or searching operation on a file, writing to a disk or RAM, etc., are examples
of unprotected operation. Database discipline requires that the actions performed on
its data must not be unprotected.
Protected or Constrained action: Partial result of a constrained action is not visible to either another constrained action or an unprotected action. The availability of
final result implies that the action committed successfully. Since database processing must have this property, it was incorporated in transaction as Atomicity property.
Atomicity requires that a constrained action can exist only in one of the two possible
states: (a) successfully completed or (b) never started. The “never started” state is
achieved by rollback operation. Thus a constrained action is atomic; either it successfully completes and the final result is available to other protected or unprotected
action or if it fails in the middle then its partial execution is rolled back to the initial
state; that is, the partial effect is removed from the database. There is no guarantee
that a constrained action will lead to data consistency. For this reason, especially
for database processing, a consistency property is introduced. By incorporating the
property of consistency, the definition of constrained action is refined.
Real action: The completion of these actions cannot be undone by rollback operations. It can be a protected or unprotected action whose final results persist in
the real world. For example, the result of firing a missile or cutting a finger cannot
be undone. There is no such thing as "uncutting" the cut finger because once a real
action is started, then the initial state is destroyed. The final result will be reached,
which may or may not be correct. For this reason it cannot be called atomic. A real
action would be useful in database management only if it could be guaranteed that
starting of the action will generate consistency preserving result. No such guarantee
could ever be given so they are not supported. It is obvious that a real action may be
unprotected and may be acceptable if the final result does not affect the real life.
Flat Transactions
The discussion on transaction mechanism begins with a $at Transaction leading to
more complex form. A detailed discussion of transaction structure is necessary to
understand its management on mobile database systems.
A$at transaction is the simplest type of mechanism which supportsone-level operation; that is, during their execution they do not trigger other dependent transactions.
A transaction is dependent on the transaction from which it reads the data item modified by the latter. Some examples of flat transactions are debidcredit transaction,
bill payment transaction, customer account statement transaction, and so on. These
perform one-level operation.
Flat transactions are constrained operation with the additional requirement that
they must satisfy consistencyproperty. The enforcementof atomicity and consistency
need two additional properties which are included in the transaction structure. The
essential properties of a transaction now can be defined as follows:
Atomicity: This is a protected action which supports only two mutually exclusive
states (a) completed and (b) not started. The completed state identifies the successful
completion of an action and the not started state identifies that the operation never
started. The not started state is achieved with the help of a rollback operation which
itself is atomic. The atomicity of rollback action defines another property which is
referred to as Idempotent. The idempotent property guarantees that one or multiple
rollback operations on the same action will produce the same final result. For example, the assignment operation X := 5 is idempotent because its multiple successful
executions are equivalent to one successful execution. Thus, if an atomic operation
is rolled back once or multiple times, its final result will be the same.
The atomicity of a transaction guarantees that its intermediate results do not exist
for the user who initiated the transaction. This is also true for messages from the
transaction. During execution if the user receives a message from the transaction
and if it is subsequently rolled back, then the received message cannot be taken back
to indicate that no message was ever sent to the user. In fact the message from the
transaction is a partial result which under atomicity must not be visible to the user.
This implies that during execution a transaction does not generate any message or if
it does it is not seen outside transaction execution space.
Consistency: This property makes sure that the value of a data item represents the
fact. If a user deposits $100 to his account with existing balance of $500, then the
database must show the final balance as $600. In terms of consistency constraints the
credit operation must satisfy
Previous balance = Current balance - Last credit amount
The next state of the database is consistent only if the last state was consistent. A
transaction takes it for granted that it always manipulates consistent database and it
also guarantees that it will produce a consistent database state.
The database does not care about the intermediate results of a transaction which
usually is inconsistent. These results are confined to the execution space of the
transaction and are not visible to the database or to any other transaction.
Isolation: This property makes sure that to preserve consistency, two conflicting
operations (e.g., read and write or write and write) on the same data item by two
different transactions are not allowed. As indicated earlier, the application program
can check consistency constraints in the code. However, this approach is prone to
error, difficult to program, and inefficient, and it also burdens the programmer to
know the system details. The isolation property was incorporated in transaction to
move the enforcement of consistency from the programming level to the modeling
level. It was enforced through a separate system software module, which is usually
referred to as Concurrency Control Mechanism or Serialization Mechanisms; this is
discussed in later sections.
Durability: This property guarantees that the final consistent result of a transaction
persists in the database, and it is not destroyed by any kind of system failure. The successful execution of a transaction indicates that it has satisfied atomicity, consistency,
and isolation, and its results must be installed in the database. When the results are
installed and the user of the transaction is notified, then it is said that the transaction
"Commits." The durability property guarantees that the effect of a transaction in the
database cannot be undone.
The property of durability is in fact not related to any of the other three properties
(ACI). It merely makes sure that whatever is installed in the database persists in the
presence of any kind of failure. It does not differentiate between a consistent and
inconsistent data. However, the three properties make sure that durability property
deals only with consistent data.
In centralized systems a transaction is processed entirely at one location. Many clients
initiate transactions (TI,Tz, . . ., T,), and they all go to the server for execution. The
server dispatches the results to the client at the end of execution of its transaction
(Figure 4.1). This way of processing concurrent transactions helps to keep the cost
of meeting ACID constraints and database recovery quite low, but at the expense of
system throughput. This is acceptable in an environment where workload remains
low and transactions are mostly short-lived. In a high-traffic environment, which
is quite common nowadays, the use of distributed systems to manage the workload
satisfactorily becomes necessary.
In a distributed system, depending upon the type of data distribution, a transaction
T is divided into a number of subtransactions (T = t l , t 2 , . . ., t,). These subtransactions are distributed to suitable processing nodes or sites (servers), some of which are
processed in parallel and some concurrently (Figure 4.2). A distributed transaction
processing is quite efficient and minimizes resource waste; however, managing the
workload (concurrency control, recovery, etc.) becomes very complex and requires
special approaches. This is especially true in multi-database or federated database
A guaranteed way to achieve consistency-preserving execution is through serial
execution. A serial execution does not allow data sharing by making sure that the next
transaction begins only when the last transaction terminates (commits or aborted). It
assumes that every two transactions are likely to conflict over a data item so schedules
each transaction separately. One of the advantages of this type of execution is that
the consistency becomes an inherent property which relieves the system to enforce it
externally. Unfortunately, a bad side effect of this is a poor resource utilization and as
a result the efficiency (response time and throughput) of the database system suffers
significantly, making the cost of achieving consistency in this way too high.
The only way out is then to run transactions concurrently (simultaneously). Unfortunately, concurrent execution cannot guarantee consistency-preservingexecution,
which is essential for database systems. If, however, this type of execution is achieved
in concurrent execution through controlled data sharing,then the problem of efficiency
would not arise. It amounts to achieving the consistency-preserving property of serial
execution through concurrent execution without affecting database efficiency. This
process is usually referred to as serialization of concurrent transactions, which mutuully excludes or isolates two transactions over the use of a common data item. The
next few sections discuss serialization process in detail.
Serializability-BasedCorrectness Criteria
A serial execution of transactions cannot achieve desirable efficiency, so they are executed concurrently. Uncontrolled concurrent execution threatens database integrity
because of inteijerence with other concurrently executing transactions.
When transactions are executed concurrently, then their basic operations (reads and
writes) are interleaved. Interleaving of basic operations may interfere with each other,
thereby producing inconsistent results; that is, either (a) the output of the transaction
is not consistent with the values of the objects in the database or (b) the effects of the
transaction on the database destroy database consistency.
The inconsistency as a result of interference can be illustrated through the execution
of concurrent transactions on a bank database using a checking account (identified
as x ) and a savings account (identified as y) which customers maintain. Overdrafts
on these accounts are not permitted so their values never go negative. There are two
types of problems: (a)lost update and (b) inconsistent retrieval.
Lost Update: As a first example, consider two concurrent transactions TI and T2
transferring money into the same account x. Assume initially that z has a balance of
$100 and that TI transfers $50 into z and T2 transfers $100.
a = read(y)
a = read(x)
b = read(x)
write(x, a+S0)
write(x, b + 100)
If (a >= SO) then
write(y, a - 50)
b = read(y)
If (b >= 90) then
write(y, b - 90)
(a) Concurrent Deposits
(b) Concurrent Withdrawals
Fig. 4.3 Lost update problem.
An interleaved execution of T I and TJ i s shown in Figure 4.3, where u and b are
local variables. The execution produces the following sequence of operations on the
database. A read operation is identified by r, [z, w],which reads the initial value of z as
w;a write operation is identified as (w,[x,
flu]),which writes the value of u into x. The
term c Ldenotes the commit of transaction T,. It is useful to represent the interleaved
execution with a schedule which records a relative execution order of reads, writes,
and commit or abort operations. It provides an easy way to see the precedence order
of conflicting operations in a schedule which is needed in serialization process. The
schedule of the execution of Figure 4.3 can be written as
- -
In this schedule, TIand Tz executed successfully and T2 wrote $200 as the final
value of z. If TIand T2 were run serially as TI
T2 or T2
then the final
value of x would have been $250. Clearly, this is not the case and the $SO deposit of
TI is missing. The reason is that the value written by TIis overwritten by Tz,since
T2 read the initial value of z before TIwrote into it. This could not have happened in
any of the serial executions TI
T2 or T2
TI.This is the case of interference
from T2 in the execution of T I .
The above interleaved execution illustrating a lost update did not violate the integrity constraint on the database for which it has potential to do so. For instance,
consider the interleaved execution of two concurrent transactions T3 and T4 that
withdraw $SO and $90 from y, respectively, assuming that the balance in the savings
account y is $90. The schedule for this execution is shown in Figure 4.3b.
- -
T ~ [ Y9, 0 ] ~ 4 [~~O,] W [ Y ,
~ O ] W [ Y0,1 ~ 3 ~ 4
The interleaved schedule processed both T3 and T4 successfully, but a serial execution of T3
T4 is only one of the two withdrawals that would have been executed
since the second withdrawal calls for y 2 0 and would not have been permitted
because it would have violated the integrity constraint.
Inconsistent Retrieval Problem: Another type of interference is known as inconsistent retrieval, which can arise as Dirty Read or as Unrepeatable Reads. Dirty
read arises when a transaction Ti reads a data item which is subsequently written by
transaction Tj (i # j). If Tj commits, then the version of data item Ti read was not
consistent. Thus Tj made Ti’sdata dirty. In Unrepeatable read if Ti reads the data
value again, then it would get a different value than what it read earlier. The following
examples illustrates how interferencegives rise to inconsistentretrieval. Consider the
interleaved execution of transactions T5 and Ts,
shown in Figure 4.4, in which a, b,
c, and dare local variables. Transaction T5 displays the sum of the balances of z and
y, whereas transaction T6 transfers $100 from y to 2.
Assuming that the initial balance of z is $200 and that of y is $100, the execution
of T5 and T6 is represented by the following schedule.
T6 [XI 2ooir6 [y, 1 o o i W 6 1x7
3001% [z, 3001T5 [yy, 1001w6 [Yy, 01c6c5
In this execution both z and y have been updated correctly (i.e., z = $300 and y =
$0). Although the sum of the balance of z and y remains invariant and equals $300,
T5 outputs $400 (i.e., a + b = $300 + $100). In a noninterleaved execution of T5 and
T6,in which T5 and T6 execute in any order, T5 would have output a sum of $300.
The reason for this discrepancy is that T5 has observed partial effects of T6 (i.e., TG
read the value of z written by T6 and the value of y before T6 wrote it); hence T5
observed an inconsistent state of z and y. In this execution, T6 made Ts’s data (i.e.,
Although in the above execution no integrity constraint is violated, similar to
lost updates, inconsistent retrievals can lead to violation of database integrity, as the
example shown in Figure 4.4(b) illustrates, assuming that z = $40 and y = $38. In
a = read(x)
b = read(y)
output(a + b)
c = read(x)
d = read(y)
write(x, c + 100)
write(y, d - 100)
(a) Display Combined Balance
a = read(x)
b = read(x)
c = read(y)
If (b > c + 1) then
write(x, b-1 )
write(x, a - 1 )
(b) Withdrawal from Checking
Fig. 4.4 Inconsistent retrievals
addition, suppose we have the requirement that the balance of the checking account
is greater than the balance of the savings account unless both have a zero balance
(x > TJ if z # 0 and 71 # 0). T7 is a promoting transaction that sets the balance of
the savings account to be a dollar less than the balance of the checking account. Tx
withdraws a dollar from the checking account.
The final result ofthis execution is z = $39 and !J = $39, which violates the integrity
constraint that calls for z > y when x and y have a nonzero balance.
The preceding examples indicates the presence of interference and illustrate that
the correctness of individual transactions is not sufficient to ensure the correctness of
concurrent executions.
Intuitively, a correct execution of a set of transactions must be free from interferences. In all the examples above, we were able to concludc whether or not a
concurrent execution of a set of transactions is acceptable by comparing its results to
a non-interleaved or serial execution of the same set of transactions.
Serial executions are interference-free, so they are consistency-preserving. Thus,
if the result of a concurrent execution of a set of transactions is the same as produced
by one of the serial execution of the same set of transactions, then the concurrent execution is also consistency-preserving. Such concurrent executions that are equivalent
to serial executions are called serializahle and satisfy the isolation property.
Indeed, serializable executions are free from interferences, as the following schedule of execution of T7 and T8 illustrates (see Figure 4.5):
a = read(x)
write(x, a - 1)
a = read(x)
b = read(x)
b = read(x)
c = read(y)
If (b > c + 1) then
write(x, b - 1)
(a) Serial Execution
write(x, a - 1)
c = read(y)
If (b > c + 1) then
write(x, b - 1)
(b) Serializable Execution
Fig. 4.5 Correct executions of T7 and T8.
In this schedule, T8 observes a consistent state of x and y produced by T7;hence,
does not violate the integrity constraint by avoiding withdrawal from x.
Several versions of serializability have been proposed, each based on different
notions of equivalence of svchedules. In most concurrency control protocols, serializability is based on the notion of conflicting operations and is called conflict
serializability. Two operations conflict when their effect is order-dependent. Conflict serializability ensures that pairs of conflicting operations appear in the same
order in two equivalent executions [18, 20,22,39]. Whether an execution is conflict
serializable can easily be determined, as discussed in the next section.
Different versions of serializability include view and state serializability [39, 4 11.
View serializability requires that each transaction read the same values and that the
final value of all data be the same, in two equivalent executions. State serializability
requires that, under all possible interpretations of transactions’ writes, two equivalent
executions must be identical when viewed as mappings from one database state to
another. Interpretation of a write is the relation of the value written in the database
to the values read before the write from the database by a transaction. A write by
a transaction can be potentially a function of some subset of the previously read
values by the same transaction. These different versions allow more concurrency
than conflict serializability, but, unfortunately, they are not practical since it is NPcomplete to lest whether an execution is view or state serialimble.
In the next section the conflict serializability is formally defined followed by the
definition of recovery correctness criteria.
Serializability Theory
Fundamental to the theory of serializability is the notion of history, which represents
the concurrent execution of a set of transactions T [8, 5, 31, 29, 28, 32, 33, 34,
351. As we discussed above, transactions are required to perform operations on
objects i n a certain manner to be considered correct. That is, correctness criteria can
be defined as constraints on the ordering of concurrent operations and transaction
primitives in histories, Similarly, correctness properties of different concurrency
control protocols can be expresscd in terms of the properties of the histories generated
by these concurrency control protocols.
Although our focus here will be on conflict serializability, the theory can be used
to reason about the other serializability criteria that are not as easy to realize. We
begin with the notion of conflicts between operations on an object and then discuss
how it induces dependencies between transactions.
Objects, Operations, and Conflicts
A database is the entity that contains all the shared objects in a system. A transaction
accesses and manipulates the objects in the database by invoking operations specific
to individual objects. The state of an object is represented by its contents. Each object
has a type, which defines a set of operations that provide the only means to create,
change, and examine the state of an object of that type. It is assumed that operations
are atomic and that an operation always produces an output (return value); that is,
it has an outcome (condition code) or a result. Operations defined on an object are
considered as functions from one object state to another object state. The result of
an operation on an object depends on the state of the object. For a given state s of
an object, we use return(s.p ) to denote the output produced by operation p and use
state(s,p ) to denote the state produced after the execution of p .
Definition 4.1 Two operations p und q conflict in a .state s, denoted by conflict(p, q ) ,
(return(s, q )
(return(s, p )
# s t a t e ( s t n t e ( s .q ) , p ) ) v
# ret,urn,(stnte(s,p),q ) ) v
# return(state(s,q ) , p ) )
Two opemtions that do not corzjict aye compatible and commute.
That is, two operations conflict if their effects on the state of an object or their
return values are not independent of their execution order. Clearly, for this to be true
(i.e., they conflict), both should operate on the same object and one of them modifies
the object (e.g., it is a write operation). On the other hand, two read operations on
the same object commute and can be executed in any order.
For each object, the conflict relations between pairs of conflicting operations specify the concurrency properties of the object and can be expressed as a compatibility
table. A yes entry for ( p , q ) indicates that the operations p and q are compatible (i.e.,
Table 4.2 Compatibility matrix of read and write operations
Read (x)
Write (x)
Read (x)
Read (x)
do not conflict), and a no entry indicates that the two operations are incompatible
(i.e., do conflict). Table 4.2 shows the compatibility matrix of an object such as a
page that supports read and write operations.
It is now necessary to formally characterize transactions, histories, and a correct
execution of a set of transactions in terms of the invocation of conflicting operations.
Concurrent transactions may interfere with each other only if they invoke conflicting
operations on the same object.
Histories of Transactions
During the course of their execution, transactions invoke operations on objects in the
database and transaction management primitives. Invocation of an operation on an
object or a transaction management primitive is termed an event. The set of operations
and primitives invoked by a transaction T, can be expressed as a partial order with
ordering relation "-+", which denotes the temporal order in which the related events
occur. The reason that a transaction is modeled as a partial order is because a transaction may invoke two or more nonconflicting operations in parallel. For example,
two read operations on two different objects can be executed concurrently.
We use p,[ob] to denote the object event corresponding to the invocation of the
operation p on object ob by transaction Tt. In general, we use t J to denote the
invocation of an event E by transaction TJ. The predicate E 4, E' is true if event E
precedes event f' in transaction T,. Otherwise, it is false. (Thus, E +, 6' implies that
f E T, and f' E T,.) We will omit the subscript in an ordering relation + when its
context is clear.
Definition 4.2 A transaction Ti is a partial order with ordering relation + i where
I. T, = {p,[ob] I p is an operation on ob} U {p,, a,, c,}
Operutions in T, cun be operutiorzs on objects, begin (p),commit (c)and abort
( 0 )primitives.
2. 'di b'p'dob p2[0h]t T, + (PI -+, p,[ob])
All operations of a transaction follow its begin operation.
~ lE
i Ti @ ci # Ti
A transaction can either commit or abort but not both.
4. if c is c, or a,, V7VpVoh 11,[ob]E T, + ( y ,[oh] +, E )
All operations of a transaction precede its commit or abort
5. Vt V p . q Vob
p 2[ob] E T, A q, [ob]E T, A conflict(p.q )
Pa [obi )
The order of conjlicting operation7 is defined.
q, [ob])V ( q ,[ob] +?
Similar to transactions, a history of a set of transactions can be modeled as a partial
Definition 4.3 Let T = { T I ,Tz , ...,?A } be a set oftrcinsactions. A (complete) history
H qfthe concurrent execution of a set of transactions T contains all the operations
and primitives invoked by the transuctions in T and indicates the partial order - ) H
in which these operations occuz
1. H = U'7=ITi
Operations in H are exact1.y those in T I ,... T,,
2. V i V p , q V o b (pi[ob]4 , q,[ob]) (pi[ob]+H qi[ob])
The order of operations within each transaction is preserved.
3. Y i >j V). q Vob
~ ~ [ oEbf f]A y 7 [ o b ] E HAconflict(p,q) =+(pL[Ob]+ H q J ( o b ] ) V ( q 7 [ o+H
Pz [obi 1.
The ordering of every pair of conjlicting operutions is defined.
H denotes a complete history. When a transaction invokes an event, that event
is appended to the current history, denoted by H,.. That is, H,:t is a prejix of a
complete history, and it is useful in capturing incomplete executions of transactions
that contain active transactions. Incomplete executions may be a result of a system
failure or describe a scheduler in execution. A complete history does not contain any
active transactions.
The projection of a history H according to a given criterion is a subhistory that
satisfies the criterion. It is constructed by eliminating any events in H that do not
satisfy the given criterion while preserving the partial ordering of the events in the
projection projection. For instance, the projection of a history with respect to committed transactions, denoted by H,, includes only those events invoked by committed
transactions. The projection criterion can be formally specified as
H , is obtained from H by deleting all operations of noncommitted transactions in
it. Note that H , is a complete history with respect to committed transactions in T .
Given that in H , the effects of aborted transactions are nullified, serialization ordering
requirements only consider operations invoked by committed transactions; hence,
serializability criteria are expressed in terms of committed projection of histories.
Conflict Serializability
As mentioned in the previous section, the notion of equivalence between two histories
needs to be defined before being able to determine whether a history is equivalent to
a serial history and, hence, serializable. It is assumed here that any history H is over
a set of committed transactions Tc.c,,,L,,);
i.e., T = TTO,R1,L.
and H = H,.
Definition 4.4 Two histories H and H' are (conflict) equivalent, ( H = H ' ) if
1. 'di 'dp'dob, T, t T,p,[ob]E T, p,[ob] E H H p,[ob] E H'
They are defined over the same set of transactions and have the same operations.
2. 'di 'dp, 4 'doh [email protected], q ) A (p, [ob]+H qj [ob])@ (p,[ob]+H' q j [ob])
Any pair of conflicting operations p, and q3 belonging to committed transactions
T, and T , is ordered in the same way in both histories.
Definition 4.5 A history H , is serial I$ for every pair of transactions T,and Tj that
appears in H,, either all operations of Ti appear before all operations of Ti or vice
versa.; i.e.,
Definition 4.6 A history history H is (conflict)serializable if its committed projection
is (conflict)equivalent to a serial history H,; i.e., H , E H,.
Clearly, conflicting operations induce serialization ordering requirements between
the invoking transactions. Specifically,if an operationp,[ob] invoked by transaction T,
precedes an operation q3 [ob]invoked by TJand with which it conflicts (con$ict(p,q)),
then T, must precede TJin a serializable history. We will denote this ordering dependency by C binary relation on transactions T, and T3:
Definition 4.7 Serialization ordering
'dti,t j E Tcornrn, ti # t j
(tiC t j ) ifl30b 3p, q (conflict(p, q ) A (pi [ob]+ q j [ o b ] ) )
Let C* be the transitive-closure of C ;i.e.,
(ti C* t k ) # [ ( t i C t k ) V 3tj (ti C t j A tj C*
It has been shown thatserializability demands that the serialization ordering must
be acyclic [8].
Definition 4.8 Serializability Theorem
Hc is (conflict) serializable iff'dt E Tco,,, ' ( t C * t).
This means that given a history, it can be determined whether it is serializable by
testing if its committed projection does not induce any ordering dependency cycles.
A simple way to recognize whether the induced ordering dependencies are acyclic
is by constructing a dependency graph, called a serialization graph, and searching for
cycles. A serialization graph is a directed graph in which nodes represent transactions
in H , and an edge T,
Tj,i # j , means that 1
‘ ; has an ordering dependency on
Tj (i.e., one of Ti’s operations precedes and conflicts with one of T j ’ s operations in
H ) . For example, Figure 4.6 shows the serialization graph of the following history:
A serialization graph that is acyclic can also be used in finding the equivalent serial
history. This can be achieved by making a topological sorting of the serialization
graph: Whenever an edge exists between two transactions, say Ti + T,, then all
operations of T, must appear before all those of TJ in the equivalent serial history.
Since histories are partial orders, several serial orders can be obtained by topological
sorting. For example, the topological sorting of the serialization graph depicted in
Figure 4.6 produces two equivalent serial histories:
Fig. 4.6 A serialization graph.
Another property of conflict serializability of practical significance is that it is
p r e j x commit-closed’ [8]. A prefix commit-closed property means that whenever it
holds on history H , it also holds for any committed projection of a prefix H’ of H .
In other words, in an incomplete execution of transactions produced by a scheduler,
transactions are allowed to commit if their corrcsponding history is serializable. Furthermore, it means that conflict serializability can be used as a correctness criterion
in the presence of failures. After the recovery from a failure, the database reflects
the execution of only those transactions that were committed before the fiiilurc. Such
an execution corresponds to the committed projection of the prefix of the history,
which includes all the aborted transactions and the active transactions at the time of
the failure.
It should be pointed out that thc serializability theory presented in this section does
not assumc that read and write are the only operations supported on the database. All
‘Note that neither view nor state serialimhility is prefix commit-closed
the definitions in the theory depend on the notions of conflicts and hold for any pair of
conflicting operations p and y defined on an object in a database. Hence, the theory is
not limited to traditional database models, but it is also applicable to object-oriented
Atomicity and Durability
In ensuring atomicity, it is necessary that transactions that read values written by some
transaction that subsequently aborts be aborted as well. This situation is referred
to as cascading aborts. Because of the durability property of transactions, once
a transaction commits, it can neither subsequently be aborted nor can its effects
be changed because of cascading aborts. An execution is recoverable if, once a
transaction is committed, the transaction is guaranteed not to be involved in cascading
aborts, and, hence there will never be a need to nullify its effects.
Definition4.9 A transaction T , reads from T,in a history H , denoted RendFroiri ( T JT,
r,[ob])A i ( n z4 r , [ o b ] ) A 3 T k ( ( w , [ o b ]+ w k [ o b ] )3
( I P 4
In other words, a transaction T , reada the value of ob written by T, if Y',is the last
transaction that has written into ob and had not aborted before T7read 06.
Definition 4.10 A history H is a recoverable ifdT2, Tj E T ;Ti
ReudFrom(T7,Ti) + (ci + c j )
# Tj
That is, in a recoverable history, for every transaction Tj that commits, T7follows
the commitment of every transaction Ti from which T' read a value.
Given a history H whose committed projection is serializable, it does not necessarily mean that H is recoverable. For example, the following history H' of transactions
TI and T2 is serializable with T I serialized before T2, but not recoverable:
Hence, in the presence of both concurrency and failures, correct executions need to
be both serializable and recoverable. Transaction executions often have additional
properties in addition to serializability and recoverability. These simplify transaction
management and minimize the amount of computation that may be lost due to failures.
An execution is said to be cascadeless if it ensures that every transaction reads only
data values written by committed transactions; hence, the execution avoids cascading
aborts [S, 251.
Strictness, a condition stronger than, ensures that every transaction
reads and writes only data values written by committed transactions.
Definition 4.12 A history H is strict iflVT,, TJ E T ,T, # TJ Vq E { r ,iii}
(w,[ob]+ q3[ob])=3 ( c , + q 1 [ 0 b ] )v ((2,
The difference between Definitions 4.3 and 4.4 lies in r,?[ob]becoming qj [oh]in
the case of 4.4, implying that this is more general because it applies to both reads
and writes. Thus, strictness implies cascadeless. Strict executions, besides avoiding
cascading aborts, allow for efficient log-based recovery using before images [S, 251.
Serialization order does not necessarily correspond to the execution order of transactions as defined by their commit order. Given two izoninterlraving transactions TI
and T L , with 'TI committing before 1; starts execution, it is possible for 15 to precede
TI in the serialization order. Order-preserving conflict seriulizuble execution is a serializable execution where all notzinterleawd transactions have the same serialization
order and executionorder [6,9]. This property is useful for certain applications where
a temporal relationship between noninterleaved transactions is important. Consider
a stock trading application in which the order of the execution of different bids and
sales affect the price of'a stock. In an order-preserving conflict serializable execution,
a stock report transaction submitted after the commitment of a bidding transaction
T'h is guaranteed to return a stock price that reflects the effects of T b . However, this
property is not sufficiently strong to ensure that the serialization order and the execution order of all transactions in a set are the same. A property that guarantees that
execution and serialization orders are the same is called Rigorousness [ I 01.
Definition 4.13 A hiytnry H is rigoroub Iff VT,, TI T . T, # T, Yp, q Vob
conflict(p, y) A (p,[ob]
[oh]) (rL qJ [4
( 0 % qj [obi)
A history is rigorous if no data item may be read or written until the transaction that
previously invoked a conflicting operation on the data item either commits or aborts.
The difference between Definitions 4.4 and 4.5 is in 'uii [ob]becomingpi[ob], meaning
that p , [oh] applies to both reads and writes. Thus, rigorousness implies strictness
and is more general. In addition, by disallowing the overwriting of data items read
by a still-executing transaction, rigorous histories ensure reads are repeatable (i.e., a
read by a transaction on a data item returns the same value as all the previous reads
on the same data item by that transaction). Strictness does not ensure repeatable
reads. Recall that repeatable reads is a requirement for serializability. In fact, by
considering and controlling the ordering of all conflicting operations, rigorousness
becomes a restricted form of conflict serializability 110, 91.
Rigorousness simplifies transaction management, particularly in distributed databases,
since it allows for the determination of a serialization order by controlling the order
in which operations are submitted and executed.
Note that like order-preserving conflict serializability and rigorousness, recoverability, cascadeless, and strictness are all prefix commit-closed properties.
4.3.3 Degree of Isolation
This strict enforcement of consistency and isolation of ACID properties significantly
affect database system performance. Consequently, such strict enforcement is an im-
pediment in keeping with changing database processing trends as a result of new user
requirements and changing system architecture, Consistency requirements appeared
unnecessarily strict for many types of data modification. Consider, for example, the
situation in statistical databases where the computation of average or mean value
does not require strict enforcement of consistency. If one of the salary values, for
example, is inconsistent, it did not create any problem in computing the acceptable
salary average. Management of long running transactions (execution time in days or
weeks or months) became problematic too under the flat transaction model, and it did
not fit well with emerging mobile database systems.
A number of significant revisions and changes were introduced in the classical
definition of transaction to resolve the efficiency (response time and throughput) and
consistency issues. The notion of consistency was revisited and categorized into
Degree 0, Degree 1, Degree 2, and Degree 3 using the notion of dirty dutu, which
is uncommitted data of an active transaction. Later on, to eliminate ambiguity, these
degrees were introduced as degree of isolation [24]. In Chapter 5 , degree of isolation
is defined using the concept of Two-Phnse locking policy. Tn subsequent discussions,
the letter T is used to represent a transaction.
Degree 0: Ti observes degree 0 isolation if it does not overwrite dirty data of
Tjs, where i # j. Thus, Ti commits its writes before it ends. This means Tj
may read or write Ti’s write and if Ti is rolledback then Ty has to be rolled-back
too. From a recovery viewpoint, degree 0 transactions are not recoverable and
also not cascade-free. The following example illustrates the use of degree 0
Suppose T,and T3have the following operations:
T L :write (x)
T,: write (x)
History: w,(z)
w1( J )
If T, and T3 are run concurrently, then the final value of x is unpredictable
and in some situations cascading may alw occur. From recovery point of view
degree 0 transactions are not recoverable and for serialization a short lock should
be applied to x.
Degree 1: T, observes degree I isolation if
- T, does not overwrite dirty data of Tj and
- 7: does not commit its write before it ends.
This means T3cannot overwrite T,’s write and T3 does not have to roll back if
T,is rolled back. However, T3is allowed to read T,’s write before T, completes
consequently cascade roll back i\ still possible. From recovery a viewpoint, T,
can undo its execution without setting any lock without erasing TJ’supdates.
This is the main reason that all commercial database management systems
automatically provide degree 1 isolation.
T,: write (x)
T3:write (x)
History: 711, ( J - ) 111~( J - )
If T, aborts, then it can restore x’s value, which requires that under degree I
a long write lock should be applied to x for serialization.
Degree 2: T, observes degree 2 isolation if
- T, does not overwrite dirty data of T,,
- T, does not commit any writer before it ends, and
- T, does not read dirty date of TJ.
Thus, T, isolates TI’s uncommitted data. Note that in degree 1 isolation, T, may
read dirty data of T3,which cannot happen in degree 2. There is no cascading
in degree 2 transactions, but unrepeatable reads may appear as shown below.
Ti: read (x) Ti: write (x)
History: ri(n:)rj (x)w j ( n ; ) commit, r i ( z )
In this execution, Ti reads two different values of 2. First it reads the initial
value of z and then it reads the value modified by TJ without violating any
isolation condition. Under degree 2 , therefore, Ti should apply a short read
lock on x for serialization.
Degree 3: Ti observes degree 3 isolation if
Ti does not overwrite dirty data of T,,
Ti does not commit any writes before it ends,
Tidoes not read dirty date of ‘I>,
Tj does not read dirty data of Ti before Ti completes.
Thus Ti isolates dirty data of TJ for reads and writes. Note that in degree
2 isolation Ti may read two different committed values of T3. In degree 3
isolation a long read lock should be applied on x for serialization.
The degrees of isolation allow decreasing data access flexibility; degree 3 has the
least flexibility but offers true isolation of ACID properties. Such a varied degree
of data access flexibility affects concurrency, leading to lower performance. In fact,
most commercial database systems do not support degree 3 isolation. Typically, they
do not keep read lock until EOT to achieve higher concurrency [241.
In many transaction processing scenarios, lower degrees of isolation are acceptable.
This is especially true in mobile database systems where transaction waiting time
affects the performance and costs expensive resources such as wireless bandwidth.
In Chapter 5 , degrees of isolation are discussed from serialization aspects, and their
importance is evaluated for mobile database systems.
The flat transaction model quite faithfully managed database processing. It efficiently
processed large and small units of work which existed at the time when flat transaction was introduced. However, its strict adherence to ACID properties became a
sever impediment for managing emerging information processing requirements. The
management of the large unit of processing, which became known as workjow, was
too much for flat transactions to handle efficiently. The unit of work such as travel
planning, insurunce claim processing, CAD/CAM tasks, utopia planning [341, etc.,
demanded significant freedom from ACID constraints, which included redefining the
concept of data consistency and isolation. This requirement motivated the development of more powerful and scalable transaction models. The main objectives of these
models for advanced applications were to (a) increase the degree of parallelism in the
execution of long running transactions, (b) redefine consistency to manage statistical
database transactions, (c) handle failure cases in a confined way, and (d) redefine
conflict scenario. It became clear that flexible and scalable models were necessary
for advanced systems like multidatabase,,federated database, data warehouse, web,
A number of advanced transaction models were developed using a flat transaction
as the seed [ 13, 14, 15, 16, 17, 19, 30, 36, 37, 421. In fact, all advanced transaction models are an extension of the flat transaction model. Since it has never been
possible to build a system which would efficiently process all kinds of transactional
requests, many different types of database systems evolved to satisfy user demands.
The development of advanced transaction models followed this system evolution and
new data processing requirements. As a result, a number of different models came
into existence. This section introduces (a) nested transaction [36], (b) SAGA [27],(c)
cooperative transaction [37], (d) ConTract [43], and (e) flex transaction [17]. Thc purpose of this discussion is to investigate their suitability for managing mobile database
processing, which has a number of unique requirements and constraints. All these
transaction models support a common construct: finer granules unit of operations.
The difference lies in the way each manages them for producing serializable history.
NestedTransaction Model
Nested transaction model was introduced in Ref. [%I. The basic idea of this model
is to organize a flat transaction in a tree with a set of semi-independent unit of actions, which are referred to as suhtrunsactions. The root of the tree represents the
parent (main) transaction, and the descendants of the root represent finer granularity
.subtransactions of the parent transaction. Theoretically, the height of the tree could
be infinite. Figure 4.7 illustrates the nested transaction model. The parent transaction
has two subtransactions, S 1 and S2. Subtransaction S 1 has two subtransactions, SS 1
and SS2; and subtransaction S2 has two subtransaction, SS3 and SS4. Subtransaction
SS 1 has two subtransactions SSS 1 and SSS2, but SS2 has no subtranaction. Similarly,
subtransaction SS3 has two subtransactions, SSS3 and SSS4; and subtransaction SS4
has two subtransactions SSSS, and SSS6.
The relationship between the root and its descendants are clearly defined and used
to manage consistency-preservation execution (commit, rollback, abort, etc.) of the
entire transaction tree. The following list summarizes the relationship:
Fig- 4.7 A nested transaction model
Subtransactions at the leaf level are flat transactions which actually perform
the necessary data processing. The parent of a set of subtransactions does
not manipulate any data but invokes subtransactions and controls the flow of
A subtransaction can commit or rollback independent to other subtransactions
or the parent of the tree. However, such a commitment or rollback takes effect
only if the parent commits or rolls back.
A subtransaction has only A, C, and I properties because its durability depends
only on its parent. Ifthe parent rolls back, then all its subtransactions must also
be rolled back.
Concurrent parent transactions conform to ACID properties; therefore, their execution must be serialized through somc serialization scheme. From a transaction
execution viewpoint, nested transaction provides improved parallelism; and from a
recovery viewpoint it confines the tranwction failure to a smaller unit of execution,
i.e., at the subtransaction level. The parent transaction has a number of options in
dealing with the failure of a subtransaction, which can be listed as follows. The parent
Ignore the failure of subtransactions if it does not threatens database consistency.
Execute a special subtransaction (contingency subtransaction) to make up the
failure of the subtransaction.
Reexecute the failed subtransaction.
Abort an active subtranaction.
Reschedule the execution of a set of subtransactions.
The original nested transaction model was further extended by removing some
of the tight relationship between the parent and its subtransactions. To differentiate
between the two models, the original model was referred to as closed nested transaction and the extended model is referred to as open nested transaction. As the name
suggests, the parent in open-nested transaction does not enforce any restriction on the
execution, rollback, and commitment of its subtransactions. The parent transaction
only invokes subtranactions, and then these subtransactions execute independently to
each other and also to the parent.
The saga transaction model [27] is based on compensating transaction [ 121 and long
running transaction [241. If a long running transaction is divided into a number of
independent fine granularity transactions and are chained together, then each tine
transaction can execute independently. For example, if a transaction updates ten
different accounts, then the entire transaction can be divided into 10 different tine
transactions and can be executed independently of each other. It is also possible to
remedy (compensate) the malfunctioning (rollback, abort, incorrect operation, etc.)
of a single fine transaction without affecting others.
The saga model can be formally defined as a set of fine granule transactions (subtransactions) (7') where each subtransaction is associated with a compensating transaction (C). The saga can be viewed as a unit of execution with two sequences; (a)
sequence of subtransactions and (b) sequence of compensating transactions.
The saga model aims to achieve this kind of extension of long running flat transactions,
however; it does so by relaxing some of the ACID properties. The system either
executes the first sequence successfully or in the case of some failure, it runs sequence
(a) and a part of sequence (b). During the execution of sequence (a), any subtranaction
can commit or roll back independently; that is, it does not wait for other subtranactions
of the same saga. In case of a failure, if forward recovery is not possible, then it uses
the corresponding compensating transaction to remedy the situation. In this remedy
the compensating transaction may correct the error of the subtransaction or may undo
all its operations on the database.
Saga achieves this kind of execution environment by relaxing some of the ACID
properties as follows:
Atomicity: Unlike closed nested transaction, saga allows other sagas to see
the partial results of a transaction. As a result, saga cannot guarantee complete
Consistency: Unlike flat transaction, saga allows interleaved execution of
subtransactions where an active subtranaction can see the partial results of
other active subtransactions. Under this execution, consistency may not be
Isolation: Since consistency is relaxed, isolation cannot be guaranteed either.
Durability: This is preserved because saga guarantees that the main transaction
commits only when all its subtransactions are committed.
Cooperative Transaction
The cooperative transaction [37] is modeled as a rooted tree, which is called cooperative transaction hierurchy. The internal nodes of this tree are called trunsaction
groups, and the leaves are called cooperative transactions. Figure 4.8 fhows the
hierarchy. TG is the transaction group, and Crri I ’ S are cooperative transaction members.
External protocol
Fig. 4.8 Cooperative transaction structure.
Transaction Group (TG): A transaction group is a parent (root) for a number of
cooperative transactions. A TG supervises the activities of its cooperative members.
It may interact with other sibling TGs, and the interaction is managed by external
Every TG has its own version of a data item which is not accessible to any other
TG. All its cooperating members can access (read and write) this version. A TG does
not take part in data processing unless it is itself a cooperative transaction.
When a member requires a data item, then it is automatically copied from the
group to the requesting member. A new version of the data item is written back to
to TG after the member has modified it. Thus, a TG plays the role of server for its
cooperating transaction members.
Cooperative Transaction Members: Cooperative transaction members are children of a TG and operate under interriul protocol. They are like clients that issue
reads and writes on data items which are performed by their TG. When an operation
comes to TG from a cooperating transaction, then TG can either process it, refuse it,
or queue it for later processing. The cooperation among members for serialization is
monitored by their TG.
Members follow familiar execution flow starting with begin trunsuction, endtrcuisuction, and commit. A TG creates a new member by rnenzber begin command. During
execution a member goes through checkpointing, rollback, commit, etc.; thus, from
an execution viewpoint the flow is identical to the execution of a lat transaction. However, this execution environment is developed in a different way than what is done in
concurrent execution of flat transactions.
The flexibility in achieving serializability is one of the main contributions ofcooperative transaction model. The freedom to define purpose-specific correctness criteria
tits well in managing long running transactions, but at the cost of consistency.
The ConTruct transaction model was proposed i n 1431. This model aims to develop a
formal approach for developing, implementing, and managing long-lived transaction
which exists in a large number of environments such as CAD, office automation,
manufacturing control, and so on. Similar to other advanced transaction models,
Contvuct also recognizes the limitations of ACID properties for dealing with longlived transactions especially in a distributed processing environment. The main idea
of CunTruct approach is then to build a fault tolerant execution system to manage the
execution an arbitrary sequence of predefined actions, referred to as steps, according to
a .script (explicitly specified control flow description) [43]. Thus from an application
viewpoint, ConTruct is a program that offers parallel programming environment with
persistent local variables and has a well-defined error semantics for managing system
Step: A step is a basic unit of work which is executed strictly sequentially. It is
similar to asubtrunsuction of other models. Some of the examples of steps are booking
a hotel, crediting a bank account, etc. A step is implemented as an ACID transaction.
However, a step maintains only local consistency of data items it manipulates.
Script: It describes the flow of control, which can be expressed in terms of recursion,
loop, iteration, etc., and manages the execution strategies of a long running task.
The ConTruct model differs with the ACID structure as follows:
Atomicity: Any time during execution a ConTruct step can be interrupted
and its execution can be frozen which can then be restarted from the point of
interruption. In case of failure, to maintain atomicity, only roll-forward of a
step, which may use a different execution path that the original one, is allowed.
Consistency: A ConTract maintains system integrity on a larger scale.
Isolation: A ConTract, for achieving higher degree of concurrency, instead
of locking uses semantic isolation through predicates for the duration of a
Durability: A ConTrmt execution is durable in conventional sense, however,
a committed ConTruct can be compensated (undone) only by running another
ConTract. A compensation is a special case so it is done only on user request.
Flex Transaction
This model is also an extension of flat transaction and specially designed for managing transactions on multi and federated database systems. A flex transaction is a set of
tasks where each task is composed of a set of functionally equivalent subtransactions.
The objective of the model 1171 is to minimize ACID constraints to allow more flexibility in processing concurrent transactions. One of the ways the flex model achieves
this is by giving more freedom to users for defining their data processing preferences.
The commitment requirement is also relaxed by allowing a flex transaction to commit
even if some of its tasks did not complete. The main features of a flex transaction
model can be described as follows [ 1, 171:
Function replication: A task, for example, renting a car can be processed at any
ental agency. It is left to the system to process this task as efficiently as possible.
A user can also express his option for renting from a certain rental agency. The
property is incorporated in this model to allow sufficient flexibility in composing and
processing global transactions.
Mixed transaction: A flex transaction is composed of compensatable and noncompensatable subtranactions and the construct is referred to as mixed transaction.
A flex model allows to execute a compensating transaction to semantically undo or
redo the execution of a subtransaction. For example, a reserved seat can be canceled
or changed by running a compensating transaction.
Value function: A value function denotes the completion time of each subtransaction. It also allows a user to define the order of execution of a subtranaction. For
example, reserving flight before or after reserving a hotel room at the destination. It
can be formally defined using the information given in [ 1 , 171.
A flex transaction T can be represented as a 5-tuple (B,S , F.
of this tuple is described as follows:
= {t,(tp1), t2(tp!!)
is, compensatable or n
n,,f). Each member
.t,,( t p T , ) } t. i ( t p , ) are typed subtransactions, that
S is a partial order of B. It defines the success order (successful execution
order) of two typed subtransactions. Thus l i < ij t S indicates that t i must be
successfully completed before t, could be started.
F is a partial order of B , which is called the failure order of flex transaction T .
The relationship ti 4 t, E F indicates that t , is not completed if 2, fails.
is a set of external predicates on B. It may contain cost functions, time
constraints, etc., on t,.
f is an N-ary boolean function which is called acceptability function of 7’ and
describes all its acceptable states. For example, the success condition of a flex
transaction can be defined over 4 transactions as f ( ~ 1:cz;
, :I;:<, ~ 4 =) ( 2 , A x : ~ )
V (z.2 A x4), where zL’sare the execution states of t
This states that the
flex transaction can be completed if any of the combinations (XI A 25) (that is,
transactions tl and t 3 ) or ( l aA q ) (that is, transactions t 2 and t 4 ) are completed
This chapter reviewed the consistency-preservingdata base processing through ACID
transactions. To understand the mechanism of consistency-preserving execution, we
discussed the concept of serialization using different types histories generated by
thc execution of concurrent transactions. The merit of strict enforcement of ACID
properties was evaluated, and it presented some valid arguments against such strict enforcement. It then reviewed a number of advanced transaction models which relaxed
ACID constraints for improving the performance of database processing.
The next chapter discusses mechanisms for serializing the execution of concurrent transactions. These mechanisms are commonly known as Concurrencqi Control
1. Define transaction structure in terms of unprotected and protected actions.
2. Explain the ACID properties of a transaction and discuss which ACID property
can be safely removed without affecting the consistency preserving property
of the execution of concurrent transactions.
3. What do you understand by a serial execution of a set of transaction and what do
you understand by their serializable execution? Compare the advantages and
disadvantages of serial and serializable executions and explain why serializable
execution is preferred.
4. Explain degrees of isolations and comments on their usefulness in managing
database processing.
5. Compare the strength and weaknesses of different transaction models.
I . E. Anwar “An Extensible Approach to Realizing an Extened Transaction Models,”
Ph.D. Disertation, University of Florida, 1996.
2. D. Z . Badal, “Correctness ofConcurrency Control and Implications in Distributed
Databases,” In IEEE Proceedings of COMPSAC Conference, pp. 588-593, Nov.
3. B. R. Badrinath and K. Ramamritham, “Performance Evaluation of SemanticsBased Multilevel Concurrency Control Protocols,” In Proceedings c?f’ the ACM
SIGMOD, May 1990.
4. B. R. Badrinath and K. Ramamritham “Semantics-based Concurrency Control:
Beyond Commutativity,“ ACM Transactions on Database Systems, Vol. 17, No.
1, Mar. 1992.
5. N. S. Barghouti and G. E. Kaiser, “Concurrency Control in Advanced Database
Applications,“ ACM Computing Surveys, Vol. 23, No. 3, Sept. 199 1.
6. C. Beeri, P. A. Bernstein, and N. Goodman, “A Model for Concurrency in Nested
Transaction Systems,“ Journml of the ACM, Vol. 36, No. 2, Apr. 1989.
7. P. A. Bernstein, and N. Goodman, “Concurrency Control in Distributed Database
Systems,”ACM Computing Surveys, Vol. 13, No. 2, June 1981.
8. P. A. Bernstein, V. Hadzilacos, and N. Goodman, Concurrency Control and Recovery in Database Systems, Addison-Wesley, Reading, MA, 1987.
9. P. A. Bernstein, D. W. Shipman, and W. S. Wong, “Formal Aspects of Serializability in Database Concurrency Control,“ IEEE Trmnsactions on Softclvre
Engineering, Vol. 5 , No. 5, May 1979.
10. Y. Breitbart, D. Georgakopoulos, M. Rusinkiewicz, and A. Silberschatz, “On
Rigorous Transaction Scheduling,“ IEEE Transactions on Software Engineering,
Vol. 17, No.9, Sept. 1991.
11. A. Chan, S. Fox, W. K. Lin, A. Nori, and D. R. Ries, “The Implementation of an
Integrated Concurrency Control and Recovery Scheme,” in Proceedings of the
ACM SIGMOD International Conference on Management of Data, July 1982.
12. M. Chessell, C. Ferreira, C. Griffin, P. Henderson, D. Vines, and M. Butler,
"Extending the Concept of Transaction Compensation," IBM System Journal,
Vol. 41, No. 4, 2002.
13. P. K. Chrysanthis and K. Ramamritham, "ACTA: A Framework for Specifying
and Reasoning about Transaction Structure and Behavior," in Proceedings qfrhc.
ACM SIGMOD International Conference on Management of Data, May 1990.
14. P. K. Chrysanthis, "ACTA, A Framework for Modeling and Reasoning about
Extended Transactions," In ACM SIGMOD, 1990.
15. P. K. Chrysanthis and K. Ramamritham, "Synthesis of Extended Transaction
Models Using ACTA," ACM Transnctions on Database Systems, Vol. 19, No. 3.
16. W. Du and A. K. Elmagarmid, "Quasi Serializability: A Correctness Criterion
for Global Concurrency Control in InterBase," in Proceedings ofthe 15th lnternational Conference on Very Large Databases, Aug. 1989.
17. A. K. Elmagarmid, Y. Liu, W. Litwin, and M. Rusinkiewicz," " A Multidatabase
Transaction Model for Interbase," in Proceedings ofthe International Conference
on Very Large Databases, Brisbane, Australia, August 1990.
18. K. P. Eswaran, J . N. Gray, R. A. Lorie, and I. L. Traiger, "The Notion of Consistency and Predicate Locks in a Database System," Comniunications of the ACM,
Vol. 19, No. 11, Nov. 1976.
19. A. K. Elmagarmid, editor. Database Transaction Models,fir Advunced Applications. Morgan Kaufmann, CA, 1992.
20. J. N. Gray, R. A. Lorie, A. R. Putzulo, and 1. L. Traiger, "Granularity of Locks
and Degrees of Consistency in a Shared Database," in Proceedings of the First
Internationd CorZference on Very Lurge Datubases, Sept. 1975.
21. J. N. Gray, R. A. Lorie, A. R. Putzulo, and I. L. Traiger, Granularity of Locks and
Degrees qjconsistency in a Shured Data Base, Modelling in Data Base Systems,
North Holland Publishing, 1976.
22. J. N. Gray, "Notes on Data Base Operating Systems," in Operating Systems: An
Advanced Coucse, Lecture Notes in Computer Science, R. Bayer, R. M. Graham,
and G. Seegmuller, (eds.), Vol. 60, Springer Verlag, Berlin, 1978.
23. J. N. Gray, "The Transaction Concept: Virtues and Limitations," in Proceedings
of the 17th International Conference on Very Large Databases, Sept. 1981.
24. J. N. Gray, and A. Reuter, lrarzsuction Processing Concepts and Techniques,
Morgan and Kaufmann, San Francisco, 1993.
25. V. Hadzilacos, "A Theory of Reliability in Database Systems." Journal of the
ACM, Vol. 35, No. 1, Jan. 1988.
26. T. Haerder and A. Reuter, “Principles of Transaction-Oriented Database Recovery,“ ACM Computing Surveys, Vol. 15, No. 4, Dec. 1983.
27. H. Garcia-Molina and K. Salem,”“Sagas,“ in Proceedings oftheACM Conjermce
on Management of Data, May 1987.
28. M. Herlihy, “ApologiLing Versus Asking Permission: Optimistic Concurrency
Control for Abstract Data Types,” ACM Transactions on Database Systems, Vol.
15, No. 1,Mar. 1990.
29. M. Herlihy and W. Weihl, “Hybrid Concurrency Control for Abstract Data Types,”
in Proceedings of the Seventh ACM SIGACT-SIGMOI~-SlGARTSymposium on
Principles of Database Systems, Mar. 1988.
30. H. F. Korth, W. Kim, and F. Bancilhon, “On Long-Duration CAD Transactions,”
Infimnation Sciences, Vol. 46, No. 1-2,Oct.-Nov. 1988.
3 1. V. Kumar, Pet$ormunce of Concurrency Control Mechanisms in Dutuhase Syst e m , Prentice Hall, Englewood Cliffs, NJ, 1996.
32. H. T. Kung, and C. H. Papadimitriou, “An Optimality Theory of Database Concurrency Control,”Acta Informutica, Vol. 19, No. 1, Jan. 1984.
33. H. T. Kung and J. T. Robinson, “On Optimistic Methods for Concurrency Control,“ ACM Transactions on Datahose Systems, Vol. 6, No. 2, June 198 1.
34. N. A. Lynch, “Multilevel Atomicity - A New Correctness Criterion for Database
Concurrency Control,“ ACM Trunsactions on Database Systems (TODS),Vol. 8,
No. 4, June 1983.
35. D. Menasce and T. Nakanishi, “Optimistic Versus Pessimistic Concurrency Control Mechanisms in Database Management Systems,” Infbrmation Systems, Vol.
7, No. 1, 1982.
36. J. E. B. Moss, Nested Transactions: An Approach to Reliable Distributed Computing. MIT Press, Cambridge, MA, 1985.
37. M. Nodine and S. Zdonik, “Cooperative Transaction Hierarchies: A transaction Model to Support Design Applications,“ in Proceedings of the lnternationul
Conference on Very Large Databases, 1984.
38. T. Ozsu and P. Valduriez, Principles ofDistributed Dutabase Systems, PrenticeHall, Englewood Cliffs, NJ, 1999.
39. C. H. Papadimitriou, “The Serializability of Concurrent Database Updates,” Journal of the ACM, Vol. 26, No. 4, Oct. 1979.
40. C. H. Papadimitriou and P. C. Kanellakis, “On Concurrency Control by Multiple
Versions,“ ACM Trunsactions on Database Systems, Vol. 9, No. 1, Mar. 1984.
4 1. C. H. Pdpadimitriou, The Theory of’ Database Concurreiicy Control, Computer
Science Press, Maryland, 1986.
42. C. Pu, (3. Kaiser, and N. Hutchinson, “Split-transaction for open ended activities,”
in Proceedings ofthe 4th VLDB conference, 1988.
43. A. Reuter, “Contract: A Means for Extending Control Beyond Transaction Boundaries,” in Proceedings qf2nd International Workshop on High Performance Truasuctiorz Systerns, September 1989.
Introduction to
Concurrency Control
This chapter introduces conventional schemes for serializing the execution of concurrent transactions in centralized and distributed database systems. These schemes are
generally referred to as Concurrency Control Mechanisms (CCMs). The objective of
this chapter is to prepare the readers to investigate the suitability of these conventional
schemes for mobile database systems.
In a multitasking environment, resource sharing is maximized to boost system performance. It is essential to achieved such sharing in database systems in a consistency
preserving manner, which requires that at any instant of time only one activity has
the resource for its exclusive use. In operating systems a common way of sharing
is through mutual exclusion which is enforced using semaphores 1261. This mechanism, however, would not work efficiently for concurrent transactions because the
granularity of mutual exclusion (critical section) is too fine to be used in databases.
It would not be very practical to treat transactions as critical sections because of their
execution behavior and size [91. What is needed is a set of schemes which can work
with coarser granularity for synchronizing the execution of concurrent transactions.
In database systems, data sharing is managed by Concurrency Control Mechanisms
(CCMs) Concurrency Control Mechanisms. In database terminology it is usually
referred to as serializing the execution of concurrent transactions which share database
data. They achieve serialization serialization by enforcing an execution order for
conflicting operations from two different transactions in such a way that it is equivalent
to a serial execution of these transactions. A CCM acts as a catalyst in the execution
life of concurrent transactions and maintains serializability either by rolling-back or
by blocking one of the conflicting transactions. It was recognized that the method of
achieving serialization significantly affected the performance of database systems, and
therefore this problem had been intensively investigated. As a result, a large number
of CCMs were developed and experimented with to identify the simple yet efficient
CCM for a majority of transaction processing environments 1121. An approach where
the syslem had multiple CCMs to choose from and selected the one most suitablc for
the workload in hand was also tried IS]. It was observed from the experiment that a
multiple-choice scheme was too time-consuming to be efficient. Other investigations
supported this observation and concluded that the basic scheme of two-phase locking is
the most favorable among all. Since then, almost all commercial database systems use
some variation of 2PL scheme without any serious performance problem. Howevcr,
in a mobile database system the applicability of the two-phase locking approach may
have to be reevaluated where it may or may not offer acceptable level of performance.
The available CCMs can be categorized into (a) locking and (b) nonlocking approaches. Locking approaches follow a two-phase locking protocol [7J to reserve
(lock) data items for transactions and rollback and blocking operations to resolve
conflicts over shared data items [7, 121. These can be applied in a variety of ways
with different combinations, and each way defines a new CCM. First, various ways
of applying two-phase locking are discussed, and then multiple ways of resolving
conflicts are explained.
Ways of Locking Data Items
Locking protocol supports two basic operations: (a) locking and (b) unlocking. Locking and unlocking operations are atomic and mutually exclusive for a transaction; that
is, during locking, a transaction cannot use unlocking; similarly, during unlocking,
the transaction cannot apply locking. During the locking operation, also referred to
as the growing phase, the transaction locks data items it refers or may use; and during
unlocking, also referred to as the shrinking phase, the transaction releases its locked
data items. There are four different combinations for managing two-phase locking
which are explained in terms of three phases: (a) locking, (b) execution, and (c)
unlocking [ 121. In the execution phase a transaction processes its locked data items.
Simultaneous Locking and Simultaneous Release: In this scheme, locking,
execution, and unlocking phases are applied atomically and the next phase
begins only when the last phase completes successfully. Thus sturt and rizd of
locking + start and end qf execution + start and end of unlocking defines the
execution life of a transaction. The failure of any one phase does not affect other
phases. For example, if the execution phase does not complete for any reason,
then it can be restarted without restarting the locking phase. This protocol is
sometimes referred to as Static Locking in the literature. Figure 5.1 illustrates
the protocol.
Fig, 5.7 Simultaneous locking and simultaneous release protocol.
Fig. 5.2 Incremental locking and simultaneous releasc protocol.
Incremental Locking and Simultaneous Release: I n this scheme the locking
and execution phases are intcrleavcd and precede the entire unlocking phase.
Thus the growing phase completes as lock + process ---i lock -+ process,
consequently, the transaction locks and accesses only those data items it actually
processes. Unfortunately, one of the side effects of incremental locking is the
occurrenceof deadlock, but there are a number of efficient ways to manage it. It
has been observed that in database systems, deadlock detection and resolution
come out to be cheaper than deadlock prevention; as a result, this has very little
effect on database performance. Once the execution phase is complete, locks
are released simultaneously. The entire execution of a transaction can be stated
as lock process + lock + process =+unlock. A CCM based on this scheme
is also referred to as Gerzercll Wuitirzg. Figure 5.2 illustrated the protocol.
Simultaneous Locking and Incremental Release: In this scheme, growing
phase is atomic and the unlock phase is interleaved with execution phase. The
entire transaction execution can be stated as locking + execution + unlock
+ exetation + unlock. The incremental unlocking suffers with cascading,
which is a serious time-consuming activity. It is far more expensive to manage
cascading than deadlock; as a result, it is always avoided. Figure 5.3 illustrated
the protocol.
Incremental Locking and Incremental Release: In this scheme the execution
phase is interleaved with both locking and release phases. As a result, this
protocol suffers from deadlock and cascading. The objective was to minimize
transaction waiting time which the protocol did achieve, but the benefit is too
little compared t o cost of handling cascading.
Fig. 5.3 Simultaneous locking and incremental release protocol.
Fig- 5.4 Incremental locking and incremental release protocol
CCMs based on a 2PL approach enforce execution order among conflicting transactions dynamically. This means that when two transactions conflict over a data item,
the underlying CCM decides which transaction should be blocked o r rolled-back to
let the other transaction continue. Prior to a conflict, the conflicting transactions have
no defined execution order. The execution order in fact is with respect to the conflict
and not in the absence of it.
The methods of resolving conflicts (i.e., choosing which transaction to rollback
and which to block) have a significant effect on the performance of CCMs. The
main aim of an efficient CCM is to make the best possible selection, where the
effects of rollbacks and blocking are minimal on the system throughput. Since the
future actions of concurrent transactions are not known, usually conflict resolution
methods either select a victim (a transaction to rollback) on an ad hoc basis or apply
some guesswork. It is possible, however, to improve the conflict resolution method
by taking into consideration some other aspects of the execution environment of
concurrent transactions. A number of reports [ 12, 13, 14, 16, 17, 18, 191 illustrate
the detailed behavior of some two-phase locking CCMs and clearly show that some
intelligence should be used in resolving conflicts more effectively. This motivated
researchers and developers to use some heuristic approaches.
5.1.2 The Phantom Problem
One of the aims of locking schemes is to achieve the highest degree of concurrency
(number of transactions executed concurrently). The size of locking unit (locking
granularity) significantly affects the degree of concurrency. Coarce granularity-for
example, an entire file or relation-reduces the locking overhead as well a$ degree of
concurrency whereas finer granularity increases them. In addition, a finer granularity
gives rise tophantom problem. A lockable unit which is not yet present in the database
but being inserted by a transaction may give rise to this problem. Consider a case of
adding a tuple to a relation. If tuple is a locking granularity, then the concurrency
control scheme will lock this new tuple to be added to a relation. Depending upon
the progress of other concurrent transactions, some would see this new tuple and
some would not. This may introduce database inconsistency. The following example
illustrate the occurrence of phantom problem. Two transactions TI and T2 operate on
relations Accounts and Bulance. TIinserts a new tuple (400 Lenexa 2000) in the
Accounts table and TLcompares the sum of each account with the Sum in the Balance
table. Figure 5.5 shows the current situation.
---- I
Kansas City
Kansas City
Fig. 5.5 A bank database.
One of the possible concurrent execution of TI and T-2 could be:
100, Lock 200, Lock 300
(Anzount = 1000, Amount = 2000 urzd Amount = 3000)
T I : Lock 400 (phantom record)
T2: Sum = 2000 + 3000 + 5000
T I : Insert (400, Lenexu, 4000) in Accounts tuble
T2: Report the sum = 5000 "Does not included recent insert*
T I : Unlock 400
T2: Unlock 100, 200, und 300
T2: Commit.
TI: Commit.
T2: Lock
T2: Reud
Unfortunately, this execution schedule is not serialixable. T2 misses to include the
amount from the new record (400 Lenexa 4000) because at the time of reading
the Accounts table this record did not exist. If locking granularity is changed from
a record to a table, then this problem would not arise for this example. The static
locking approach also would not solve this problem. One way to take care of this
problem is through the use of Index locking.
Index Locking: The idea of an index locking is simple. Suppose index P points
to all instances of Lenexu. Now consider the case when TI locks index P , which
effectively means TI locks all instances of Lenexu including records yet to be inserted and excludes all other transaction including T2 from accessing Lenexu instance.
T2 can access Amount value for Lenexa only after the insert is complete. This way of
executing TI and Tz generates a serializable schedule.
Index locking can be explained in terms of predicates. In the above example,
TI locks those records which satisfy the predicate (Location = Lenexa). This idea
gives rise to the scheme of predicate locking, where a more complex predicate can
be composed to define locking unit precisely.
Multigranularity Locking
In reality, lockable units are of different sizes. It could be a disk block, a data page, a
relation, an attribute of a relation, or arecord of a file. This diversity defines a hierarchy
of lockable granularity and suggests the scheme of multigranularity locking. In this
scheme a transaction T’,locks data items in a hierarchical manner (from coarser to
finer granules) in different locking modes. This helps transactions which access and
modify large volume of data. For example, if a transaction modifies all tuples of a
large relation then it can just lock the entire relation for processing. On the other
hand, if a transaction accesses only a couple of tuples of a large relation, then it can
lock the entire relation in a sharable locking mode but lock the required tuples in an
exclusive mode. This way of locking allows other concurrent transactions to access
other tuples except the ones locked exclusively.
A total of five different lock modes are defined to manage multigranularity locking
requirements. These lock modes are:
Read: This mode allows a transaction to read a data item.
Write: This mode allows a transaction to write to a data item.
Intention Read - IR: A transaction applies IR when it intends to read a data
item. Thus the transaction first applies IR lock to ancestors of a data item (for
example, a relation) and then applies a read lock on the data item (for example,
its tuple) it wants to read.
Intention Write - I W It is similar to IR only the operation is a write.
Read Intention Write - IRW This mode allows a transaction to read a set of
records and modify a few of the records of this set.
Figure 5.6 shows a lock instance graph and lock compatibility matrix which are
used to define the steps of the protocol. Suppose a transaction T, wants to read File
3 and T3 wants to write to R32. The execution of T, and T3 goes as follows:
1. T, intends to read File 3, which is a node of the root Database so it applies ir
lock to Database.
2. It applies ir lock to Area I .
3 . Finally it applies a r lock to File 3.
Lock Compatibility Matrix
Area 2
w i n
iw riw
Fie 3
R5, R5,
Fig. 5.6 Lock instance graph and compatibility matrix.
4. Tj applies iw lock to Database successfully.
5. It applies iw lock to Area I successfully.
6. It cannot apply iw to File 3 because the lock conflicts with Tt’s lock r (see
conflict matrix).
7. Ti releases r from File 3.
8. T7now sets iw on File 3 and applies w on R32.
wants to read Area I so it successfully sets ir on Database.
10. It tries to set r lock on Area 1 but it conflicts with TJ’slock (iw)(see conflict
metrix) .
11. It waits for T3to release its iw lock on Area I
Heuristic Approach in Locking Schemes
In locking-based concurrency control mechanisms discussed so far, when a conflict
occurs, then the transaction requesting the data item is blocked. In incremental locking
approaches, this could create a deadlock; to resolve, it one of the transactions is rolled
back. Thus a rollback is to resolve a deadlock which is the result of a conflict and not to
resolve the conflict. This unnecessarily increases transaction waiting time. A scheme
where the conflict is immediately resolved instead of resolving its side effect (it.,
deadlock) is more effective in minimizing transaction wait time. This idea gave rise
to some aggressive approaches where conflict was resolved by immediately rolling
back or blocking conflicting transactions. This did prevent deadlock and achieved
some performance gain. A number of such aggressive schemes are discussed below.
Cautious Waiting
The policy of Cautious Waiting is an improvement over Wound-Wait (WW)and WuitDie (WD) mechanisms, and it can be further optimized. Under this mechanism a
conflict is resolved by rolling back or by blocking one of the conflicting transactions;
however, unlike WW and WD mechanisms, a transaction to be rolled back is selected
by examining the status of the conflicting transactions (blocked or running), thus
eliminating the need for timestamps. When a requestor conflicts with a holder, the
requestor is rolled back only if the holder is in a blocked state. If the holder is in
execution (i.e., not blocked due to a lock conflict), then the requestor is blocked and
resumes its execution when the holder finishes (i.e., commits or is rolled back). If the
holder is subsequently blocked, the previously blocked transaction remains blocked.
CW kills (rolls back) only the requestor. It avoids killing the blocked holder which
might have waited for a long time.
The properties of CW algorithm are summarized below:
The algorithm is nonpreemptive; that is, when conflict arises, it never aborts
the holder of the entity in the conflict.
The wait-for graph can have a queue length greater than one. This occurs when
a transaction TIis blocked by a running transaction T2 while T2 in turn is
blocked by another running transaction T3.
It is deadlock-free. CW is also conceptually simpler since there is no externally
imposed ordering.
CW can be optimized if in the conflict resolution, the amount of resource
utilized (i.e., CPU) by conflicting transactions is taken into consideration. So
in a conflict, if a transaction has to be rolled back, then the progress of the
holder and the requestor in terms of CPU utilization can be compared, and the
transaction should be rolled back which has so far consumed the least amount
of resource. This way of selecting a transaction to be rolled back takes away
the nonpreemptive quality, but it may reduce the cost of rolling-back.
Running Priority
The running priority mechanism [8] blocks the requestor (transaction requesting the
data) if the holder is running. But if the holder (transaction holding the data item) is
blocked, then it is aborted. Thus, unlike cautious waiting, the running priority allows
the requestor to continue execution by aborting all its conflicting blocked holders. It
is also possible in running priority that a blocked holder may remain blocked for a
long time and eventually get aborted.
Another algorithm similar to cautious waiting was proposed in Ref. [2]. This
algorithm limits the queue length of the waiting transaction to be one; that is, a
transaction can wait for at most one blocked transaction.
Some concurrency control mechanisms tried to reduce further the cost of conflict
resolution by more accurately selecting conflicting transactions for rolling back or for
blocking. They selected to roll back a conflicting transaction not only by examining
the execution status of holder-requestor pair but also by analyzing their execution
progress and resource utilization. One such concurrency control mechanism called
Krishna reviewed conflicting transactions progress in terms of locked data items and
already executed Read, Write, and Abort operations.
This mechanism uses Dynamic attributes [3] of conflicting transactions to resolve conflict. Transactions during their execution life inherit a number of attributes. Some
of the examples of such attributes are number of conjicts suffered by a transaction,
number qf entities locked by the transaction, duration the transaction waited for the
desired dutu items, number of times the transaction was blocked, number of times
the transaction was rolled back, etc. These attributes are called dynamic attributes
of transactions, and a subset of them can precisely identify the execution status of
a transaction. Since dynamic attributes acquire their values during execution, they
can be used as a measure of the relative progress of a transaction in a concurrent
environment. The values of a subset of these attributes can be used to identify the
right transaction for resolving conflict efficiently. For example, if transactions 371
and T2conflict, and if T I has acquired and processed relatively a larger number of
entities, then an efficient way to resolve the conflict is to roll back or block (whichever
is cheaper) Tz. It is possible that the values of all dynamic attributes of two transactions may match (identical progress in their execution). In this situation any one of
these transactions can be selected for rolling- back or blocking for resolving conflict.
Dynamic Attribute Set (DAS) can be represented as
where a, is a dynamic attribute of a transaction. Theoretically, n can be very large,
however, a small value of n with selected attributes may give us sufficient information
for making a right conflict resolution decision.
Conflict resolution scheme: The scheme uses a subset of DAS to compute priorities of conflicting transactions and uses them to decide which transaction to roll back
or to block. Whenever an operation is performed by a transaction, then the value
of the dynamic attribute representing that operation is incrcmented. For example,
if a transaction locks a data item, then the value of its number of locks acquired so
far is incremented by one. This is done for all other attribute values; as a result, it
makes the priority time-variant. It has a unique value at an instant of time, and it may
either remain the same or increase with time but never decreases. The computation
of priority of transactions TJ and T k is computed as follows:
When these two transaction conflict, then the priorities are computed as follows:
> b l ) , then P7 > P k
else i f ( a l < b l ) , then PJ < P k
else i f ( n l = b l ) then
v ( a z > bz), then P3 > Pk
else if (02 < bz), then PJ < Pk
else v ( a 2 = bz), then
... .. . ...
$ ( a , > bn), then PJ > P k
else $(a, < bn), then P3 < Pk
else # ( a , = h,,), then Pj = Pk
A Conjict Resolution Set (CRS)is created to resolve conflict. An example of CRS
(number of locks acquired so far; number of conjlicts occurred so fur; number of
roll-backs so far; number of blockings occurred so f u r}. Out of these, depending
upon the transaction processing environment, an attribute-for example, number of
locks acquired so jur-can be assigned the highest precedence since under the twophase policy the progress of a transaction depends on its successfully acquiring the
desired locks. So the number of locks gives a measure of transaction maturity (i.e.,
how far it has progressed in its execution) in terms of its data utilization.
The algorithm can be defined as follows. Transaction T, represents the requestor
of the data item and Th as the holder.
Ifthe priority of T, > the priority cfTtL,then
if Th is blocked, then roll buck Th
else block T,
else if the priority of T, 5 priority of T h , then
ifTtLis blocked, then roll-back T,
else block T,
Figure 5.7 illustrates the conflict resolution steps of Krishna. A final decision is
always reached at level 2. In the special case when PT, = P T ~
then a preemptive
or nonpreemptive decision can be taken. The introduction of the second level of test
makes this algorithm deadlock-free.
Non-Locking-Based Schemes
The purpose of the serialization process is to enforce consistency-preserving order
in conflicting operations. Locking is one of the effective and most common ways
of achieving this; however it generates locking overhead. To lock and unlock a data
item, a few thousand instructions have to be executed each time. In addition, some
incremental locking approaches had to detect and resolve deadlocks which further
compounded the overhead. To eliminate these overheads, timestamp-based schemes
were proposed.
Level 1
If PT, > P,, then
Level 2
If T, is blocked then roll-back T,
If T, is running then block T,
If T, conflicts with T,
If PTr <= P,, then
If T, is blocked then roll-back T,
If T, is running then block T,
Fig. 5.7 Conflict resolution of Krishna.
Timestamping: The timestamp approach for serializing the execution of concurrent
transactions was developed to introduce more flexibility, to eliminate the cost of
locking, and to cater for distributed database systems [4, 121. In timestamping, the
execution order of concurrent transactions is defined before they begin their execution.
The execution order is established by associating a unique timestamp (usually an
integer) to every transaction. When two transactions conflict over a data item, their
timestamps are used to enforce serialiLation by rolling back one of the conflicting
Simple Timesfamping Scheme: Under this scheme, each transaction is associated
with a unique timestamp. When a transaction reads or modifies (writes) a data item,
it attaches its timestamp to the data item to indicate which transaction operated on
the data. Thus to access a data item the tranaction first compares its timestamp with
the timestamp of the data. If the timestamp of the transaction is smaller than the
timestamp associated with the data, then it indicates that the transaction came too late
and the access is not allowed. The transaction is rolled back and is restarted with the
next higher timestamp. In some way a timestamp appears to behave as a lock, but
it does produce some serializable schedule which cannot be produced by two-phase
locking approach [4].
One of the problems with this simple scheme is that it cannot differentiate between a
read lock and a write lock, and so it treats all locks as an exclusive lock. Consequently,
two transactions cannot read a data item simultaneously, which severely restricts
degree of concurrency and highly undesirable. This problem is eliminated in the
Basic Timestumping Scheme.
Basic Timestamping Scheme: This scheme associates two timestamps with each
data item to allow read operations to go concurrently and to resolve read-write and
write-write conflicts. When a transaction wants to read a data item, then it compares
its timestamp with the write timestamp of the data item to check the presence of a
read-write conflict. The transaction is allowed to read the data item if its timestamp
is larger than the write timestamp of the data. Note that this allows two transaction\
to read a data item, which is not possible with only one timestamp. After reading the
data item the transaction overwrites the read timestamp of the data item with the larger
of the two timestamps (data and transaction). The transaction is rolled back if this
condition is not satisfied. Similarly, if a transaction wants to write to a data item, then
it compares its timestamp with the read timestamp of the data item. The transaction
writes to the data item only if its timestamp is larger than the read timestamp of the data
item and overwrites the write timestamp of the data with the larger of the two (data
and transaction). In the case of two consecutive writes by two different transactions,
the Thomas Write Rule (TWR) [4] is used to resolve write-write conflicts.
The timestamping approach, although managed to eliminate the locking and deadlock management costs, restricted the conflict resolution options compared to twophase locking schemes. In addition, it also adds some new overheads which affected
system performance more than locking approaches [ 1 1, I 21. For these reasons, none
of the timestamping schemes made its way into any commercial database systems.
Mixed Approaches
To exploit the dynamic aspects of two-phase locking and the static ordering of timestamping, a number of concurrency conrol mechanisms were developed using a combined approach. One of the main reasons for mixing these two approaches is to
manage efficiently the transaction execution in distributed database systems. The
timestamping approach offers some freedom to nodes of distributed database systems in making conflict resolution decisions with minimum consultation with other
nodes participating in the execution of the transaction. In mixed approach schemes,
locking is used to enforce mutual exclusion among transactions, and timestamps are
used to resolve conflicts. Two such well-known concurrency control mechanisms are
Wound-Wait and Wait-Die [12, 251, which are explained below using transaction T,
as the holder and T j as the requester of the data item.
Wound-Wait (WW)
In Wound-Wait (WW) a conflict is resolved by rolling back a younger (larger timestamp) holder. This is a preemptive algorithm since it rolls-back the holder which might
be under execution or waiting for a data item locked by an older (smaller timestamp)
transaction. It avoids deadlock by not blocking the older requestor. When there is a
conflict. then
[f T3's timestamp > T, 's timestump, then
T3waits for T, to terminate (commit or abort)
else T, is wounded (T3,forces T, to abort)
Wait-Die (WD)
In Wait-Die (WD) action is taken only on the requestor. A requester is rolled back if
it is younger than the holder, otherwise it is blocked. It is a nonpreemptive algorithm
since when a conflict over an entity occurs, it never takes away any resource from the
holder (younger or older) in conflict. It avoids deadlock since it rolls back a younger
requestor only which is capable of precipitating a deadlock.
If TJ's timestamp > Tz's timestamp, then
T , dies (rolled back)
else T7waits for T, to terminate (commit or abort)
Multiversion Approach
The main objective of the multiversion approach is to minimize requester's waiting
time by providing its requested data item [4]. Thus a transaction's data requests
are always immediately satisfied. To achieve immediate data allocation, every write
operation generates a new version of the data. This creates a time series data item
sequence of versions. The generation of this sequence can be illustrated as follows,
where II: represents a data item and its subscript represents the time it was generated.
Thus, 2 1 is created by a write after 2 0 , is~created after z1, and so on. The generation
of the temporal sequence of versions can be illustrated as follows:
w1(21)4 :c1
w2(II::2) 4 :c2
x,L-l + w,(z,)
This generates a time sequence of data item 5 as
'. ,x,>
Suppose a transaction T, request data item :r. The right version (the version which
it would have accessed in a serial execution) of x for T, is present in the sequence.
The task a multiversion scheme is first to identify the version and then reserve it for T,.
The multiversion approach can be implemented with timestamp or with two-phase
Optimistic Concurrency Control Mechanisms
Serialization of concurrent transaction through locking is the most commonly used
concurrency control scheme. It has, however, locking overhead which becomes significant for high contention workload. It becomes unacceptable for a workload with
a high percentage of read operations. Optimistic concurrency control approach tries
to reduce locking overhead by delaying lock operation until conflicting transactions
are ready to commit. They rely on efficiency in the hope that conflicts between
transactions will not occur. Since locks are not used during the execution life of
transactions, the execution is deadlock-free. For these reasons the scheme is called
optimistic concurrency control or certifiers [4, 201.
Optimistic approach uses three phases: (a) read, (b) validate, and (c) write for
executing the transaction.
Read: A transaction reads the desired data item completely unrestricted and save
it in is local cache. The data valuer read is not returned to the user.
Validate: In this phase it is determined that the transaction will not generate an
inconsistent data and the result it returns will be correct.
Write: In this phase the transaction writes modified data items to the database and
makes it available to other transaction if the validation is successful.
The optimistic approach can be implemented through timestamp, locking, or graph
testing [4]. The following example illustrates how the certification (validation) is
performed at the time of commit. Suppose there are two concurrent transactions
T, and Tj which read and write data items. For each active transaction the certifier
maintains two queues to store its read set and write set. Thus, Ti maintains a queue Ri
to store data items it reads and maintains a queue Wi to store data items it writes and
so does T I .When the certifier receives a request for data item x (i.e., ~i (x)or wi(x))
from Ti, it adds x to Ri or to W, depending upon the requested operation. When
the certifier receives a commit operation from Ti, it tests for conflict by performing
Ri n W j , W, n Rj and Wi n Wj with all active transactions. If any one of these
produces an empty set, then the commit request is rejected and Tiis aborted; otherwise
the certifier commits the transaction and removes it from the active transaction queue.
The optimistic scheme does not apply lock; however, it does generate the effect
of two-phase locking with the help of transaction roll back. Although it eliminates
locking overhead but replaces it by roll back overhead, numerous performance investigations suggest that this scheme performs poorly in high contention transaction
workload [4].
5.1.9 Two-Phase Locking for Distributed Database Systems
Two-phase locking mechanisms were developed for centralized database systems, but
they can be effectively applied to serialize distributed transactions as well. However,
because of the different data distribution model, the implementation requires some
modifications. There are three different ways that a two-phase scheme can be applied
to distributed database systems: (a) centralized two-phase locking, (b) primary copy
locking, and (c) distributed two-phase locking.
Centralized Two-Phase Locking: In this scheme, one site (node) is responsible
for managing all locking activities. This means that in the entire distributed database
system only one site has a lock manager. Any lock request from any node is directed to
this site which makes the decision and informs the requesting node. This approach is
also called the Primary Site two-phase algorithm [ 1,241. A number of sites are usually
involved in processing a transaction. One of these sites is called coordinating site,
which is also responsible for sending a node’s locking request for the transaction to the
central locking site. The other sites are called participating sites of that transaction.
The centralized locking site only provides the locking service and does not send the
operations (subtransactions) to participants, which is done by the coordinating site.
In the case of partial and full database replication, the coordinator is responsible for
selecting participating sites and completing updates for global consistency.
Primary Copy Two-Phase Locking: The centralized two-phase scheme suffers
with single point of failure and other performance problems [22, 231. To minimize
and eliminate some of these problems, the locking responsibility is distributed to
multiple sites. Each lock manager is now responsible for a subset of data items. The
node executing a part of the transaction sends lock requests to the appropriate lock
manager. Once a copy of a data item is locked, then, in the case of full or partial
replication, all copies of the data item are implicitly locked. In this a way the locked
copy of the data item serves as the primary copy of the data item.
Distributed Two-Phase Locking: In this approach all nodes can serve as a lock
manager. In the case of database partition, this algorithm degenerates to a centralized
two-phase scheme. The coordinator sends lock request to all participating sites which
are responsible for managing the execution of their part of the transaction. As a result,
the participants do not have to Fend a "lock granted" message back to the coordinator of
the transaction. At the end of execution a participants just sends "End of processing"
message to the coordinator of the transaction. A distributed two-phase locking scheme
was used in System R* [21] and in NonStoop SQL [6,27,28]
This chapter introduced a number of concurrency control mechanisms for database
systems to the readers. A two-phase locking scheme is most commonly used in
centraked as well as distributed database systems and all other schemes remained
as a topic of intensive investigation. The objective of the chapter is to encourage the
readers to analyze the applicability of these schemes for mobile database systems. A
detailed analysis of their applicability to mobile systems is presented in Chapter 6.
Intuitively, because of their high communication and locking overheads, they would
not perform satisfactorily in mobile database systems. The overhead generated by
them cannot be handled by mobile databases, which are highly resource-constrained
1. Explain the role of concurrency control mechanisms in managing serializable
execution of concurrent transactions.
2. Prove that if two-phase policy is violated then it may not be possible to serialize
the execution of concurrent transactions.
3. What is phantom problem‘? How does it arise? Why does it arise only i n
dynamic databases? Give a real-life example of phantom problem and develop
a scheme to handle it efficiently. Identify the phantom record in your example.
4. Do you think a lock conversion may give rise to phantom problem? Explain
your answer.
5. Consider developing your own concurrency control mechanism based on dynamic attributes of transactions. (Hint: Try to integrate multiple locking-based
concurrency control mechanisms.)
1. P. A. Alsberg and J. D. Day, “A Principle for Resilient Sharing of Distributed
Resources,” in Proceedings of 2nd International Conference on Software Engineering, 1976.
2. R. Balter, P. Berard, and P. Decitre, “Why Control of Concurrency Level in
Distributed Systems is More Fundamental than Deadlock Management,”in Proceedings ofACM PODC, Ottawa, Canada, Aug. 1982.
3. A. Burger and V. Kumar, “PRABHA - A Distributed Concurrency Control Algorithm,“ ACMAnnual Computer Science Conference, 1990.
4. P. A. Bernstein, V. Hadzilacos, and N. Goodman, Concurrency Control and Recovery in Database Systems. Addison-Wesley, Reading, MA, 1987.
5. P. A. Bernstein, J. B. Rothnie, N. Goodman Jr., and C. H. Papadimitriou, “The
Concurrency Control Mechanisms of SDD- 1: A System for Distributed Databases
(The Fully Redundant Case),“IEEE Trans. on Software Engineering, Vol. 4, No.
3, May 1978.
6. A. Borr, “High Performance SQL Through Low-Level System Integration,” in
Proceedings of ACM SIGMOD Conference, June 1988.
7. K. P. Ec,waran, J. N. Gray, R. A. Lorie, and 1. L. Traiger, “The Notion of Consistency and Predicate Locks in a Database System,“ Communications of the ACM,
Vol. 19, No. 11, Nov. 1976.
8. P. Franaszek and J. T. Robinson, “Limitations of Concurrency in Transaction
Processing,“ ACM Transactions on Database Systems, Vol. 10, No. I , March
9. J. N. Gray, and A. Reuter, Transaction Processing Concepts and Techniques,
Morgan and Kaufmann, San Francisco, 1993.
10. M. Hsu and B. Zhang, “Performance Evaluation of Cautious Waiting,“ ACM
Transactions on Database Systems, Vol. 17, No. 3, 1992.
11 I
11. V. Kumar “Performance Comparison of Some Database Concurrency Control
Mechanisms Based on Two-Phase Locking, Timestamping and Mixed Approach,“
Informution Sciences, Vol. 5 I , No. 3, 1990.
12. V. Kumar, Peqormance of Concurrency Control Mechanisms in Database Systems, Prentice Hall, Engleewood Cliff, NJ, 1996.
13. V. Kumar and N. Gaddipati, “An Efficient CCM Krishna for High Contention
Environment and its Performance Comparison with WDL,“ Data and Knowledge
Engineering, Vol. 34, 2000.
14. V. Kumar, “KRISHNA - An efficient CCM Based on Dynamic Attributes of
Transactions and Its Performance,“Data and Knowledge Engineering. Vol. 21,
15. V. Kumar and M. Hsu. “A Superior Two-Phase Locking Algorithm and Its Performance,” Information Sciences, Vol. 54, No. 1, 2., 1991.
16. V. Kumar, “Concurrent Operations on Extendible Hashing and Its Performance,”
Communications of the ACM, Vol. 33, No. 6, June 1990.
17. V. Kumar, “Performance Comparison of Some Database Concurrency Control
Mechanisms Based on Two-Phase Locking, Timestamping and Mixed Approach”.
Information Sciences, Vol. 51, No. 3, 1990.
1 8. V. Kumar, “Concurrency on extendible Hashing“,Information Processing Letters,
Vol. 30, No. 6, April 1989.
19. V. Kumar, “Behavior of Read:Write Ratio and Read-only Transactions,” Information Systems, Vol. 14, No. l., 1989.
20. H. T. Kung and John T. Robinson. “On Optimistic Methods of Concurrency
Control,“ ACM Transaction of Database Systems, Vol. 6, No. 2. 1981.
2 1 . C. Mohan, B. Lindsey, and R. Obermarck, “Transaction Management in R* Disri buted Database Management System,“ACM Transactions on Dutubase Systems,
Vol. 1 1 , No. 4, December 1986.
22. T. Ozsu, “Performance Comparison of Distributed vs Centralized Locking Algorithms in Distributed Database Systems,” in Proceedings 5th Internationul
Conference on Distributed Computing Systems, May 1985.
23. T. M. Koon and T. Ozsu, “Performance Comparison of Resilient Concurrency
Control Algorithms for Distributed Databases,’’in Proceedings 2nd Int. Conference on Data Engineering, February 1986.
24. T. Ozsu and P. Valduriez. Principles of Distributed Database Systems. Prentice
Hall, Engleewood Cliffs, NJ, 1999.
25. D. J. Rosencrantz, R. E. Sterns, and P. M. Lewis, “System Level Concurrency
Control for Distributed Database Systems,” ACM Transactions on Database Systems, Vol. 3, No. 2, June 1978.
26. A. Silberschatz, P. Galvin, and G. Gagne. Operating System Concepts, John
Wiley & Sons, New York; 2002.
27. “TheTandem Database Group. Nonstop SQL -A Distributed High-Performance,
High- Availability Implementation of SQL,” in Proceedings International Workshop on High Pegormance Transaction Systems, September 1987.
28. “The Tandem Performance Group. A benchmark of Nonstop SQL on the Debit
Credit Transaction,“ in Proceedings ACM SIGMOD Conference on Munugement
ofDatu, June 1988.
Data Processing
and Mobilitv
The objective of this chapter is to discuss the role of personal and terminal mobility
in emerging information processing discipline. This discipline has been referred to as
Mobile Computing, Ubiquitous Computing, Nomad Computing,Anytime Anywhere
Computing, Pervasive Computing, and so on. With time the scope of the discipline
may change and new terms are likely to be added to identify the change. The chapter introduces geographical mobility of processing units and analyzes its effect on
transaction processing.
In recent years the work discipline has become highly dynamic with the introduction of
“mobility in action” aspect. The concept “continuous connectivity in mobile space”
allows the workforce to actively perform necessary tasks independent of its status
(mobile or static). This is especially true for information management activities such
as sending and receiving e-mails, web browsing, internet shopping, and so on. The
personal and terminal mobility have become indispensable components of the highly
efficient workforce. It has become a common approach to turn any location and
situation a job office. Thus a manager, while traveling in a car or on a plane or sitting
on a beach, can create his job office on the spot and can access necessary information
to complete his tasks. It is quite obvious that this type of work environment provides
increased productivity because the traveling time becomes available for completing
the tasks in hand. For example, the manager on the plane can supervise the activities
of his employees, can evaluate their performance, can decide their salary raises and
finalize the next leg of his travel plan, and so on.
The recent advances in wireless technology has made it possible to achieve “continuous connectivity in mobile space.“ The technology has managed to provide the
convenience of cell phone, wireless web browsing, and use of e-mail facilities. Wireless networks are widely used within a business environment to connect laptops and
other portables and has significantly increased the functionality of mobile gadgets.
Laptops can now easily store and process large databases which were possible only
by heavyweight stationary servers. The power and capacity of PDAs are continuously increasing, and they can perform a number of database tasks quite efficiently.
As a result, more and more users have begun using wireless portable devices not
only to communicate with each other but also to manage their day-to-day activities
and information. These changing ways for interacting with the informatiofi space
has formatted the business world and identified it with the name “Mobile Commerce
(M-Commerce). The following examples illustrate the existing power of mobility in
action concept [ 11.
In busy city traffic, carpoolers usually end up spending a significant amount
of time on the road. Instead of waiting, they can use their mobile gadget to
connect to their corporate database servers and begin their work. This facility
will minimize the negative effect of communication delay on productivity.
Automobiles of the future can use many mobility aware applications to access
information like news, music, road conditions, etc. Additionally, cars driving
in the same area can build an ad hoc network for fast information exchange
or to keep a safe distance from each other. A car can study the current road
condition and transmit this information to another car coming that way. In the
case of an emergency, the cars will have the capability to automatically call
an ambulance or police. Thus a wireless notification system can be developed
which will automatically notify agencies such as police, hospital, etc., during
the occurrence of life-threatening events. A system called NOW (Notijication
on Wireless)is being developed at the University of Missouri-Kansas City.
Users can access services depending on their actual location. For example, a
user might query the local wireless network to find the whereabouts of a nearby
restaurant, or his current geographical location, or a local network itself might
advertise such data which the user can access similar to listening music on a
particular channel.
In electronic commerce applications, such as auctions, it is expected that a
typical auction might bring together millions of interested parties. Updates
based on bids made must be disseminated promptly and consistently. A mobile
system may use broadcast facility to transmit the current state of the auction
while allowing the client to communicate their updates using low bandwidth
uplink channels. Broadcast based data dissemination is likely to be a major
mode of information transfer in mobile computing and wireless environments.
The above set of examples illustrates the importance of mobile database systems to
manage real-life information processing activities. Mobile systems, however, cannot
function without the support of conventional systems. It is, therefore, important to
investigate how mobile discipline affects conventional data processing approaches
for understanding their seamless integration 131.
In conventional database systems there is one common characteristic: All components, especially the processing units, are stationary. A user must go to a fixed
location to use the system. In distributed systems, depending upon the type of data,
distribution data may migrate from one node to another, but this migration is deterministic; that is, data move from one fixed source to another fixed destination. Such
data migration does not satisfy any mobility criteria.
The integration of geographical mobility is an excellent way to efficiently salvage
time wasted in traveling. However, it gives rise to a number of problems related to the
maintenance of ACID properties in the presence of personal and terminal mobility.
A number of these problems are addressed in the following sections.
The ACID properties of a transaction must be maintained in all data management activities. Concurrency control mechanisms and database recovery schemes
make sure that ACID is maintained. In mobile and wireless platform the nature of
data processing remains the same, but the situations under which data are processed
may change. It is, therefore, important to understand the effect of mobility on data
distribution and ACID properties of transactions.
6.2.1 Data Categorization
The data distribution in conventional distributed database systems can be done in three
ways: (a) partitioned, (b) partial replication, and (c) full replication. The presence
of processor mobility adds another dimension to conventional data distribution. It
introduces the concept of Location-Dependent Data (LDD).
Location-Dependent Data (LDD): It is a class of data where datavalues are tightly
linked to specific geographical location. There is 1 : 1 mapping between the data value
set and the region it serves. For example, City Tax data value is functionally dependent
on the city’s tax policy. It is possible that all cities may use the same city tax schema,
but each city will map to a unique instance of the schema. Some other example
of LDD are zip code, telephone area code, etc. In contrast, some classes of data
have no association with any location-for example, Social Security Number (SSN),
street names, rain fall, snow fall, etc. The value of SSN does not identify any specific
location such as a street name. The same street name may exist in Boston or in Seattle
or in Kansas City. These are called Location-Independent Data, and the conventional
data processing approach interprets all data as location-independent data.
Location Dependent Query: LDD gives rise to Location-Dependent Query and
Location-Aware Query. A location-dependent query needs LDD for computing the
result. For example, What is the distance from the airport to here? is a locationdependent query because the value of the distance depends on the geographical location of the mobile unit which initiated the query. If the coordinates of the location
“here“ is not known, then the query cannot be processed. Consider the situation when
a person is driving to the airport to catch his flight. He is running late, and so after
every 5 minutes he repeats the query How far is the airport now? Each answer to
this identical query will be different but correct because the geographical location of
“here“ is continuously changing. A similar situation arises in processing the query
Where am I? I will continuously ask this query after driving randomly to some location and will have different correct answers. (I may get completely lost but that is a
different matter altogether!). This kind of situation exists only when the geographical
coordinates of the origin of query continuously change with time. This is a common
situation in every day life. If a traveler initiates a query What is the sales tax of this
city? while passing through a city, then the answer must be related to the current city
and not to the next city where he arrives soon after initiating the query. A similar situation arises in listening to a radio station while traveling. When the traveler crosses
the broadcast boundary, the same frequency tunes to a different radio station and the
broadcast program changes completely,
In processing a location-dependent query, the necessary LDD and the geographical
location of the origin of the query must be known. This requires that the system must
map the location with the data to obtain correct LDD. A number of service providers
have location discovery facility which can be used to access LDD.
Location-Aware Query: This type of query includes reference to a particular location either by name or by suitable geographical coordinates. For example, What is
the distance between Dallas and Kansas City? is a location-aware query because it
refers to locations Kansas City and Dallas. The answer to this query or any location
aware query does not depend on the geographical location of the query; as a result,
the mobility does not affect its processing.
Location Dependent Data Distribution
The I :1 mapping between data and its geographical location restricts the three data
distribution approaches. The horizontal fragmentation and vertical fragmentation of
a relational database must include the location information implicitly or explicitly.
The partition of database, however, becomes easier because the decision is solely
based on the location parameter. The concept of data region is helpful to understand
the distribution of database partitions in mobile databases.
Definition 6.1 A data region is a geographical region or a geographical cell, and
every geographical point of this region satisfies 1:I mapping with data.
Pi - A partition of Kansas City database
A Cell -
Fig. 6.1 Database partition for LDD.
Figure 6.1 illustrates data distribution for data partition scheme. It assumes Kansas
City as a data region for city sales tax. The entire data region is enclosed in a cell.
Every location of Kansas City satisfies 1 :1 mapping between city tax value and the
location. The entire Kansas City database is partitioned into subdivisions identified
by PI through Pg. All subdivisions map to the same city sales tax; as a result, all
subdivisions charge the same city tax. If every subdivision maintains its own database,
then at each subdivision a database partition can be stored. A mobile unit which moves
among subdivisions will see the same one consistent value of a data item.
A hotel chain or franchise can be used to demonstrate the problem of data
replication and its consistency for mobile databases. A particular hotel has a
number of branches across the nation. Each branch offers identical services;
however, its room rent, policy, facilities, etc., would depend on the branch
location. Thus, the same-size suite may cost more in Dallas than in Kansas
City. The data consistency constraints in Kansas City might be different from
those in Dallas, because of local taxes and environment policies. Each branch
may share the same schema but their instantiations (values for the data) may
In a partial replication approach the same partition can be replicated at more than
one subdivision. For example, at subdivision 1 and subdivision 2, PI and P.Lcan
be replicated without affecting the consistency. In a full replication, also the entire
database can be replicated and used at all subdivisions in a consistent manner.
Data region 1
Fig. 6.2 Database replication restriction.
The situation does not change if the data region is covered by multiple cells. A
mobile unit can move from one subdivision to another and use the same data item in
both subdivisions. However, the situation changes when a cell covers two or more
data regions as shown in Figure 6.2. Data of one region cannot be replicated at another
region. For example, the sales tax rate of Kansas City (region 1) cannot be replicated
at Springfield (region 2). This constraint requires that a location-dependent query
in Springfield must be processed in Springfield before the client enters Kansas City.
This restriction also affects mobile data caching. A mobile unit must clear its cache
before entering to another data region for maintaining global consistency.
Since the distribution of LDD is dependent on geographical locations, its distribution is defined as spatial distribution to distinguish it from the conventional distribution which is called a temporal distribution. In spatial distribution and in temporal
distribution spatial replication and temporal replication, respectively; are used.
Definition 6.2 Spatial Replication refers to copies of data objects which may have
different correct data values at any point in time. Each value is correct within a given
location area. One of these copies is called a Spatial Replica.
Definition 6.3 Temporal Replication refers to copies of data objectsall of which have
only one consistent data value at any point in time. One of these copies is called a
Temporal Replica.
The temporal distribution mainly considers local availability of data and the cost
of communication, but for spatial distribution the geographical location must also be
included. The identification of data as spatial and temporal affects the definition of
Effect of Mobility on Atomicity: The property of atomicity guarantees that partial
results of a transaction do not exist in the database. If a transaction fails to commit, then
all its effects are removedfrom the database. The mobility does not alter the definition
of atomicity but makes its enforcement quite difficult. Transaction execution log is
required for implementing atomicity. In a conventional system the log is stored at
the server and is easily available. In a mobile system, conventional logging approach
does not work satisfactorily because a mobile unit gets connected and disconnected to
several servers when it is mobile. There are a number of ways to manage a transaction
log in mobile systems; this is discussed in the recovery section.
Effect of Mobility on Consistency: In a centralized or distributed environment
there is only one correct value for each data object. The term mutual consistency is
used to indicate that all values of the same data item converge to this one correct value
[ 2 ] .A replicated database is said to be in a mutually consistent state if all copies have
the exact same value [ 2 ] . In addition, a database is said to be in a consistent state if
all integrity constraints identified for the database are followed [2].
In a mobile database system the presence of location-dependent data defines two
types of consistency: Spatial Consistency and Temporal Consistency.
Definition 6.4 Spatial consistency indicates that all data item values of a spatial
replication are associated with one and only one data region, and they satisfi consistency constraints as defined by the region. Thus there is I : 1 mapping between data
v d ue and the region it serves.
Every mobile unit that initiates transactions in a region must get a consistent view
of the region and the database must guarantee that the effect of the execution of the
transactions is durable in that region. To achieve this state, the region must satisfy
temporal consistency as well.
Definition 6.5 Temporal consistency indicates that all data item values must satisJLa
given set of integrity constraints. A database is temporally consistent if all temporal
replicas (replication of data items at multiple sites) of a data item have the mme
Effect of Mobility on Isolation: Transaction isolation ensures that a transaction
does not interfere with the execution of another transaction. Isolation is normally
enforced by some concurrency control mechanism. As with atomicity, isolation is
needed to ensure that consistency is preserved.
In mobile database systems a mobile unit may visit multiple data regions and
process location-dependent data. The important thing is to ensure that execution
fragments satisfy isolation at the execution fragment level. It will do so under some
concurrency control mechanism which must recognize the relationship between a data
item. The mechanism must enforce isolation in each region separately but achieve
isolation for the entire transaction. This is quite different from a conventional distributed database system which, does not recognize spatial replication and thus does
not enforce regional isolation.
Effect of Mobility on Durability: Durability guarantees the persistence of committed data items in the database. In mobile database systems the durability is regional
as well as global. For spatial replicas and temporal replicas; regional durability and
global durability, respectively are enforced.
Effect of Mobility on Commit: Transaction commitment is not affected by mobility; however, because of the presence of location-dependent data, a location commit
is defined. A location commit binds a transaction commit to a region. For example, a department manager initiates the following transaction on his mobile unit:
Reserve 5 seats in a vegetarian restaurant located I mile from here. . This is a
location-dependent update transaction, and it must be processed in the region where
the restaurant is located. The confirmation must be sent back as fast as possible to
the manager, which becomes necessary if the manager is waiting for the confirmation. The database server responsible for processing this transaction must first map
the location of the query and the location of the restaurant and then access the correct database for making the reservation. The entire execution remains confined to
the region until the transaction commits. Thus the process of commit is identical
to the conventional notion of transaction commit; however, the requirements for the
commit are different. It is called location-dependent commit to differentiate it from
conventional notion of commit.
Definition 6.6 An execution,frugment, et, satisfies a Location-Dependent Commit
iff the fragment operations terminate with u commit operation and a location to dutu
mupping exists. Thus all operutions in e, operate on spatial replicas dejned on the
location identGed by locution mapping. The commit is thus associated with a unique
location I,.
Effect of Connectivity on Transaction Processing
In a mobile environment an MU can process its workload in a continuoudy connected
mode or in disconnected mode or in an intermittent connected mode.
Connectivitymode: In this mode an MU is continuously connected to the database
server. It has the option of caching required data for improving performance or can
request data from the server any time during transaction processing. If necessary, it
can enter into doze mode to save power and becomes active again. However, this
mode is expensive to maintain and is not necessary for processing users workload.
Disconnected mode: In this mode an MU voluntarily disconnects from the server
after refreshing the cache and continues to process workload locally. At a fixed
time it connects and sends its entire cache to the server using wireless or wired link.
The server install the contents of the cache such a way that global consistency is
intermittent connected: This mode is similar to the disconnected mode, but here
the MU can be disconnected any time by the system or voluntarily by the user.
The disconnection by system may be due to lack of channel, low battery, security,
etc. The user may disconnect the MU to save power or to process data locally, or
no communication with the server is required for some time. Unlike disconnected
mode, intermittent mode does not have any fixed time for connecting and disconnecting an MU.
This type of connectivity is useful for agents dealing with customers-for example,
insurance agents, UPS or FedEx, postal delivery, etc. For postal delivery, the entire
day’s delivery can be defined as a long workflow. The agent delivers a packet to a
house and locally updates the cached database on the mobile device. At the end of the
day or at a prescribed time the agent connects and ships the entire cache to the server
with through a wired or wireless channel. It is possible that the agent may connect
to server to report the status of the high priority shipment. The stock evaluator in
a supermarket also works in a similar manner. After recording the stock level the
agent connects the server for updating the main database. Connection on demand
is also a form of intermittent connectivity because a user’s need for data is usually
The database consistency in disconnected or intermittently connected mode is
hard to define and maintain. This becomes relatively difficult in an e-commerce or
m-commerce environment, which can be explained with a simple example. Consider
a company called Pani’ Inc., sells water purifier aggressively. Two agents Kumar
and Prasad go house to house in a subdivision, demonstrate the water filter, and try
to win household’s business. Suppose the company has 100 water purifier units in
the warehouse and wants to sell them aggressively. Pani Inc. does not want to take a
chance, so it asks each agent to download 100 units on their laptop and to sell them
in a day. In this way if each agent sells 50 units, then the job is done. Now suppose
with a bit of luck and with some persuasion, Kumar and Prasad both sell 100 units
without being aware of each others success. This pushes the database into a real mess.
Pani Inc. handles the situation using a “back order” scheme and reduction in the cost
‘Pani is a Hindi word which means water
of water purifier. So in this situation, how can we define the consistent state of the
database? One way could be “existing inventory +back order,“ but this is quite risky.
If Pani Inc. could not supply all back orders within the promised time, then some
orders may have to be rolled back; as a result, it may be difficult to maintain ACID
Managing ACID transactions processing in the connected state is easy and can
be handled in a conventional manner. However, their processing in the disconnected
and intermittent connected modes requires new caching consistency approaches, new
locking approaches, new commit protocol, new rollback and abort schemes, and most
important a new transaction model or new way of processing ACID transactions.
This chapter discussed the relationship between mobility and transaction processing.
A clear understanding of this relationship is necessary for the development of mobile
transaction model and its management. Three types of connectivity modes and their
effect on database consistency and transaction processing were explained. In the next
chapter, various ways of executing ACID transactions on mobile database system and
mobile transaction models are presented.
1. Define processor mobility from data management and transaction execution
viewpoints. Identify the set of problems exclusive to each.
2. In the presence of processor mobility, data and transactions acquire exclusive
properties. Identify and explain these properties. How do they affect database
query processing?
3. Explain the difference between location-dependent, location-independent, and
location-free queries. Give at least two real-life examples of each of them.
4. Explain the problems of location-dependent data distribution. How do they
affect database integrity and consistency. Are they similar to problems of data
distribution in federated and multidatabase systems? Explain your answer.
5. Give your own thoughts on the effect of mobility on database consistency,
database integrity, database distribution, and transaction execution.
1. D. Barbara, “Mobile Computing and Databases - A survey,“ IEEE Trunsactions
on Knowledge and Data Engineering, Vol. 11, No. 1, January 1999.
2 . T. Ozsu and P. Valduriez. Principles of Distributed Database Systems. Prentice
Hall, Engleewood Cliffs, NJ, 1999.
3. E. Pitroura and 8.Bhargava, “Revising Transaction Concepts for Mobile Computing,“ in Proceedings ofworkshop on Mobile Computing Systems andApplication,
Transaction Management
in Mobile Database
This chapter deals with management of transactions in mobile database systems.
It presents a reference architecture of the Mobile Database System (MDS), which
is built on PCS (Personal Communication System) and GSM (Global System for
Mobile Communication) to build the foundation for transaction management. It was
recognized in some of the earlier chapters that the conventional ACID transaction
model was unable to satisfactorily manage mobile data processing tasks. Some of the
important reasons were: the presence of handoff, which is unpredictable; the presence
of doze mode, disconnected mode, and forced disconnection; the lack of necessary
resources such as memory and wireless channels; the presence of location-dependent
data; etc. It was recognized that to manage data processing in the presence of these
issues, a more powerful ACID transaction execution model that can handle mobility
during data processing was highly desirable. A number of such execution models
were developed, and a few of them are discussed in the chapter. These execution
models, unfortunately, are unable to handle location-dependent data processing; for
this reason, mobile transaction models which included such processing capability as
a part of the structure were developed. A few mobile transaction models are discussed
in this chapter.
Concurrency control mechanisms are essential for managing concurrent transactions. Not much work has been done in this area, and the chapters include some
discussion on this topic. It also discusses transaction commitment issues and presents
a protocol.
The chapter also discusses in detail the recovery issues and presents some useful
information on mobile database recovery schemes.
The topics covered in this chapter are highly research-oriented; and although a
significant number of schemes have been proposed, none has become a commonly
accepted method. The chapter, therefore, identifies and present the original scheme
as describes by the author(s) of the reports. The discussion clearly indicates the
incremental understanding of mobile data processing and thinking trends. The chapter
begins with a reference Mobile Database System
A Mobile Database System (MDS) provides full database and mobile communication
functionalities. It allows a mobile user to initiate transactions from anywhere and at
anytime and guarantees their consistency preserving execution. In the case of any kind
of failure (transaction, system, and media), MDS guarantees database recovery. The
reference architecture shown in Figure 7.1 provides the following essential properties.
Geographical mobility: Clients are able to move around in the geographical
space without affecting their processing capability and continuous connectivity.
Connection and Disconnection: A client is able to disconnect and reconnect
with any server at any time.
Data processing capability: Clients have some and servers have full database
processing capability.
Wireless communication: A client can communicate with the server and with
any other client through a wireless network.
Transparency: Since the mobility in data processing is introduced through
cellular architecture, the data processing functions of clients does not affect the
cellular communication.
Scalability: Any time, a client can be added to, or an existing client can be
deleted, from the network.
An MDS is a distributed multidatabase client/server system based on PCS or GSM.
There are some differences in GSM and PCS architecture, however, they do not affect
MDS. Database functionality is provided by a set of DBSs (database servers) which
are incorporated without affecting any aspect of the generic mobile network.
GSM and PCS systems were discussed in Chapter 2. The components of these
systems are in fact special-purpose computers responsible for connecting users with
the system. The reference architecture of MDS is, therefore, described in terms of
general-purpose computers such as personal computers, workstations, PDAs, cell
phones, etc.
In MDS a set of general-purpose computers are interconnected through a highspeed wired network. These computers are categorized into Fixed Hosts (FH) and
Base Stations (BS) or Mobile Support Stations (MSS).FHs are not fitted with transceivers,
so they do not communicate with mobile units. One or more BSs are connected with
a Base Station Controller or Cell Site Controller (BSC) [25, 261, which coordinates
b e d Host1
Wireless connection
Wired connection
fig. 7.7 Reference architecture of a mobile database Ssystem.
the operation of BSs using its own stored software programs when commanded by the
MSC (Mobile Switching Center). To coordinate with database servers, some additional simple data processing capability is incorporated in BSs. Unrestricted mobility
in PCS and GSM is supported by wireless link between BS and mobile units such
a5 PDA (Personal Digital Assistants), laptop, cell phones, etc. These mobile gadgets
are referred to as Mobile Hosts (MH) or Mobile Units (MU) [25, 261. BSs are fitted
with transceivers and communicate with MUs through wireless channels. Each BS
serves one cell whose size depends on the power of its BS. In reality a high power
BS is not used because of a number of factors; rather, a number of low-power BSs
are deployed for managing movement of MUs.
To incorporate full database functionality, it is necessary to incorporate Database
Servers (DBSs) to PCS or GSM. They can be installed (a) at BSs or (b) at FHs. There
are, however, a number of problems with this setup. A BS or FH are switches, and they
have specific tasks to perform, which does not include database functions. In order
to add database functions, the entire architecture of a BS (hardware and software)
may have to be revised, which would be unacceptable from mobile communication
viewpoint. In addition to this, the setup will not be modular and scalable; a5 a result,
any change or enhancement in database components will interfere with data and voice
communication. For these reasons, DBSs are connected to the mobile system through
wired line as separate nodes, as shown in Figure 7.1. Each DBS can be reached by
any BS or FH, and new DBSs can be connected and old ones can be taken out from
the network without affecting mobile communication. The set of MSCs and PSTN
connects the MDS to the outside world.
A DBS communicates with a MU only through BSs. A mobile user remains
connected on the average for 2 to 4 hours during a day, and at all other times, it must
save the battery power. To conserve the power, a mobile unit can be switched to stay
in (a) powered off mode (not actively listening to the BS) or (b) idle mode (doze
mode - not communicating but continuously listening to the BS) or (c) active mode
(communicating with other party, processing data, etc.) The unit can move from one
cell to another in any of these modes, for example, a driver can switch its cell phone
to save battery power while driving and may cross many cell boundaries. The total
coverage area of MDS is the sum of all its cell areas, i.e., {C, + C, + . . + CTL}.
discussed in Chapter 2, the mobile unit encounters handoff only in active mode.
The MDS has multiple DBSs, and a database can be distributed by partition or by
partial or fully replication. An MDS can either be a federated or a multi-database
system. Spatial replications must follow the constraints of location-dependent and
location-free data.
Data region 3
Fig. 7.2 Different replication types.
Figure 7.2 illustrates how database is distributed among DBSs and MUs. Locationfree data-for example, D1, D2, and D4-can be replicated at all regions and have
the same values. This is one of the reasons that temporal replicas can be processed
using the read-one write-all version of the distributed two-phase locking concurrency
control mechanism, which is not relevant for spatial replication. Location-dependent
data-for example, D3-can also be replicated to all regions but each region will have
different correct value. Three basic types of replications of the database are shown
in this figure: (a) “no replication,” (b) “traditional distributed replication” (temporal
replication), and (c) “location dependent replication“ (spatial replication). Data object
0 4 has no replication, and data objects D1 and 0 2 are traditional replicas which are
copied to data regions 1 and 2. The distributed replicas are copies of each other,
which may have different values temporarily but there is only one one correct value.
The location-dependent data 0 3 has multiple copies and multiple correct values. The
correct value is determined by location. It is replicated at all three regions. Each region
has one correct value for 0 3 , and it may also have temporal replicas in that region. The
value of 0 3 which exists at the BS in data region 3 is replicated at a MU, but it has the
same value as that at the DBS. This is an example of temporal replication of locationdependent data. For example, information about phone numbers is spatially replicated
where the data region granularity is associated with local phone company domains.
Hotel information could have a data region granularity associated with postal codes
(zip codes). Each data object uniquely determines the type of replication (none,
temporal, spatial) and the data cell granularity (universe, zip code, metropolitan area
as defined by counties).
Table 7.1 Summary of data replication
Correct Values
One per time
One per location and time
Table 7.1 summarizes the differences between the three types of data replication.
Notice that replicas at a cache at a MU are really temporal replicas, i.e., there may
be temporal replicas of spatial replicas (Object 0 3 in Figure 7.2). That is, within a
given area there may be temporal replicas of location dependent data. For example,
a MU could hoard a temporal copy of hotel information for Kansas City. This would
allow a traveler to leisurely examine this location dependent data while disconnected.
Mobility has no effect on temporal replication but does on spatial replication. This
means that as an MU moves from one data region to another, different values from
the spatial replicas may be needed for processing queries.
A distributed database systems utilizes maximum parallelism in processing the workload to improve system performance. It implements parallel processing by fragmenting a transaction into a number of subtransactions which are then executed at multiple
nodes. The entire execution requires a software module called a coordinator, which
manages the set of activities leading to the termination of the transaction. There are
three main ways to implement a coordinator: (a) centralized, (b) partially replicated
and (c) totally replicated. In the centralized approach one of the nodes of the distributed database system servers as a coordinator; in the partially replicated approach,
a subset of nodes serve as a coordinator; and in a fully replicated system all nodes
serve as a coordinator. In MDS, because of resource limitations, only the centralized
approach seems feasible.
Identification of Coordinator in MDS
In MDS the identification of coordinator nodes is not that clear cut. A coordinator
must have (a) direct and continuous communication with other nodes, (b) theoretically
unlimited and continuous power and large storage space, and (c) high reliability and
availability. Unlike conventional distributed database systems, there are several types
of processing nodes in MDS, but only some can play the role of a coordinator as
explained below:
MU: An MU cannot provide continuous connectivity because it is subjected
to unpredictable hundoffs, it has limited storage capacity and power supply
source, and it is a personal resource of a user which can be taken out of the
network at any time. As a result, a MU cannot serve as a coordinator.
DBS: A DBS is continuously available and has sufficient storage capacity. It,
however, has no direct communication with other nodes (DBSs and MUs) and
are not fitted with transceivers for wireless communication. As a result, a DBS
cannot serve as a coordinator.
FH: An FH is equipped with everything except transceivers. As a result, it cannot communicate with mobile devices, which makes it unfit to be a coordinator.
MSC: An MSC seems to satisfy all the requirements of a coordinator. However,
it has to use the services of a BS to reach a mobile unit. So this may not serve
as an efficient coordinator.
BS: A BS satisfies all the requirements of a coordinator. Assigning it additional
coordinator responsibility would not overload it. As a result, a BS is the most
suitable node to serve as a coordinator.
Transaction Processing in MDS
A transaction in MDS can be initiated from a DBS or from a MU or from both. It
can be processed entirely at the MU where it was initiated or entirely at the DBS, or
a combination of the two. If it is processed entirely at one node (origin node or any
other), then the coordinator plays only a minor role in the execution and commitment
of the transaction. When there are more than one nodes involved in the execution,
then the following situations may arise:
Origin at MU: Three processing scenarios are possible when a transaction
originates at an MU: (a) The transaction executes at the MU and at a set of
DBSs and the final result is sent to the MU, (b) the transaction is processed
only at a set of DBSs and the final result goes to the MU, and (c) the transaction
is processed only at the MU. It is important to note that no other MUs should
be involved in the execution of this transaction because (a) an MU is a personal
processing resource of a client which can be disconnected or turned off by its
owner any time and (b) the owner of the MU may not like to share the resource
with workload other than his own. The final result goes to the MU which
initiates the transaction.
Origin at DBS: A transaction originates at a DBS and executes at a number of
DBSs. The final result goes to the DBS, which initiates the transaction.
When an MU initiates a transaction, it checks to see if the transaction can be
entirely executed locally (at the MU). In this case the MU executes and commits the
transaction using its cached data. At the end of commit, the MU sends transaction
updates to DBSs for installing them to the database and sends the results to the user.
If it cannot be entirely executed at MU, then there are two options:
Transfer required data items from DBSs to MU: The MU identifies the set of
data it requires to process the transaction. It communicates with its BS, which
reaches DBSs and moves these data items to an MU cache. The MU executes
and commits the transaction and sends the final results to the user. It also
sends the updates through its BS to DBSs for installing them to the database.
This scheme does not require the services of the coordinator but generates a
significant amount of communication overhead.
Distribute transaction to a set of nodes: The MU divides the transaction
into a number of subtransactions. It keeps the subtransactions it can execute;
and with help of the coordinator, it distributes the rest of them to a subset of
DBSs for execution. The current BS of the MU becomes the coordinator of
this transaction and manages the entire execution leading either to a commit
or abort. This scheme generates comparatively less communication overhead
and database update cost.
The movement of the MU makes the job of coordinator difficult which requires coordinating execution and movement of the MU correctly. With mobility the following
processing scenarios are possible:
MU does not move: A transaction arrives and completes its processing entirely
at the MU. The MU does not move during the execution of the transaction. This
is a case of no movement of any kind and is similar to conventional centralized
data processing.
MU moves: A transaction arrives and entirely completes its execution at the
MU. Required data items are moved here from other nodes. During transaction
execution the MU moves to different cells. This type of execution is called
“local atomic” which is quite common in mobile computing. Traveling salesmen usually like to process all orders locally for efficiency and for minimizing
message communication overhead.
Distributed processing and MU moves: A transaction originates at a MU and
is fragmented. The subtransactions are distributed among the MU and a set
of DBSs. A coordinator is identified which manages the execution. The MU
moves to different cells during transaction execution.
The service of a coordinator to a MU must be continuously available during the
execution of a transaction. This link may be broken when the MU crosses the current
cell boundary and enters a different cell. The link can be maintained in two ways:
Static method: When a transaction originates at a MU, then the BS of this
MU becomes the coordinator of the transaction and remains the coordinator
until the transaction commits. The MU may continue to migrate from one
cell to another while processing its subtransaction but the coordinator does not
change. This scheme is shown in Figure 7.3a. The MU moves from cell C1
to C2 with its subtransaction e, leaving behind the coordinator at BS1, which
continues to manage the execution of e, with the help of BS2.
It is the responsibility of the MU to inform the new BS identity of its coordinator.
This can be done when the MU registers with the new BS which communicates
with the coordinator once it knows its identity. The problem with this simple
method is that the coordinator and the MU each may have to go through a
number of BSs to update each other. This makes transaction commit and
logging quite complex, as discussed later in this book.
(a) Static scheme: Coordinator does not change
(b) Dynamic scheme. Coordinator changes
Fig. 7.3 Change of coordinators due to mobility.
Dynamic method: In this method the role of coordinator moves with MU.
For example, as shown in Figure 7.3b, when MU moves to cell C2, its base
station (BS2) becomes the coordinator of the transaction being executed by
the MU. Since a transaction is being processed by multiple DBSs, they must
know when a new coordinator is assigned to an existing transaction. This is
done by the new coordinator which informs all DBSs of this transaction the
identify of the new coordinator. For example in Figure 7.3b, BS2 is the new
coordinator, which informs all involved DBSs that BS2 is the coordinator for
this transaction.
Although in dynamic method a mobile unit is directly connected to its coordinator all the time, it becomes a problem for a highly mobile unit. Consider
a situation where MU rapidly moves between C1 and C2 many times. In this
situation it is possible that the process of changing coordinators and the handoff
process may go out of sync. As a result, BS2 may remain the coordinator while
the MU is back in C1. In this highly mobile situation the coordinator change
is not desirable.
Two schemes can be applied to handle coordinator for highly mobile scenario:
- Residency limit: In this scheme a maximum residency duration for a
mobile unit-that is, how long a MU must stay in a cell before a coordinator is changed-is defined. Under this scheme, the coordinator migrates to
the current BS only if the residency of the MU in a cell is longer than the
predefined residency limit. Thus, in Figure 7.3b the coordinator moves
from BS1 to BS2 if the residency of MU in C2 is larger than the predefined
limit. The value for a residency limit may be applied to all MUs or may be
unique to a specific MU. A number of parameters such as movement behavior, the traffic congestion, the time of the day, and so on, can be used
to define a residency limit. Physical movement and traffic congestion
may vary significantly; however, they probably exhibit some pattern. For
example, in the morning time (rush hour) an MU may be highly mobile
and the traffic volume on the network may be high. Thus, the residency
value may be computed dynamically on a case-by-case basis. The residency duration is calculated from the time MU registers with the new BS.
Although the cost of coordinator change is not significant, it should not
be allowed to happen frequently. The rate of change of coordinator can
be controlled by the residency limit parameter.
Nonadjacent migration: Under this scheme the coordinator migrates
only if MU moves to a “nonadjacent cell.” Nonadjacent cells are those
which do not directly touch the cell in which the MU is currently residing.
For example, in Figure 7.4, cells 2, 3 , 4 , 5 , 6 , and 7 are adjacent to cell I ,
and all others such as 9, 10, 11, 12, 13, and 14 are nonadjacent cells to
cell I. The coordinator changes only if the MU moves to any of 9 through
11 cell from cell 1. The idea is that a MU is likely to move back soon
to cell 1 from an adjacent cell; therefore, there is no need to change the
coordinator. This scheme is quite effective for local commuters.
Fig. 7.4 Adjacent and nonadjacent cells.
This section discusses the need for a new transaction model for mobile database
systems. It was recognized in some of the earlier chapters that the conventional ACID
transaction model was unable to satisfactorily manage mobile data processing tasks.
Some of the important reasons were: the presence of hundoff, which is unpredictable;
the presence of doze mode, disconnected mode, and forced disconnection; lack of
necessary resources such as memory, and wireless channels; presence of locationdependent data; etc. To manage data processing in the presence of these new issues, a
more powerful transaction model or ACID transaction execution model that can handle
mobility during data processing was highly desirable. Two approaches to manage
mobile databases were proposed, and the chapter discusses them in detail. Under
each approach, a number of schemes were developed and each approach addressed
some specific issues.
The entire topic of mobile transaction modeling is highly research-oriented; and
although significant number of schemes have been proposed, none has become a
commonly accepted method. The chapter, therefore, identifies each execution model
and presents the original scheme as described by the author(s) of the report. The
discussion clearly indicates the incremental understanding of mobile data processing
and how researchers addressed related issues with their execution models.
In Chapter 6 the effect of new parameters such as mobility, location information, intermittent connectivity, etc., was investigated. It was illustrated that the basic
ACID transaction model was unable to handle mobility aspect and location dependent
processing, which are now quite common in transactional requests.
There are basically two ways to handle transactional requests on MDS: (a) execution model based on ACID transaction framework and (b) mobile transaction model
and its execution. The first approach creates an execution model based on ACID
transaction framework. In the second approach a user query is mapped to a mo-
bile transaction model and executed under mobile ACID constraints. The execution
model approach managed to handle mobility and location information, but its scope
was somewhat limited. This gave rise to the development of mobile transaction models which captured and assimilated mobility and location property in its structure.
These two approaches are discussed in detail in subsequent sections.
The concept of ACID transaction was introduced for consistency-preserving database
processing. Informally, “A transaction is a collection of operations on the physical
and abstract application state” [ 1 11. The conventional transaction model makes sure
that the ACID properties of a transaction are maintained during database processing
[ 1 11. The introduction of mobility significantly changed the database architecture
and management paradigm, and it became clear that the strict enforcement of ACID
properties was not necessary to maintain database consistency. As a matter of fact,
mobility changed and in many cases had to relaxed the notion of consistency because
in mobile database systems the notion of consistency is closely related to locations
in the geographical domain, which is defined as follows:
Definition 7.1 The Geographic Domain, G, is the total geographical area covered
by all mobile units o f a cellular system. Thus, G = (C, + C2 + . . . + Cn),where Ci
represent the area of a cell.
Definition 7.2 A Location is a precise point within the Geographic Domain. It represents the smallest identiJiableposition in the domain. Each location is identiJed by
a spec& id, L. Also, G = UL,V L and C;:= {Li,L2, ..., L,rrL}.
In reality, a location of a mobile unit is identified with reference to the BS. If the
geographic domain were on the Earth, then one can think of a location as a latitude/longitude pair. However, the granularity of the location used may be larger. For
example, the location could be an address, city, county, state, or country.
It is important to understand the complex relationship among the data, the operations to be performed on the data, and the termination of the execution for the
development of an execution model. These issues were introduced in Chapter 6 and
are further elaborated in this chapter.
Location Dependent Query - LDQ: In legacy systems, the frequency of access
of a data items and not their association with geographical locations is used in data
distribution (partition and partial replication). In MDS this association plays an
important role in their processing as well as in their distribution. Figure 7.5 identifies
some important points. Suppose a person is traveling by car from Dallas to Kansas
City and asks, Tax rate please? The answer to this query will depend on where
actually the query originated. If the location is Dallas, then it will give the tax rate
for Dallas; and if it is Kansas City, then the tax rate will be for Kansas City. Now
Fig. 7.5 An example of LDD processing.
suppose that the query is repeated twice while traveling - once in Dallas and then in
Kansas City. We will get two different correct value\. Now suppose the traveler asks
the query, What is the temperature of Dallas? The answer will not depend on the
origin of the query. The result will be the same irrespective of Dallas or Kansas City.
Now consider the following query from the same agent. Get the name and address
of the cheapest hotel. The answer to this query will depend on the characteristics of
the place (e.g., city) where the hotel is located. Thus in one city the rent of the same
hotel could be different compared to some other city.
In every organization, these types of data exist. For example, an insurance company
may have a number of branches in different cities and in different states. At each
branch the premium, the coverage, etc., will be different. These simple real-life
examples suggeyt that the correct answer to a query depends on the geographical
location of the query and the geographical location of the data objects required to
answer the query.
A Location-Dependent Query (LDQ) [4 1,42,48] is a query which processes LDD.
To process an LDQ, the DBMS must first determine that it is an LDQ, LocationRelated ( L R ) or Non-Location-Related (NLR). The location of the query mu\t be
determined and made available to the processor to obtain valid rewlts. A process
called Location Binding is used to associate the query location with the query and to
determine the correct results. The correct definitions of LDD and spatial replication
can be viewed based upon a mapping from an object to a location. Thus given an
object, this mapping identifies the correct data regions for that object. For a specific
object, a subset of the powerset of R identities the data regions for that object where
R represents the set of all possible data regions.
Definition 7.3 Given a set of data objects D and a set of data regions R,a Data
Location Mapping (DLM) is a mapping D L M : 2,
where DLM(D) =
Thus the set of data regions for a data object is a partitioning of the geographic
domain. In the case where no spatial replication of a data object exists, the number
of data regions for that object is one. Given a specific location L in G, each object is
associated with a unique data region.
Definition 7.4 Given a set of data objects V,a set of location ids C, and a set of
data regions R,a Duta Region Mapping ( D R M )is a mapping D R M D x C
where D R M ( < D , L >) E D L M ( D ) .
A data region is identified by the data object and location. As an MU moves,
each location uniquely identifies the data region to which each data belongs. This
gives us the basis to perform location-dependent queries and transactions. A locationdependent query normally returns data values for the location from which it executes.
Notice that this approach is consistent with that in a centralized or distributed environment where only one data region exists for all data objects.
Effect of Mobility and LDD on Consistency: In a centralized or distributed environment, there is only one correct value for each data object. The term mutual
consistency is used to indicate that all the values converge to this same correct value.
A replicated database is said to be in a mutually consistent state if all copies have
the exact same value [34]. In addition, a database is said to be in a consistent state
if all integrity constraints identified for the database are satisfied [34]. This basic
idea of consistency is based only on temporal replication. The idea of consistency is
complicated with spatial replication.
A conventional method of scheduling to ensure mutual consistency is called onecopy serializability [34]. This intuitively implies that the behavior of distributed
transactions appear to provide values of replicas just as if there was no replication.
Thus the scheduling of update operations on the replicas ensures that mutual consistency is eventually achieved. In a snapshot database, this would be the one correct
value. In a temporal database, this would be the mutually consistent value for that
particular time point. Mutual consistency within temporal databases implies that the
replicas for one time point must eventually have same value. When spatial replication is added the data location must also be added to this. Thus, mutual consistency
with spatial replication implies that the spatial replicas for one location (data region)
converge to the same value.
In the MDS environment, the concept of consistency is more complex because
it also involves the geographical location of the data. In MDS a consistent view
is obtained with reference to the geographical data location. A transaction may
modify a data value which would be valid only for a specific data region. Thus an
identical update transaction (at a different location) may be subjected to different sets
of consistency constraints, which will depend upon the place of data manipulation.
A hotel chain or franchise can be used to demonstrate the significance of spatial
replication and its consistency. Hotel Luxury has a number of branches across the
nation. Each branch offers identical services, however, the cost, policy, facilities, etc.,
might depend at the place of the branch location. Thus the same size suite of Luxury
may cost more at Dallas than Kansas City. The data consistency constraints at Kansas
City might be different than at Dallas, because of local taxes and environment policies.
Even though each branch may share the same schema, their instances (data values)
may differ. Any change in Kansas City suite rent by a transaction will not affect
Dallas suite rent and vice versa. This indicates that conventional global and mutual
data consistency states do not apply in MDS. The concept of spatial consistency is
introduced here to distinguish this with conventional consistency, which is referred
to as temporal consistency. The following transaction processing example illustrates
the concept of Locution Inconsistency.
Suppose that a driver during his long trip in winter plans to take a break according to the weather condition. If the weather at the destination is bad, then
he decides to book a hotel around X miles of his current location and eats at a
nearby restaurant; otherwise he decides to continue driving towards his destination and eat in a restaurant there. Suppose the destination is 20 miles from
the starting point. He issues a transaction T from his MU, which processes the
following set of execution fragments.
T1: Check weather at 20 miles from the current location
T2: Check into a hotel 20 miles from the current location.
T3: Find list of restaurants 20 miles from the current location.
T4: Check into a hotel at X miles from current location.
T5: Get list of restaurants at X miles from current location.
If the weather at the destination is not bad, then the possible execution
order is T I ,Tz, and T3;otherwise the order is T I ,T d , and T5. A bad weather
scenario is used to analyze a possible execution order to illustrate how location
inconsistency arises because of the mobility of the MU. Suppose the driver
starts at X for destination Y . After traveling a few miles from X , he issues TI
(What is the weather at Y?) while moving (Figure 7.6). He gets 7’1’s response
Bud weather at Y at A. In a mobile environment, even a short transaction may
run for a longer period of time (not long running in the conventional sense)
because of resource constraints, bandwidth limitations, disconnections, and
heavy traffic in the cell. Consequently, it is possible that by the time the MU
receives the result of T I ,it might have traveled more than 10 miles. This also
depends on how fast the MU is moving. These are likely to create a location
~ _ _ _ _
T l ' s response
MU Movement
T4s response T5's response
T4-Book hotel
T5-resturant list
Fig. 7.6 Transaction execution during mobility.
mismatch. At B he issues T4 (book a hotel within 5 miles) and then issues Ts
(list of restaurants within 5 miles of B).
There exist the following possibilities:
a. The traveler gets the answer of
consistent with the query.
when he is within 5 miles of B. This is
b. The traveler gets the answer of T4 beyond 5 miles of B , in which case there is
location inconsistency. In this case the data region associated with the object
(restaurant) for the query is different from that of the current location of the
c. If (b) exists, then the answer to Ts will be inconsistent (location inconsistency).
*-Hotel booked
List of resturants
Somewhere between E and Y
Current location of MU
Fig. 7.7 An example of location inconsistency.
Figure 7.7 shows an instance of location inconsistency. The result is that the
hotel is booked at location D and restaurants listed are from location D and the
current location is beyond D. The MU has to go back to D where the hotel is
booked and to location E for the restaurant.
A case of location consistency is illustrated in Figure 7.8. Here the location
where the hotel is booked and list of restaurants are the same.
A correct transaction execution model must address these issues. A number of
execution models have been developed and they are explained in detail below. These
mobile execution models are based on existing basic and advanced ACID models
such as ACTA, SAGA, and so on (see Chapter 4) and support distributed transaction
execution. The underlying approach of these execution models is similar; that is,
each supports transaction fragmentation (subtransactions) which satisfies ACID constraints to a large extent. However, they differ on how these fragments are executed
and committed, leading to different execution models for mobile database processing.
The important issues that each execution model considers are the resource (wireless
List of resturants
Hotel booked
Current location of MU
Somewhere between E and Y
Somewhere between E and Y
Current location of MU
Hotel booked
List of resturants
Fig- 7.8 An example of location consistency
channel, memory and disk space, limited energy source, and channel bandwidth)
constraints and mobility of the processing units, and we try to create the same execution scenario which exists in conventional distributed database management systems.
This is where approaches differ from each other.
7.4.1 Execution Model with Reporting Transaction
A mobile execution model based on Open-nested transaction [ 31,43,55] approach is
presented in Ref. [5]. In the execution model the parent ACID transaction is a set of
component transactions where each component transaction can be further fragmented
in to a number of lower level components. The model thus can support an arbitrary
levels of nesting. Formally, the model can be defined as follows:
Definition 7.5 Execution model = { C1. C2, ..., C,,} where C, is a component transaction. A C, = {eel, cc2, cc,,,}, where ccl is a component transaction of C,.
A component transaction can be one of the following four types:
Atomic transaction: It is an ACID transaction and can be compensated by a
compensating transaction. It can be structured as {Begin, Commit, Abort}. An
atomic transaction can be one ofthe child of a parent transaction and can commit
before the parent the commits because, if necessary, it can be compensated. Not
all atomic components can be compensated.
Noncompensating component: It is an atomic component but cannot be compensated. For this reason, a noncompensating transaction can commit before
the parent transaction commits but its data updates cannot be installed in the
final database. A noncompensating transaction (component of a parent transaction) delegates all its updates to its parent transaction, which handles the final
Reporting transaction: A reporting component shares (reports) its updates
with the parent transaction at any time during its execution. This transaction
periodically reports to other transactions by delegating some of its current
results. Thus, reporting transactions are associated with the Report transaction
primitive in addition to the Begin, Commit, and Abort primitives. Begin is
used to initiate a reporting transaction, and Commit and Abort are used for
termination. The mode of this report depends on whether or not it is associated
with a compensating transaction.
Co-transaction: A co-transaction component also shares its results with the
parent transaction; but unlike a reporting transaction, its execution is suspended
when it reports to the parent transaction and resumes its execution from the point
of suspension. Similar to a reporting transaction, a transaction delegates its
current results to its co-transaction by invoking the Report transaction primitive.
Co-transaction components maintained their execution state, and for this reason
they could not be executed concurrently.
This scheme also identified (a) vital and (b) nonvital components. The commitment
of the parent transaction was dependent upon vital transaction; that is, the parent could
commit only if its vital components committed. This kind of commit dependency did
not exist for nonvital components. The parent transaction was able to commit only
after a nonvital component either committed or successfully aborted.
The reporting and co-transaction components are mainly responsible for all data
modifications. Reporting components always execute on base station where as cotransactions execute on mobile units. When a mobile unit, running a co-transaction,
moves and registers with another base station,the corresponding reporting component
also moves to the base station and the communication between reporting and cotransaction remains active. They share their partial results so that the co-transactions
get the most up-to-date values of data items, and the reporting component receives
updates to be installed in the database. The compensating components are invoked
to repair any inconsistency occurred during execution of these components.
This execution model which was based on open-nested framework did not address
the location -dependent data processing issues. Its main objective was to represent
and support ACID transaction execution using mobile components.
In this approach, reporting transactions and co-transactions are treated as an independent unit of action. These transactions support delegation between transactions.
7.4.2 Two-Level Consistency Model
In any database platform, centralized or distributed, the data distribution significantly
affects database performance. A flexible execution model was reported in Ref. [40],
which considered the data distribution as a part of the model. It created clusters of
semantically related or closely located data which were dynamically configured.
Data cluster: A cluster is a set of data with a similar set of properties. Thus a cluster
C = { dl , dz, . . . , d n } where d, is a data item. All dz’s of C are semantically related
and they are required to be fully consistent, while the set of data items at another
cluster may exhibit bounded consistencies. The set of properties of a cluster may
include geographical location of data items; as a result, a cluster can be made up of
data items which are stored at neighboring nodes such as neighboring base stations, if
they are used to store part of the database. Clusters are created, revised, and merged
dynamically, and their management is affected by connection and disconnection of
mobile units.
The model also allows mobile users to specify conditions for creating clusters.
This is especially useful for local commuters who frequently access a well-defined
set of data items. These items are clustered to minimize the access time. In this way
the model tries to satisfy the data needs of mobile units. In terms of clusters, the
database is defined as follows:
Definition 7.6 A mobiledatabaseMD = (Cl1, Glz, . . ., Cln},where C1, isacluster:
Cl = {XI, 5 2 , . . ., rc,}, where x, is a data item. An item J’ E M D iff .c E Cl, for
yome i E N .
Cluster consistency: A data cluster is a unit of consistency. Since a database is a set
of clusters, like conventional databases, there exist two kinds of consistency (a) intracluster consistency and (b) inter-cluster consistency. Intra-cluster consistency refers
to consistency of data items of a cluster (local consistency), and inter-consistency
refers to data item consistency across the clusters similar to global consistency in
conventional distributed systems. This type of consistency is defined by the model
Definition 7.7 (m-consistency)A cluster state is consistent if and only if all intracluster integrity constraints hold. A mobile database state is m-consistent if and
only f a l l cluster states are consistent and all inter-cluster integrity constraints are
m-degree consistent 1401.
Data consistency were maintained at cluster level (local) and at database level
(global). The model defines weak transaction and strong transaction. In addition
to this, it defines weak read and weak write and refers to the normal read as strict
read and normal write as strict write to manage the entire database processing in the
presence of mobility.
Strict write: It writes and leaves the database in a consistent state.
Strict read: It reads main database items which were written by the last strict writes.
Weak write: Writes local data (data in a cluster). This data value becomes permanent only when installed in the main database.
Weak read: Reads local data (data in a cluster) which is written by a weak write.
Weak transaction: A weak transaction is made up of only weak reads and weak
Strict transaction: A strict transaction is made up of only strict reads and strict
writes; that is, it does not include any weak read or weak write operations.
When a transaction is initiated by a user, then it is fragmented into a number of
weak and strong transactions.
Pro-Motion: Proactive management of Mobile Transactions
This execution model focuses on the issues introduced by disconnections and limited
resources [53,54]. The model manages the execution with the help of Compacts and
exploits object semantics for improving concurrency.
Fig. 7.9 Compact object structure
Compacts: A compact is an object which is composed of (a) cached data, (b)
cached data access methods, (c) information about the current state of the compact,
(d) rules of maintaining global consistency, (e) obligations such as deadlines, and
(f) an interface for the mobile unit to manage the compact. Figure 7.9 shows the
complete structure of a compact.
The server comes to an agreement with the mobile unit where a transaction is to be
executed through a compact. Under this agreement the mobile unit is free to execute
the transaction and makes its updates available to a server through the compact. If
there is a need for changing some of the conditions in the execution of transactions,
then this change is renegotiated through the compact.
The server and the mobile unit together manage the compact. The creation and
removal of a compact is handled by the database server. When a mobile unit begins
transaction execution and needs data, then it sends a necessary request to the server.
If the data are available, then the server creates a compact, initializes it with data and
other necessary information, and sends it to the mobile unit. If there already exists a
compact for the execution of this transaction, then any further request from the mobile
unit is satisfied by the updated compact. The arrival or modification of a compact is
recorded in a data structure called compact registry. The compact history provides
complete information about all open compacts initiated by a mobile unit.
The processing of a transaction on a mobile unit is managed by a conzpact agent.
A transaction during its execution on a mobile unit may generate a number ofrequirements. A compact agent, in addition to managing the set of compacts listed in the
registry, is responsible for processing transaction requests. Its functions may be compared with the transaction manager of conventional database management systems.
In particular a compact agent is responsible for (a) enforcing a concurrency control
mechanism, (b) logging, and (c) recovery. Since a compact is an independent object,
a number of consistency constraints and data caching can be efficiently supported.
A compact agent has the following methods available for efficiently managing the
execution of a transaction. In addition to these methods, a compact is also capable
of supporting specialized methods which could be required by special concurrency
control or specific data manipulation.
Inquire: Enquires the current status of a compact.
Notify: Notifies the compact of any change in the status of the mobile unit.
Dispatch: Processes operations on the compact issued by transaction executing
on the mobile unit.
Commit: cCommits the transaction executing on the mobile unit.
Abort: Rejects or removes the changes made to the compact by the transaction.
There is also a compact manager which stores the status of each compact, and
at predefined intervals the state of a compact is updated whenever the status of a
compact changes. In this way it acts as a front-end to the database server and shields
it from mobile units which executes transactions. The database server interacts with a
compact manager as a client, which executes the root transaction. The root transaction
is fragmented under an open-nested model, and each mobile unit executes one or
more fragments. The execution of these sibling fragments proceed independent to
one another without violating the consistency constraints defined in the compacts.
The root transaction is committed by the compact manager.
The transaction processing under Pro-Motion model has four basic steps which are
performed by the compact agent. These steps prepare for (a) disconnected execution,
(b) connected execution, and (c) server database updates. The four basic steps are:
Hoarding: The compact manager prepares and stores the required compacts
to manage disconnected execution of transactions. The mobile unit may be
disconnected from the network anytime.
Connected execution: The mobile unit is connected to the network, and the
compact manager processes transactions.
Disconnected execution: The mobile unit is disconnected from the network,
and the compact manager processes transactions locally.
Resynchronization: The mobile unit, after completing disconnected execution, is reconnected to the server and the compact agent reconciles local updates
performed during the disconnected execution with the server database.
The entire execution is managed by the coordinated effort of the compact, compact
manager, and compact agent. The task of connected execution is simple and similar to
any transaction processing on legacy distributed systems. The mobile unit can process
the transaction, and updates are installed on the server database. The disconnected
operation becomes complex in the presence of mobility. The other three steps which
are responsible for managing disconnected execution are explained in detail below.
Hoarding and Caching
A mobile unit requires a number of resources including data for transaction execution.
Each resource request is implicitly or explicitly associated with a specific compact
type. The compact agent, the mobile application, and the user together build and
maintain the resource list for a mobile unit in behalf of a transaction. The compact
agent continuously monitors the additional resource needs and adds to the list as the
execution progresses. If an application attempts to use the data which is not on the
list, then the compact agents immediately adds it to the list and tries to obtain it. There
are a number of ways hoarding steps can be performed, and the application developer
has enough flexibility for implementing any scheme suitable for the mobile database
In Pro-Motion, it is possible to have multiple requests for the same resource with
different access types. For example, an application A requires data item x with read
and write permissions, and another application B only wants to read x. If application
A is later removed from the MU, then x will still be required but the access level
may be downgraded to read-only. On the other hand, if B is removed, then the
associated request from B is removed and the compact is adjusted to comply with the
requirements of the remaining requests.
A conflict between a holder of a resource (MU) and a requestor compact is resolved
with the help of server side compact. If therequest can be satisfied, aMU-side compact
with appropriate constraints and obligation is created and queued for transmission.
Otherwise a null compact is created and queued to be sent to the MU. If the resource
is available, then the compact manager obtains data modification rights and finds the
matching compact type. The compact manager creates an instance of the appropriate
server-side compact type and forwards the request to the newly created compact. The
server side compact creates an instance of matching MU-side compact with the data
and needed code and queues the new MU-side compact for transmission to MU. If
the resource is held by a stationary transaction, then a null compact is created and
queued for transmission to the MU. A null compact causes operation attempted by an
application to fail.
Disconnecting Transaction Processing
The compact agent on a mobile unit begins local processing when the communication
link between the server and the unit is broken. In local processing the compact agent
and compacts together manage all the operations. The compact agent maintains an
event log to manage transaction processing, recovery, and resynchronization. The
complete execution involves (a) transaction initiation, (b) transaction execution, (c)
transaction completion, and (d) failure recovery.
Transaction Initiation: An application initiates a transaction on a mobile unit by
issuing a BEGIN event. When the compact agent receives this event, it assigns a
unique transaction ID and writes them (the event and the ID) in the event log. ProMotion allows a number of options to the BEGIN event to further specify transaction
behavior. Two such options control transaction’s level of isolation and local commitment. A Begin event with local option commits locally and makes its results available
to other transactions with a possibility of failure at the server. A transaction without
local option does not commit locally until the updates have committed at the server.
A Begin event may also contain a group ID. In the absence of such ID, the compact assigns an ID and returns it to the new transaction. The application can pass
this information to additional transactions, allowing them to join active transactions;
these additional transactions receive the same group ID but different IDS for their
transactions. All transactions with same group ID are commit-dependent, that is,
they terminate together.
Transaction Execution: When a transaction needs to access data during execution,
an OP event is sent to the compact agent with compact ID, the operation to be performed, necessary parameters to complete the operation, transaction ID and group ID.
The compact ID and OP events are used by the compact agent to invoke the compact’s
dispatch method. The compact determines the presence of a conflict between the new
and any pending operations; and if there is one, then the OP event is returned to the
compact agent with a Conjict code and a list of ID’S of conflicting transactions. The
agent then queues the OP event for dispatch to the compact when the compact event
changes. The information saved in the queue is sufficient for deadlock detection and
its resolution. In the absence of a conflict, the operation is performed by the compact.
Transaction Completion: Transaction commitment is performedusing a two-phase
commit protocol. Commitment is initiated when a commit is issued by the transaction. Unlike most transaction processing systems, Pro-Motion allows a contingency
procedure to be attached to each Commit event and logged with the event. When
a commit event is received from a transaction, the compact agent coordinates and
commits the transaction.
Further details about this approach can be found in Refs. [53, 54, 571.
A transaction execution model based on in Ref. pre-write operation [311was presented
in [30]. The approach of this execution model iq to first execute and commit a
transaction on “logical” level and make its data items available to other concurrent
transactions. This logical commit is achieved through pre-write. The results of this
transaction is not installed in the final database. The transaction is finally committed
on the physical level only when it satisfies a set of predefined constraints.
A pre-write announces what value a data item will have after the commit of its
write operation. In other words, it announces the AFter Image (AFIM) of a data item
before the application of a write. Thus the result of a pre-write can be announced as
{jle-name, record number,$eld-name, new value} for a simple database application.
The notion of a virtual execution or pre-commit of a transaction can be expressed
in terms of pre-write. For example, a transaction can be called pre-committed if
it has announced all its pre-writes values but the transaction has not been finally
committed. Likewise, a pre-read returns a pre-write value of the data item whereas
a conventional read returns the result of a write operation. A pre-read becomes a
weak-read if it returns the result of a pre-write of a fully committed transaction. This
is a different way of using weak-read than the way it was used in Ref. [37].
The proposed transaction execution model is based on these set of operations. The
model has the following features:
Each pre-write operation of a transaction shows AFIM value of a data item.
The values of pre-writes depends on the execution environments. In some
cases its value may be identical to what produced by a conventional write, but
in some cases it may differ. For example, the draft copy of a graphic (result of
a pre-write) may be slightly different in color or dimension than the final copy
(produced by a conventional write). Similarly, a pre-write may represent an
abstract of the complete document.
A transaction pre-commits after it has read or pre-read its required data items
and pre-writes are computed. After a transaction pre-commits all its pre-writes
values are made available to other concurrent transactions. Since pre-writes
do not touch the final copy of the database, they are handled at the transaction
manager level and conventional writes are handled by the data manager.
The commit order of concurrent transactions commit is decided at the precommit. This helps to detect conflict quite early.
A transaction can only be aborted or rolled-back before it pre-commits and a roll
back does not cascade. This is illustrated in Figure 7.10. Three transactions,
T I ,T2, and T3, execute concurrently. T I begins and applies read (x),pre-write
(x) on data item .T. T2 begins and applies pre-read (x) after pre-commit but
before write (x) and final commit of T I . TJcommits before 7’1 is aborted.
T3 applies the same set of operation as T J ,but it commits after TI is aborted.
Since T2 and T3 applied pre-read (x) after pre-write (x), they are not rolled
back because it is assumed that T I would write the result of pre-write (x) in
the database. However, if a pre-committed transaction is forced to abort due to
system crash, then it is restarted after system recovery.
read (x), pre-write (x)
Pre-read (x)
Pre-read (x)
Fig. 7.70 Execution of transactions with pre-read and pre-write.
Through the use of pre-read, pre-write, and pre-commit the model relaxes the
isolation constraints and a transaction makes its data items available to other
transaction immediately after it pre-commits but before its final commit.
The following steps describes the working of the algorithm. A Transaction Manager (TM) and Data Manager (DM) architecture is used or the execution of these
steps. The algorithm uses the compatibility matrix given in Table 7.2.
Table 7.2 Compatibility matrix
Pre-write Algorithm
a. Tranaction T, arrives at the TM. The TM identifies read and write requests of
b. If T, has reads and writes, then, if possible, locks are obtained for reads and
data item? values are read. If these values are generated by pre-wrifes, then
these reads become pre-reads.
c. Similarly, necessary locks all acquired for pre-writes.
d. After Ti ends its execution, the pre-commit phase starts. In pre-commit if there
is no conflict, thenpre-write lock mode is converted to write lock mode (Table
e. The pre-commit of T, is announced where all read locks are released
f. The final commit begins where the database is updated with pre-write values
(final write). All write locks are released and commit is announced.
Pre-write Execution in Mobile Database Systems
The pre-write execution model tries to work within resource constraints of mobile
database system. One of the important consideration is the speed of the CPU. For
slow CPUs the execution model does not scale very well and MUs act as a simple
client with no database processing capability. The following transaction execution
example assumes a high speed CPU.
MUs with high-speed CPUs store consistent data items in their local cache. When
a transaction arrives at an MU, it uses cached data to process reads and returns the
pre-write values. Those reads for which cache does not have data are sent to the server
for processing. The server returns pre-write values or write values. The transaction
pre-commits when all values are returned by the server and MU has also completed
its processing. All locks are released and the pre-commit schedule is sent to the server
for the final commit of the transaction.
In some data processing situations, tolerable difference between apre-write version
and a final write version may appear. Consider a transaction rl’, that executes a preread on data item IC which is the result of ape-write of Tj. Tj commits at the server.
In some cases, Ti may have an old value of 2 , but it is tolerated-for example, draft
and final version of a graphic object or some average salary data. A minor difference
in this version is not likely to influence the decision outcome.
In the last few sections, mobile execution models for ACID transactions were discussed in detail. An execution model provides a scheme to execute ACID transactions
in a resource-limited mobile platforms; however, they have some inherent limitations.
Later mobile transaction models were developed to take care of these limitation. A
number of such transaction models are discussed in this section.
HiCoMo: High Commit Mobile Transaction Model
This model was presented in Ref. [29]. Although it has been presented as a mobile
tran5action model, in reality it is a mobile transaction execution model. The execution model is mainly for processing aggregate data stored in a data warehouse which
resides in mobile units. Since the data warehouse resides in mobile units, HiCoMo
transactions are always initiated on mobile units where they are processed in a disconnected mode. As a result, transaction commitments are quite fast. The results of
these transactions are then installed in the database upon reconnection.
The base database resides on the fixed network. It is manipulated by transactions called base or source transactions. These transactions are initiated at the fixed
network. Transaction which are initiated and processed at mobile units are called
HiCoMo. Since HiCoMo transactions do specialized processing, it is based on the
following assumptions:
The data warehouse stores aggregate data of the following types: average, sum,
minimum, and maximum.
Operations such as subtraction, addition, and multiplication are allowed with
some constraints on their order of application.
The model allows some margin of errors. This margin can be defined before
allowed operations are initiated and their value can be varied between a lower
and an upper bound.
The structure of HiCuMo transaction is based on nested transaction model. The
database consistency is satisfied through convergence criteria. It is satisfied when the
states of the base database and the data warehouse in mobile units are identical. This
transaction model ensures that convergence is always satisfied.
As mentioned earlier, the base database at the server is updated by Jource transactions. This requires that to install updates of HiCoMo transactions, they must be
converted to source transactions. This conversion is done by a Transaction Transformation Function, which works as follows:
Conflict detection: A conflict is identified among other HiCoMo transactions
and between HiCoMo and bases transactions. If there is a conflict between
HiCoMo transaction, then the transaction which is being considered for transformation is aborted,
Base transaction generation: In the absence of a conflict, initial base transactions are generated and executed as subtransactions on the base database at the
server. The type of base transaction depends upon the HiCoMo transactions.
Alternate base transaction generation: It is possible that some of these subtransactions may violate integrity constraints (may be outside the error margin)
and, therefore, are aborted. These updates are tried again by redistribution of
error margin. In the worst-case scenario the original HiCoMu transactions are
aborted. If there is no integrity violation, then base transactions are committed.
Moflex Transaction Model
A mobile transaction model called Moflex, which is based on a flexible transaction
model (131, is presented in Ref. [24]. The structure of a Moflex has 7 components
Moflex transaction T = { M , S,
D, H , .I
M = { t l , t z , . . ., t,,}, where t , are compensable on noncompensable subtransactions. Every compensable t , is associated with a corresponding compensating
S = a set of success-dependencies between ti and t,i (1: # j ) . This defines the serial
execution order of these subtransactions. Thus, t j has a success-dependency
on t , (i.e., ti <,s t j ) if t j can be executed only after t i commits successfully.
F = a set of failure-dependencies which indicates that t j can be executed only
after t , has failed. This dependency is represented as (i.e., t, < f t j ) .
D = a set of external-dependencies which indicates that ti can be executed only if
it satisfies predefined external predicates. These predicates are defined on time
( p ) ,cost (Q), and location (L).
H = a set of handoff control rules which manages the execution of subtransactions
in the presence of a handoff. In this event a subtransaction may continue its
execution or restart or split-resume or split-restart. These execution states or
modes are related to handoff and are explained later.
J = a set of acceptablejoin rules which are used to determine he correct execution
of a subtransaction.
G = a set of all acceptable states of T (Mojex).
A Mojlex transaction can be (a) not submitted for execution - N , (b) currently
under execution - E, (c) successfully completed - S or (d) failed - F. An execution
of T is regarded as being complete if its current state exists in set G. When this is
satisfied, then T can commit. Otherwise, if no subtransaction of T is executing or
can be scheduled for execution, then T is aborted.
It is possible to process a location-dependent query with Mojex. The locationdependent predicate, along with other constraints, can be defined in terms of time
such as from 8 AM to 5 PM. For example, a temporal dependency, which is a member
of D , can be stated as follows:
D = {8 Q, L }
P = ( 8 < time ( t l )< 17, 8 < time ( t z ) < 17}
Q = {cost ( t z ) < $100, cost ( t 3 ) < $100)
{tl, t 4 }
When a handoff occurs during the execution of T , then the subtransaction can
further split into finer subtransactions. If the parent subtransaction is compensable and
processing location-dependent data, then the handoff rule forces the subtransaction
to abort and restart in the new cell. A restart can be split-restart where the value of
the partial execution of the subtransaction in the last cell is preserved. In the case of
location-independent subtransaction, it further splits into finer subtransactions. One
of these subtransactions which represents the portion of execution occurring in the
last cell is free to commit.
An Example of a Moflex
An emergency patient dispatch query can be stated as follows. The objective of this
hypothetical transaction is to illustrate how the transaction fits into Mojex transaction
structure. Find the right hospital or take the patient the defuult hospital, then dispatch
patient status to the emergency doctor,for getting the correct treatment. This can be
expressed in a Mojex as
In this example in set G, S indicates a successful execution of Mopex and
means that the execution state of the subtransaction does not have to be one of the
predefined states. Further details about Mojlex can be found in Ref. [24].
Kangaroo MobileTransaction Model
In Ref. [7] a transaction model called Kangaroo is presented which captured both
data and the movement of mobile units. The model is based on a split transaction
model and enforces the majority of ACID properties.
A global or parent Kangaroo transaction, K T , is composed ofa number of subtransactions. Each subtransaction is similar to an ACID transaction, which is composed of
a set of reads and writes. These subtransactions are called Joey Transaction (JT) and
are local to a base station. Upon initiation of a Kangaroo transaction, a base station
creates a JT for its execution which may be executed at mobile units. When these
mobile units migrate to another cell, the base station of this cell takes control of the
execution of this transaction.
KTs support transaction execution in Conzpensating or Split modes. When a failure occurs in a compensating mode, the JT all execution (preceding or following) is
undone and previously committed JTs are compensated. It is difficult for the system
to identify a compensating mode, so users provide useful input for creating compensating JTs. The default execution mode is split mode. When a failure occurs (when
a JT fails) in a default mode, then no new local or global transaction is created from
KT and previously committed JTs are not compensated. As a result, in compensating
mode, JTs are serializable but may not be in split mode.
Kangaroo transaction processing: A KT, when initiated by a mobile unit, is
assigned a unique identity. The initial base station immediately creates a JT with a
unique identity and becomes responsible for its execution. There is one JT per base
station. When the mobile unit encounters a handoff (i.e., moves to a different cell),
KT is split into two transactions - JT1 and JT2. Thus the mobility of a mobile unit is
captured by splitting a KT into multiple JTs. These JTs are executed sequentially; that
is, all subtransactions of JTl are executed and committed before all subtranactions of
JT2. Further details on KT and be found in the original paper.
Some other models have been reported in the literature which are mentioned briefly
here. The semantics-based mobile transaction processing scheme [57]views mobile
transaction processing as a concurrency and cache coherency problem. The model
assumes a mobile transaction to be a long-lived, one characterized by long network
delays and unpredictable disconnections. This approach utilizes thc object organization to split large and complex objects into smaller, manageable fragments. A
stationary database server dishes out the fragments of a object on a request from a
mobile unit. On completion of the transaction the mobile hosts return the fragments
to the server. These fragments are put together again by the merge operation at the
server. If the fragments can be recombined in any order, then the objects are termed
reorderable objects. Since a single database server is assumed, the ACID properties
can be maintained.
MDSTPMTransaction Execution Model
An execution model called Multidatabuse Transaction Processing Munager (MDSTPM) is reported in Ref. 1.561 which supports transaction initiation from mobile
units. The model uses message and queuing facilities to establish necessary communication among mobile and stationary (base station) units. At each stationary unit a
personal copy of MDSTPM exists which coordinates the connected and disconnected
execution of transactions submitted at mobile units.
The MDSTPM has the following components:
Global Communication Manager (GCM): This module manages message
communication among transaction processing units. It maintains a message
queue for handling this task.
Global Transaction Manager (GTM): This module coordinates the initiation
of transactions and their subtransactions. It acts as a Global Scheduling Submanager (GSS)which schedules global transactions and subtranactions. It can
also act as a Globul Concurrency Subnzanager (GCS),which is responsible for
the execution of these transactions and subtranactions.
Local Transaction Manager (LTM): This module is responsible local transaction execution and database recovery.
Global Recovery Manager (GRM): This module is responsible for managing
global transaction commit and their recovery in the event of failure.
Global Interface Manager (GIM): This serves as a link between MDSTPM
and local database managers.
These transaction models did address most of the important issues of mobility,
however, no single model captured or incorporated these issues at one place. In the
Kangaroo model a transaction issued by a user at one mobile unit can be fragmented
and executed at multiple mobile units. This is acceptable on the research level, but
in reality this does not happen. A mobile unit is a resources dedicated to its own
transactions and not open for execution sharing. The location-dependent, locationaware, location-independent, intermittent-execution, etc., are some of the important
issues which are interrelated and need a unified processing by a single model. A model
called Mobilaction has tried to capture these into one model which is discussed next.
Mobilaction-A MobileTransaction Model
In this section a new mobile transaction model called Mobilaction is presented in Ref.
1201. Mobilaction is capable of processing location-dependent data in the presence
of spatial replication. It is composed of a set of subtransactions, which is also called
Execution Fragments, and each fragment is a Mobilaction.
Mobilaction is based on the framework of the ACID model. To manage locationbased processing, a new fundamental property called “location (L)” is incorporated
extending the ACID model to ACIDL. The “location (L)” property is managed by a
location mapping function.
Definition 7.8 Fragment Location Mapping FLM: Each executionfragment, e,7, of a
mobile transaction, Ti, is associated with a unique location. Given a set of execution
,fragments E, FLM is a mapping F L M : E + L.
The FLM identifies (a) the correct geographical location and (b) the correct spatial
replica (LDD) for the execution of a fragment. In addition, it is used to ensure spatial
consistency of fragments within a transaction. We first explain how Mobilaction
satisfies ACID properties and then formally define Mobilaction.
Atomicity for Mobilaction
The purpose of atomicity is to ensure the consistency of the data. However, in a mobile
environment we have two types of consistency. Certainly, atomicity at the execution
fragment level is needed to ensure spatial consistency. However, transaction atomicity
is not. We could have some fragments execute and others not.
Definition 7.9 A mobile transaction, Tt,satisjies Spatial Atomicity iff each execution
.fragment, elj , of T, is atomic. T, is said to be Spatially Atomic iff each execution
.frugment, e 7 j ,is atomic.
Isolation for Mobilaction
Transaction isolation ensures that a transaction does not interfere with the execution
of another transaction. Isolation is normally enforced by some concurrency control
mechanism. As with atomicity, isolation is needed to ensure that consistency is
preserved. Thus we need to reevaluate isolation when spatial consistency is present.
As with consistency, isolation at the transaction level is too strict. The important thing
is to ensure that execution fragments satisfy isolation at the execution fragment level.
Definition 7.10 A mobile transaction, T,, satisjies Spatial Isolation iff each execution,fragment, e t j , o j T , is isolated from all execution frugments of T, or any other
Note that Mobilaction will need to implement a concurrency control technique at
the fragment level. Any concurrency control technique could be used. As a matter of
fact, a different technique could be used for each fragment.
7.6.8 Consistency and Durability for Mobilaction
A conventional transaction commit satisfies the durability property. There is normally only one commit operation per T,. However, to ensure spatial consistency,
spatial isolation, and spatial atomicity, the mobility property requires that the commit
of Mobilaction must also change. We introduce the concept of location-dependent
Definition 7.11 An execution fragment, e,j, satisjies u Location-Dependent Commit
iff thefragment operations terminate with a commit operation and a FLM exists. Thus
all operations in e i j operate on spatial replicas dejined b y a data region mapping
on the location ident$ed b y the FLM. The commit is thus associated with a unique
location, L.
Definition 7.12 An Execution Fragment e z j is a partial order e,j
= {o,,< J } ,
OS, U {N,}, where OS, = UkO,ik, O,k E {read,write}, and NJ E
{abortL, cornrmtL}. Here thehe are a location-dependent commit and abort.
oJ =
For any 0 , k and 0 , l where O,k = R ( r )and 0,I = W ( x )for a data object
x, then either 0,ik
0,I or 0,l
0, k.
VO,k E OS,,O,k IJN,.
The only difference between an execution fragment and a transaction is that either
a location dependent commit or abort is present instead of a traditional commit or
abort. Every fragment is thus associated with a location. However, keep in mind
that if the data object being updated is a temporal replica, then the fragment updates
all replicas. Thus it is not subjected to location constraints and appears as a regular
Definition 7.13 A Mobilaction (T,)
= <F,,L,,FLM7>, where F, = { e l l ,..., p , n }
is a set ojexecution fragments, L , = { 1, 1, ..., I , n } is u set of locations, and F L M t =
{ f l * r n i l ,..., flmin} is a set offragment location mappings, where V j , f l m L j ( e i j )=
lt:j. In addition, V j ?I;, l z j <> lik.
In traditional database systems, ACID transaction is assumed to be a unit of consistency. Even with spatial atomicity, this is still the case with a Mobilaction. A
Mobilaction is a unit of consistency. That is, given a database state which is both
temporally and spatially consistent, a Mobilaction T, converts this state into another
temporally and spatially consistent state.
Table 7.3 Summary of previous mobile transaction models and ACID adherence
Fixed Network
MU or Fixed Network
Restricted Server/MU
MU or Fixed Network
Table 7.3 compares the various mobile transaction models based on ACID property compliance and processing location. Due to the fact that the Kangaroo model
assumes the autonomy of the underlying DBMS systems, subtransactions are allowed
to commitlabort independently. Atomicity may be achieved if compensating transactions are provided. While the Semantics approach allows processing anywhere in the
mobile platform, it is a restricted type of processing in that only one server is assumed
and all fragments processed at the MU must be returned to the server prior to commit.
All but the Semantics-based approach may violate durability. This is because local
transactions which have committed may later be "undone" by a compensating transaction. It is certainly debatable as to whether this really violates durability, since the
compensating transaction is a completely separate transaction. The request column
indicates where the transaction is assumed to be requested. All but the Reporting
assume it is requested at the Mobile Unit. Since this model is a more general than the
others and not limited to a mobile computing environment, it does not assume that
the initial request is made from any particular site. The Execute column indicates
at what sites the kangaroo is assumed to execute. Again this really does not apply
to the Reporting approach. The Kangaroo limits processing to nodes on the fixed
network, while the Semantics approach assumes that the execution at a server on the
fixed network is limited to the creation and then update of the fragments.
Mobile clients encounter wide variations in connectivity ranging from high-bandwidth,
low-latency communications through wired networks to total lack of connectivity
[8, 15, 391. Between these two extremes, connectivity is frequently provided by
wireless networks characterized by low bandwidth, excessive latency, or high cost.
To overcome availability and latency barriers and reduce cost and power consumption, mobile clients most often deliberately avoid use of the network and thus operate
switching between connected and disconnected modes of operation. To support such
behavior, disconnected operation-that is, the ability to operate in a disconnected
mode-is essential for mobile clients [15, 16, 36, 471. In addition to disconnected
operation, an operation that exploits weak connectivity; that is, connectivity provided
by intermittent, low-bandwidth, or expensive networks), is also desirable [ 14, 321.
Besides mobile computing, weak and intermittent connectivity also applies to computing using portable laptops. In this paradigm, clients operate disconnected most of
the time, and occasionally connect through a wired telephone line or upon returning
back to their working environment.
In the proposed scheme, data located at strongly connected sites are grouped
together to form clusters. Mutual consistency is required for copies located at the same
cluster, while degrees of inconsistency are tolerated for copies at different clusters.
The interface offered by the database management system is enhanced with operations
providing weaker consistency guarantees. Such weak operations allow access to
locally (i.e., in a cluster) available data. Weak reads access bounded inconsistent
copies and weak writes make conditional updates. The usual operations, called strict
in this chapter, are also supported. They offer access to consistent data and perform
permanent updates.
The scheme supports disconnected operation since users can operate even when
disconnected by using only weak operations. In cases of weak connectivity, a balanced use of both weak and strict operations provides for better bandwidth utilization,
latency, and cost. In cases of strong connectivity, using only strict operations makes
the scheme reduce to the usual one-copy semantics. Additional support for adaptability is possible by tuning the degree of inconsistency among copies based on the
networking conditions.
In a sense, weak operations offer a form of upplication-aware adaptation [33].
Application-aware adaptation characterizes the design space between two extreme
ways of providing adaptability. At one extreme, adaptivity is entirely the responsibility of the application; that is, there is no system support or any standard way of
providing adaptivity. At the other extreme, adaptivity is subsumed by the database
management system. Since, in general, the system is not aware of the application
semantics, it cannot provide a single adequate form of adaptation. Weak and strict
operations lie in an intermediate point between these two extremes, serving as middleware between a database system and an application. They are tools offered by
the database system to applications. The application can at its discretion use weak
or strict transactions based on its semantics. The implementation, consistency con-
trol, and the underlying transactional support is the job of the database management
The sites of a distributed system are grouped together in sets called physical clusters (or p-clusters) so that sites that are strongly connected with each other belong
to the same p-cluster, while sites that are weakly connected with each other belong
to different p-clusters. Strong connectivity refers to connectivity achieved through
high-bandwidth and low-latency communications. Weak connectivity includes connectivity that is intermittent or low bandwidth. The goal is to support autonomous
operation at each physical cluster, thus eliminating the need of communication among
p-clusters, since such inter-cluster communication may be expensive, prohibitively
slow, and occasionally unavailable. To this end, weak transactions are defined that
access copies at a single p-cluster. At the same time, the usual atomic, consistent,
durable, and isolated distributed transactions, called strict, are also supported.
7.8.1 The Extended Database Operation Interface
To increase availability and reduce inter-cluster communication, direct access to locally (e.g., in a p-cluster) available copies is achieved through weak read ( W E )and
weak write ( W W )operations. Weak operations are local at a p-cluster, i.e., they
access copies that reside at a single p-cluster. We say that a copy or item is locally
available at a p-cluster if there exists a copy of that item at the p-cluster. We call the
standard read and write operations strict read ( S R )and strict write ( S W )operations.
To implement this dual database interface, we distinguish the copies of each data item
as core and quasi. Core copies are copies that have permanent values, while quasi
copies are copies that have only conditionally committed values. When connectivity
is restored, the values of core and quasi copies of each data item are reconciled to
attain a system-wide consistent value.
To process the operations of a transaction, the database management system translates operations on data items into operatioiis on copies of these data items. This
procedure is formalized by a translation function h.. Function h, maps each read operation on a data item z into a number of read operations on copies of z and returns one
value (e.g., the most up-to-date value) as the value read by the operation. That is, we
assume that h, when applied to a read operation, returns one value rather than a set of
values. In particular, h maps each S R [ z ]operation into a number of read operations
on core copies of 2 and returns one from these values as the value read by the operation. Depending on how each weak read operation is translated, we define two types
of translation functions: (1) a best-effort translation function that maps each W R [ z ]
operation into a number of read operations on locally available core or quasi copies
of z and returns the most up-to-date such value and a (2) conservative translation
function that maps each weak read operation into a number of read operations only
on locally available quasi copies and returns the most up-to-date such value.
Based on the time of propagation of updates of core copies to quasi copies, two
types of translation functions are defined: (a) eventual translation function that maps
a S W [ z ]into writes of core copies only and (b) immediate translation function that in
addition updates the quasi copies that reside at the same p-cluster with the core copies
written. For an immediate h, conservative and best effort have the same result. Each
W W [x]operation is translated by h into a number of write operations of local quasi
copies of x. How many and which core or quasi copies are actually read or written
when a database operation is issued on a data item depends on the coherency algorithm
used (e.g, quorum consensus, ROWA) [4]. Table 7.4 summarizes the semantics of
Table 7.4 Variations of the translation function
Reads local copies and returns the most recent value
Weak Read (WR)
Best effor h:
Reads both core and local quasi copies
Conservative h: Reads only local quasi copies
1 Strict Read (SR) I Reads core copies and returns the most recent value
I Weak Write (WW) I Writes local quasi copies
Strict Write (SW)
Eventual h:
Writes only core copies
Immediate h:
Writes both core and quasi copies at the corresponding p-clusters
Definition 7.14 A transaction ( T )is a partial order (OP, <), where OP is the set
of operations executed by the transaction, and < represents their execution order.
The operations include the following data operations: weak ( W R )or strict reads
( S R )and weak ( W W )or strict writes ( S W ) , as well as abort ( A )and commit ( C )
operations. The partial order must specify the order o j conflicting data operations
and contains exactly one abort or commit operation which is the last in the ordex
Two weak or strict data operations conflict if they access the same copy of a data item
and at least one of them is a weak or strict write operation.
Two types of transactions are supported: weak and strict. A strict transaction ( S T )
is a transaction where O P does not include any weak operations. Strict transactions
are atomic, consistent, isolated, anddurable. A weak transaction ( W T )is a transaction
where O P does not include any strict operations. Weak transactions access data copies
that reside at the same physical cluster and thus are executed locally at this p-cluster.
Weak transactions are locally committed at the p-cluster at which they are executed.
After local commitment, their updates are visible only to weak transactions in the
same p-cluster; other transactions are not aware of these updates. Local commitment
of weak transactions is conditional in the sense that their updates might become
permanent only after reconciliation when local transactions may become globally
committed. Thus, there are two commit events associated with each weak transaction,
a local conditional commit in its associated cluster and an implicit global commit at
Other types of transactions that combine weak and strict operations can be envisioned; their semantics, however, become hard to define. Instead, weak and strict
transactions can be seen as transaction units of some advanced transaction model. In
this regard, upon its submission, each user transaction is decomposed into a number of weak and strict subtransaction units according to semantics and the degree of
consistency required by the application.
Data Correctness
A database is a set of data items, and a database state is defined as a mapping of every
data item to a value of its domain. Data items are related by a number of restrictions,
called integrity constraints, that express relationships among their values. A database
state is consistent if the integrity constraints are satisfied 13.51. In this chapter, we
consider integrity constraints being arithmetic expressions that have data items as
variables. Consistency maintenance in traditional distributed environments relies on
the assumption that normally all sites are connected. This assumption, however, is no
longer valid in mobile computing, since the distributed sites are only intermittently
connected. Similar network connectivity conditions also hold in widely distributed
systems as well as in computing with portable laptops.
To take into account intermittent connectivity, instead of requiring maintenance of
all integrity constraints of a distributed database, logical clusters is introduced as units
of consistency. A logical cluster, 1-cluster, is the set of all quasi copies that reside
at the same p-cluster. In addition, all core copies constitute a single system-wide
logical cluster independently of the site at which they reside physically. Consistency
is relaxed in the sense that integrity constraints are ensured only for data copies that
belong to the same logical cluster. An intra-cluster integrity constraint is an integrity
constraint that can be fully evaluated using data copies of a single logical cluster. All
other integrity constraints are called inter-cluster integrity constraints.
Definition 7.15 A mobile database state is consistent ifall intra-cluster integrity constraints are satisfied and all inter-cluster integrity constraints are bounded-inconsistent.
In inter-cluster integrity constraints bounded inconsistency means that all copies
in the same logical cluster have the same value while among copies at different logical
clusters there is bounded divergence 12, 491. Bounded divergence is quantified by
a positive integer d, called degree of divergence; possible definitions of d are are as
Maximum number of transactions that operate on quasi copies.
Range of acceptable values that a data item can take.
Maximum number of copies per data item that diverge from a pre-assigned
primary copy of item, i.e., the core copies.
Maximum number of data items that have divergent copies.
Maximum number of updates per data item that are not reflected at all copies
of the item.
A replication constraint for T thus bounded is called d-consistent. The degree of
divergence among copies can be tuned based on the strength of connection among
physical clusters, by keeping the divergence small in instances of high bandwidth
availability and allowing for greater deviation in instances of low bandwidth availability.
Immediate translation and consistency. To handle integrity constraints besides
replication, in the case of an immediate translation function la, h should be defined
such that the integrity constraints between quasi copies in the same logical cluster are
not violated. The following example is illustrative.
For simplicity consider only one physical cluster. Assume two data items x and
y, related by the integrity constraint T > 0 + y > 0, and a consistent database
state xc = -1, .xq = -1, yc = 2 and !j4 = -4, where the subscripts c, and q
denote core and quasi copies respectively. Consider the transaction:
x = I0
ify < 0
theny = 10
If the above program is executed as a strict transaction S W ( x ) SR(y) G, it
sets the database state rc, = 10, zq = 10, yc = 2 and yq = -4, in which the
integrity constraint between the quasi copies of x and TJ is violated. Note that
the quasi copies were updated because an immediate translation function was
The problem arises from the fact that quasi copies are updated to the current value
of the core copy without taking into consideration integrity constraints among them.
Similar problems occur when refreshing individual copies of a cache [21. Possible
solutions include:
a. Each time a quasi copy is updated at a physical cluster as a result of a strict write,
the quasi copies of all data in this cluster related to it by some integrity constraint
are also updated either after or prior to the execution of the transaction. This
update is done following a reconciliation procedure for merging core and quasi
copies (as in Section 7.10). In the above example, the core and quasi copies of
x and g should have been reconciled prior to the execution of the transaction,
producing for instance the database state = -1, zq = -1 yjl: = 2 and
yq = 2. Then, the execution of the transaction would result in the database
state x, = 10, x q = 10, yc = 2, and yy = 2, which is consistent.
b. If a strict transaction updates a quasi copy at a physical cluster, its read operations are also mapped into reads of quasi copies at this cluster. In cases of
incompatible reads, again, a reconciliation procedure is initiated having a result
similar to the one above.
c. Updating quasi copies is postponed by deferring any updates of quasi copies
that result from writes of the corresponding core copies. A log of weak writes
resulting from strict writes is kept. In this scenario, the execution of the transaction results in the database state x, = 10, x4 = -1, ?jC = 2 and yq = -4,
which is consistent. The first two approaches may force an immediate reconciliation among copies, while the third approach defers this reconciliation and
is preferable in cases of low connectivity among physical clusters.
This section covers serializability-based criteria, graph-based tests and a locking protocol for correct executions that exploit weak connectivity. In the operation represented by o3 the subscript j indicates that o belongs to transaction j , while the
subscript on a data copy identifies the physical cluster at which the copy is located. It
is assumed that there was only one quasi copy per physical cluster. This assumption
can be easily lifted but with significant complication in notation. Since all quasi
copies in a physical cluster have the same value, this single copy can be regarded as
their representative. Read and write operations on copies are denoted by read and
write respectively.
A complete intra-cluster schedule, IAS, is an observation of an interleaved execution of transactions in a given physical cluster configuration, that includes (locally)
committed weak transactions and (globally) committed strict transactions. Formally,
Definition 7.16 (intra-cluster schedule) Let T = {To,T I ,..., TTL}
be a set oftransactions. A (complete)intra-cluster schedule, I A S , overT is a pair ( O c <,) in which
<a is a partial ordering relation such that:
1. O P = h(U;="=,,) for some translation function h. This condition states
that the transaction managers translate each operation on a data item into
appropriate operations on data copies.
2. For each T, and all operations O p k , opi in T,, ifopk <%
opl, then every operution
in h ( o p k ) is related by <a to every operation in h(opl). This condition states
that the intra-cluster schedule preserves the ordering < Lstipulated by each
transaction T,.
3. All pairs of conjicting operations are related by <, where two operutions
conflict ifthey access the same copy and one of them is a write operation. This
states that the execution order of conjicting operations are also recorded.
4. For all read operations, yead, [xi],there is at least one w i t e k [z,] such that
writek[x,] <a read,
This condition states that a transaction cannot read
a copy unless it has been previously initialized.
S R j [ x ]and rc:adj((zi) E h ( S R j [ z ] )then
writej(xi) E
h ( S W j [ x ] ) .This condition states that, if a transaction writes a data item
x before it reads x,then it must write to the same copy of x that it subsequently
5. lj’SWj[x] <3
6. Ifrwrite, [xi]E Ii(SW, [x])
for some strict transaction T f ,then uiritej [yi] E
h ( S W j [ y ] )for
, all y written by Tj for which there is a y i atphysical cluster
Cli, where z i is a quasi copy when h, is conservative and any, quasi or core,
copy when h is best effort. This condition indicates thatfor a strict transaction,
f a write is translated to a write on a core copy at a physical cluster Cli then
all other writes of this transaction must also write any corresponding copies
at this cluster. This condition is necessary for ensuring that weak transactions
do not see partial results of a strict transaction.
A read operation on a data item J reads-x-from a transaction T z ,if it reads (i.e.,
returns as the value read) a copy of c written by T, and no other transaction writes this
copy in between. A transaction T,has the same reads-from relationship in schedule
5’1 as in schedule 5’2, if for any data item .c, if T, reads-x-from T3in 5’1, then it readsr-from T3in &. Given a schedule S, the projection of S on strict transactions is the
schedule obtained from S by deleting all weak operations, and the projection of S on
aphysical cluster Clk is the schedule obtained from S by deleting all operations that
do not access copies in Clk. Two schedules are conflict equivalent if they are defined
over the same set of transactions, have the same set of operations and order conflicting
operations of committed transactions the same way [4]. A one-copy schedule is the
single-copy interpretation of an (intracluster) schedule where all operations on data
copies are represented as operations on the corresponding data item.
Correctness Criterion
A correct concurrent execution of weak and strict transactions must maintain boundedinconsistency. A weak form of correctness, in which the only requirement for weak
transactions is that they read consistent data, is considered first. The requirement for
strict transactions is stronger, because they must produce a system-wide consistent
database state. In particular, the execution of strict transactions must hide the existence
of multiple core copies per item: i.e., it must be view-equivalent to a one-copy
schedule 141. A replicated-copy schedule S is view-equivalent to a one-copy schedule
S and SIChave the same reads-from relationship for all data items, and
For each final write W R , ( z )in SIC,writei(x,7)is a final write in S for some
copy x3 of x.
These requirements for the execution of strict and weak transactions are expressed
in the following definition:
Definition 7.17 (IAS Weak Correctness) An intra-cluster schedule S r ~ iss weakly
correct ifl all the~followingthree conditions are satis$ed:
1. All transactions in S l ~ have
s a consistent view, i.e., all integrity constraints
that can be evaluated using the data read are valid,
2. There is a one copy serial schedule S such that: ( a ) it is dejined on the same
set of strict trumactions as SIAS,( b ) strict transactions in S have the same
reads-from relationship as in S I A S ,and ( c ) the set of$nul writes in S is the
same as the set of’nal writes on core copies in SIAS,
3. Bounded divergence among copies at different logical clusters is maintained.
The approach to enforce the first two conditions is discussed first. Protocols for
bounding the divergence among copies at different logical clusters are outlined at
the end of this section. A schedule is one-copy serializable if it is equivalent to a
serial one-copy schedule. The following theorem defines correctness in terms of
equivalence to serial executions.
Theorem 1 Given that bounded divergence among copies at different logical clusters
is maintained, if the projection of an intra-cluster schedule S on strict transactions
is one-copy serializable and each of its projections on a physical cluster is conjictequivalent to a serial schedule, then S is weakly correct.
Proof: Condition 1 of Definition 7.17 is guaranteed for strict transactions from the
requirement of one-copy serializability, since strict transactions get the same view as
in a one-copy serial schedule and read only core copies. For weak transactions at a
physical cluster, the first condition is provided from the requirement of serializability
of the projection of the schedule on this cluster given that the projection of each (weak
or strict) transaction on the cluster satisfier all intracluster integrity constraints when
executed alone. Thus, it suffices to prove that such projections maintain the intracluster integrity constraints. This trivially holds for weak transactions, since they are
local at a physical cluster. The condition also holds for strict transactions, since if
a strict transaction maintains consistency of all database integrity constraints, then
its projection on any cluster also maintains the consistency of intra-cluster integrity
constraints, as a consequence of Condition 6 of Definition 7.16. Finally, one copy
serializability of the projection of strict transactions suffices to guarantee 2(b) and
2(c), since strict transactions read only core copies and weak transactions do not write
core copies respectively.
Inter-cluster integrity constraints other than replication constraints among quasi copies
of data items at different clusters may be violated. Weak transactions, however, are
unaffected by such violations, since they read only local data. Although, the above
correctness criterion suffices to ensure that each weak transaction gets a consistent
view, it does not suffice to ensure that weak transactions at different physical clusters
get the same view, even in the absence of intercluster integrity constraints. This is
illustrative by the following example.
Assume two physical clusters C11 = {x,y} and CZ2 = {w, z , I } with both
quasi and core copies of the corresponding data items, and also assume two strict
transactions ST, = SlV1 [x]SW1[w]C,
and ST2 = SW2 [y]SW~[z]SR:![x]C2.
In addition, at cluster C11 there is a weak transaction WT3 = WR3 [z]
WR3 [y]
C;, and at cluster Clz the weak transactions are WTq = WR,[z] WW4[1]
C4, and WTs = WR,,[w]WR5[1]C,. For simplicity, the transaction that
initializes all data copies is not shown. We consider an immediate and best
effort translation function h. For notational simplicity, no special notation for
the core and quasi copies have been used, since which copies are read is inferred
by the translation function.
Assume that the execution of the above transactions produces the following
schedule which is weakly correct: S = WR,[zu] SW~[:I;]WR;[s]
c1 W, [y] sw2 [4 sns
WR3 [y] C3WR4 [z ] W W, [11 WR5 [11
I . [ c,
The projection of S on strict transactions is: SW1[x]SW,[w] C1 SW2[y]
SW2 [ z ] C2 which is equivalent to the 1SR schedule: SW, [x]SW, [w]
sw2 [Yl sw2I.[
c 2
The projection of S on Cl1: SW1[z]
WR3 [x]C1 SW2 [y] SR2 [x]WRs [y] C<:
is serializable as ST1 + ST2
TheprojectionofSonClz: WR,[w] SWl [%I)] C1 SW2[z]Cz WR4[z] WWd[l]
C d WRs[I]
Cs is serializable as ST2 + WTd + WT, + ST1
Thus, weak correctness does not guarantee that there is a serial schedule equivalent to the intra-cluster schedule as a whole, that is, including all weak and strict
transactions. The following is a stronger correctness criterion that ensures that all
weak transactions get the same consistent view. Obviously, strong correctness implies
weak correctness.
Definition 7.18 (IAS Strong Correctness) An intra-cluster schedule
correct iff there is a serial schedule Ss such that
S i s strongly
I . SS is conjict-equivalent with S.
2. There is a one-copy schedule SIC;
such that ( a )strict transactions in Ss have
the same reads-from relationship as in SIC,and ( b ) the set offinal writes on
core copies in Ss i s the same as in SIC.
3. Bounded divergence among copies at diferent logical clusters is maintained.
Lemma 1 Given that bounded divergence among copies at difSerent logical clusters
is maintuined, ij'the projection of an intra-cluster schedule S is conjlict-equivalent to
a serial schedule SS and its prqjection on strict trunsactions is view-equivalent to a
one-copy serial schedule SICsuch that the order qf transactions in SS is consistent
with the order of transactions in SIC,S is strongly correct.
Proof: It is necessary to prove that in SIC, strict transactions have the same readsfrom and final writes as in SS,which is straightforward since strict transaction only
reads data produced by strict transactions and core copies are written only by strict
Since weak transactions do not conflict with weak transactions at other clusters
directly, the following is an equivalent statement of the above lemma,
Corollary 1 Given that bounded divergence among copies at different logicul clusters is maintained, ifthe projection of an intra-cluster schedule S o n strict transactions
is view-equivalent to a one-copy serial schedule SIC,and each qf its projections on
a physical cluster Cl, is conflict-equivalent to a serial schedule SS,such that the
order cgtransactions in Ss, is consistent with the order of transactions in SIC, S is
strongly correct.
If weak I A S correctness is used as the correctness criterion, then the transaction
managers at each physical cluster must only synchronize projections on their cluster. Global control is required only for synchronizing strict transactions. Therefore,
no control messages are necessary between transaction managers at different clusters for synchronizing weak transactions. The proposed scheme is flexible, in that
any coherency control method that guarantees one-copy serializability (e.g., quorum
consensus, primary copy) can be used for synchronizing core copies. The scheme
reduces to one-copy serializability when only strict transactions are used.
7.9.2 The Serialization Graph
To determine whether an I A S schedule is correct, a modified serialization graph that
we call the intra-cluster serialization graph (IASG) of the I A S schedule is used.
To construct the IASG, first a replicated data serialization graph (SG) is built that
includes all strict transactions. An SG 141 is a serialization graph augmented with
additional edges to take into account the fact that operations on different copies of
the same data item may also create conflicts. Acyclicity of the SG implies one-copy
serializability of the corresponding schedule. Then, the SG is augmented to include
weak transactions as well as edges that represent conflicts between weak transactions
in the same cluster and weak and strict transactions. An edge is called a dependency
edge, if it represents the fact that a transaction reads a value produced by another
transaction. An edge is called a precedence edge, if it represents the fact that a
transaction reads a value that was later changed by another transaction. It is easy
to see that in the IASG there are no edges between weak transactions at different
clusters, since weak transactions at different clusters read different copies of a data
item. In addition:
Property 1 Let WT, be a weak transaction at cluster Cl,, and let ST be a strict
transaction. The IASG graph induced by an IAS may include only the following
edges between them:
a dependency edge from ST to WT,
a precedence edge from WT, to ST
Proof: Straightforward, since the only conflicts between weak and strict transactions
are due to strict writes and weak reads of the same copy of a data item.
r 7 1
Fig. 7.1 1 Lock compatibility matrices. A X entry indicates that the lock modes are compatible. (a) Eventual and conservative h. (b) Eventual and best effort h. ( c ) Immediate and
conservative h. (d) Immediate and best effort h.
Theorem 2 Let S I A be
~ an intracluster schedule. If S l ~ has
s an acyclic IASG,
then SIA.~
is strongly correct.
Proof: When a graph is acyclic, then each of its subgraphs is acyclic; thus the
underlying SG on which the I A S G was built is acyclic. Acyclicity of the SG implies
one-copy serializability of strict transactions, since strict transactions only read values
produced by strict transactions. Let l ; ,TJ,
... , T,, be all transactions in S I A S .
Thus, T I ,T2, ... , T,, are the nodes of the IASG. Since IASG is acyclic it can be
topologically sorted. Let Ti,, Ti2,... , Ti, be a topological sort of the edges in
IASG, then by a straightforward application of the serializability theorem [4], S I A ~
is conflict equivalent to the serial schedule SS = T i , , Ti2,... , Ti,. This order is
consistent with the partial order induced by a topological sorting of the SG; let SIC
be the serial schedule corresponding to this sorting. Thus, the order of transactions
in S , y is consistent with the order of transactions in Sic.
7.9.3 Protocols
Serializability: It is important to distinguish between coherency and concurrency
control protocols. Coherency control ensures that all copies of a data item have the
same value, in the proposed scheme, we must maintain this property globally for core
and locally for quasi copies. Concurrency control ensures the maintenance of the
other integrity constraints, here the intra-cluster integrity constraints. For coherency
control, we assume a generic quorum-based scheme 141. Each strict transaction reads
q7. core copies and writes qTUcore copies per strict read and write operation. The
values of 4,. and qw for a data item z are such that qT + qW> n d , where 'nd is the
number of available core copies of 2 . For concurrency control we use strict two phase
locking, where each transaction releases its locks upon commitment 141. Weak transactions release their locks upon local commitment and strict transactions upon global
commitment. There are four lock modes ( W R ,IVW, SR, S W ) corresponding to the
four data operations. Before the execution of each operation, the corresponding lock
is requested. A lock is granted only if the data copy is not locked in an incompatible
lock mode. Figure 7.1 1 depicts the compatibility of locks for various types of translation functions and is presented to demonstrate the interference between operations
on items. Differences in compatibility stem from the fact the operations access different kinds of copies. The basic overhead on the performance of weak transactions
imposed by these protocols is caused by other weak transactions at the same cluster.
This overhead is small, since weak transactions do not access the slow network. Strict
transactions block a weak transaction only when they access the same quasi copies.
This interference is limited and can be controlled, for example, by letting in cases
of disconnections, strict transactions access-only core copies, and weak transactions
access-only quasi copies.
Bounding divergence among copies: At each p-cluster, the degree for each data
item exprecses the divergence of the local quasi copy from the value of the core
copy. This difference may result either from globally uncommitted weak writes or
from updates of core copies that have not yet been reported at the cluster. As a
consequence, the degree may be bounded either by limiting the number of weak
writes pending global commitment or by controlling the h function. Table 7.5, we
outline methods for maintaining d-consistency for different ways of defining d.
Table 7.5 Maintaining bounded inconsistency
Definition of divergence (4
Applicable method
A ranae of accedable values of a data item
i of divergent copies
The maximum number of data items that
L i v e r aent comes
The maximum number of updates per data
item not reflected at all copies
Appropriately bound the number of weak transactions at each phyical cluster. In
the case of a dynamic cluster reconfiguration, the distribution of weak transactions
at each cluster must be readjusted.
The maximum number of transactions that
operate on quasi copies
Allow onlv weak writes with values inside the acceDtable ranae
Writes local quasi copies
Bound the number of data items that can have quasi copies
Define h so that each strict write modifies the quasi copies at each physical
cluster at least after dupdates. This, however, cannot be ensured for
disconnected clusters since there is no way of notifyinq them for remote updates.
After the execution of a number of weak and strict transactions, for each data item, all
its core copies have the same value, while its quasi copies may have as many different
values as the number of physical clusters. Approaches to reconciling the various
values of a data item so that a single value is selected vary from purely syntactic to
purely semantic ones [6]. In restoring the database state, syntactic approaches use
serializability-based criteria, while semantic approaches use either the semantics of
transactions or the semantics of data items. A purely syntactic and thus applicationindependent approach is adopted here. The exact point when reconciliation is initiated
depends on the application requirements and the distributed system characteristics.
For instance, reconciliation may be forced to keep inconsistency inside the required
limits. Alternatively, it may be initiated periodically or on demand upon the occurrence of specific events, such as the restoration of network connectivity, for instance
when a PDA (Personal Digital Assistant or Palmtop) is plugged-back to the stationary
network or a mobile host enters a region with good connectivity.
7.1 0.1
Correctness Criterion
The reconciliation approach is based on the following rule: A weak transaction becomes globally committed $the inclusion of its write operations in the schedule does
gstrict transactions. It assumes that weak
not violute the one-copy serializability c
transactions at different clusters do not interfere with each other even after reconciliation; that is, weak operations of transactions at different clusters never conflict. A
(complete) inter-cluster schedule (IES) models execution after reconciliation, where
strict transactions become aware of weak writes; that is, weak transactions become
globally committed. Thus, in addition to the conflicts reported in the intra-cluster
schedule, the inter-cluster schedule reports all relevant conflicts between weak and
strict operations. In particular:
Definition 7.19 (inter-cluster schedule) An inter-cluster schedule ( I E S )S I Ebased
s (OP, <,) is a pair (OP', < e ) , where
on an intra-cluster schedule S r ~ =
1. OP' = OP, and for any opi and opJ t OP', ifopi
<e op.7 in S I E S .
<a orjj
in . ' j l ~ s ,then op,
2. For each pair of weak write opi = W W t [ x ]and strict read opj = SRj[.r]
operations, as well as for all pairs of operations, we have cop? E h(opi) and
cop, t h(opj),we have copi cecop,, or copj < r cop+
3. For each pair of weak write opi = WWi[.r]and strict write opj = SW, [x]
operations, as well as for all pairs qjoperations, cop? E h(opi) and cop, E
h ( o p j ) , copi <a copj, or copj < p copi.
The reads-from relationship for strict transactions is extended to take weak writes
into account. A strict read operation on a data item z reads x from a transaction
T, in an IES schedule, if it reads a copy of x and Ti has written this or any quasi
copy of x and no other transaction wrote this or any quasi copy of x in between. A
weak write by a strict transaction is acceptable as long as the extended reads-from
relationship for strict transactions is not affected; that is, strict transactions still read
values produced by strict transactions. In addition, correctness of the underlying
1AS schedule implies one-copy serializability of strict transactions and consistency
of weak transactions.
Definition 7.20 (IES Correctness) An inter-cluster schedule is correct i f
1. it is based on a correct IAS schedule SIAS,
2. the reads-jrom relationship jbr strict transactions is the same with their reads
from relationship in the SIAS.
7.10.2 The Serialization Graph
A modified serialization graph called inter-cluster serialization graph (IESG) is defined to determine correct IES schedule and to construct IESG the serialization graph
IASG of the underlying intra-cluster schedule is augmented. The following steps are
induced to force conflicts among weak and strict transactions that access different
copies of the same data item:
First, a write order as follows: if T, weak writes and T k strict writes any copy
of an item .c, then either T, + T k or T k
Then, a strict read order as follows: If a strict transaction ST, reads x,from ST,
in S I A ,and
~ a weak transaction W T follows ST,, we add an edge ST, + W T .
Theorem 3 Let S I Ebe
~ an IES schedule based on an IAS schedule S I A S .l f S I E ~
has an acyclic IESG, then S r ~ is
s correct.
Proof Clearly, if the IESG graph is acyclic, the corresponding graph for the IAS
is acyclic (since to get the IESG we only add edges to the IASG) and thus the 1AS
schedule is correct. It can be shown that if the graph is acyclic, then the reads-from
relationship for strict transactions in the inter-cluster schedule S l ~ iss the same as
in the underlying intra-cluster schedule Sins. Assume that STj reads x from ST,in
S I A , ~Then
. ST, STj. Assume for the purposes of contradiction that ST, reads x
from a weak transaction W T . Then W T writes IC in S I Eand
~ since ST, also writes
:L either (a) ST, + W T or (b) W T + ST;. Case (a), from the definition of the
IESG, gives STj + W T ,which is a contradiction since STj reads xjrom W T . In
case (b), W T 4 S T , ;that is, W?' precedes ST,,
which precedes ST,, which again
contradicts the assumption that STj reads x from W T .
7.10.3 Protocol
It is necessary to break potential cycles in the IES graph to get a correct schedule.
There is always at least one weak transaction present in each cycle because the construction of the IESG starts from an acyclic graph where edges are added between a
weak and a strict transaction. These weak transactions are rolled back. Undoing a
transaction T may result in cascading aborts of transactions that have read the values
written by T-that is, transactions that are related to T through a dependency edge.
Since weak transactions write only quasi copies in a single physical cluster and only
weak transactions in the same cluster can read these quasi copies:
Lemma 2 Only weak transactions in the same physical cluster read values written
by weak transactions in that clustel:
The above lemma ensures that when a weak transaction is aborted to resolve conflicts
in an inter-cluster schedule, only weak transactions in the same p-cluster are affected.
In practice, fewer transactions ever need to be aborted. In particular, only weak
transactions whose output depends on the exact values of the data items they read
need to be aborted. These are called exact transactions. Most weak transactions
are not exact, since by definition, weak transactions are transactions that read local
&consistent data. Thus, even if the value they read was produced by a transaction
that was later aborted, this value was inside an acceptable range of inconsistency and
this is probably sufficient to guarantee their correctness.
Detecting cycles in the IESG can be hard. The difficulties arise from the fact
that between transactions that wrote a data item an edge can have any direction,
thus resulting in polygraphs [35]. Polynomial tests for acyclicity are possible, if it is
assumed that transactionsread a dataitem before writing it. Then, to get the IES graph
from the IAS graph, only the following is needed. Induce a read order as follows:
Ifa strict transaction ST reads an item that was written by a weak transaction W T ,
then add a precedence edge ST + W T .
The reconciliation process can be expressed as follows:
Until there are no cycles in IESG
rollback a weak transaction WT in the cycle
rollback all exact transactions related with a dependency edge to WT
Ifthejnal write is on a core copy propagate this value to all quasi copies
choose a value of a quasi copy
propagate this value to all core and quasi copies
In the proposed hybrid scheme, weak and strict transactions coexist. Weak transactions let users process local data thus avoiding the overhead of long network accesses.
Strict transactions need access to the network to guarantee permanence of their updates. Weak reads provide users with the choice of reading an approximately accurate
value of a datum-in particular, in cases of total or partial disconnections. This value
is appropriate for a variety of applications that do not require exact values. Such applications include gathering information for statistical purposes or making high-level
decisions and reasoning in expert systems that can tolerate bounded uncertainty in
input data. Weak writes allow users to update local data without confirming thcse
updates immediately. Update validation is delayed until the physical clusters are
connected. Delayed updates can be performed during periods of low network activity
to reduce demand on the peaks. Furthermore, grouping together weak updates and
transmitting them as a block rather than one at a time can improve bandwidth usage.
For example, a salesperson can locally update many data items, until these updates
are finally confirmed, when the machine is plugged back to the network at the end
of the day. However, since weak writes may not be finally accepted, they must be
used only when compensating transactions are available or when the likelihood of
conflicts is very low. For example, users can employ weak transactions to update
mostly private data and strict transactions to update frequently used, heavily shared
The cluster configuration is dynamic. Physical clusters may be explicitly created
or merged upon a forthcoming disconnection or connection of the associated mobile
clients. To accommodate migrating locality, a mobile host may join a different pcluster upon entering a new support environment. Besides defining clusters based
on the physical location of data, other definitions are also possible. Clusters may
be defined based on the semantics of data or applications. Information about access
patterns-for instance, in the form of a user’s projile that includes data describing
the user’s typical behavior-may be utilized in determining clusters. Some examples
Cooperative Environment: Consider the case of users working on a common
project using mobile hosts. Groups are formed that consist of users who work
on similar topics of the project. Physical clusters correspond to data used by
people in the same group who need to maintain consistency among their interactions. Consider data that are most frequently accessed by a group as data
belonging to this group. At each physical cluster (group), the copies of data
items of the group are core copies, while the copies of data items belonging
to other groups are quasi. A data item may belong to more than one group, if
more than one group frequently accesses it. In this case, core copies of that
data item exist in all such physical clusters. In each physical cluster, operations on items that do not belong to the group are weak, while operations on
data that belong to the group are strict. Weak updates on a data item are accepted only when they do not conflict with updates by the owners of that data
Caching: Clustering can be used to model caching in a clientlserver architecture. In such a setting, a mobile host acts as a client interacting with a server
at a fixed host. Data are cached at the client for performance and availability.
The cached data are considered quasi copies. The data at the fixed host are core
copies. Transactions initiated by the server are always strict. Transactions initiatcd by the client that invoke updates are always weak, while read-only client
transactions can be strict when strict consistency is required and weak otherwise. At reconciliation, weak writes are accepted only if they do not conflict
with strict transactions at the server. The frequency of reconciliation depends
on the user consistency requirements and on networking conditions.
Caching location data: In mobile computing, data representing the location of
a mobile user are fast-changing. Such data are frequently accessed to locate a
host. Thus, location data must be replicated at many sites to reduce the overhead
of searching. Most of the location copies should be considered quasi. Only a
few core copies are always updated to reflect changes in location.
One-copy serializability [4] hides from the user the fact that there can be multiple
copies of a data item and ensures strict consistency. Whereas one-copy serializability
may be an acceptable criterion for strict transactions, it is too restrictive for appli-
cations that tolerate bounded inconsistency and also causes unbearable overheads in
cases of weak connectivity. The weak transaction model described in this chapter was
first introduced in Ref. [37], while preliminary performance results were presented
inRef. [38].
Network Partitioning: The partitioning of a database into clusters resembles the
network partition problem [6], where site or link failures fragment a network of
database sites into isolated subnetworks called partitions. Clustering is conceptually different than partitioning in that it is electively done to increase performance.
Whereas all partitions are isolated, clusters may be weakly connected. Thus, clients
may operate as physically disconnected even while remaining physically connected.
Strategies for network partition face similar competing goals of availability and correctness as clustering. These strategies range from optimistic, where any transaction
is allowed to be executed in any partition, to pessimistic, where transactions in a partition are restricted by making worst-case assumptions about what transactions at other
partitions are doing. The model discussed here offers a hybrid approach. Strict transactions may be performed only if one-copy serializability is ensured (in a pessimistic
manner). Weak transactions may be performed locally (in an optimistic manner). To
merge updates performed by weak transactions, a purely syntactic approach has been
Read-only Transactions: Read-only transactions do not modify the database state,
thus their execution cannot lead to inconsistent database states. In the scheme discussed here, read-only transactions with weaker consistency requirements are considered a special case of weak transactions that have no write operations.
Two requirements for read-only transactions were introduced in Ref. 191: consistency and currency requirements. Consistency requirements specify the degree
of consistency needed by a read-only transaction. In this framework, a read-only
transaction may have: (a) no consistency requirements; (b) weak consistency requirements, if it requires a consistent view (that is, if all integrity constraints that can
be fully evaluated with the data read by the transaction must be true); or (c) strong
consistency requirements, if the schedule of all update transactions together with all
other strong consistency queries must be consistent. While the strict read-only transactions of this scheme always have strong consistency requirements, weak read-only
transactions can be tailored to have any of the above degrees based on the criterion
used for 1AS correctness. Weak read-only transactions may have: no consistency
requirement, if ignored from the IAS schedule; weak consistency, if part of a weakly
correct IAS schedule; and strong consistency, if part of a strongly correct schedule.
Currency requirements specify what update transactions should be reflected by the
data read. In terms of currency requirements, strict read-only transactions read the
most-up-to-date data item available (i.e., committed). Weak read-only transactions
may read older versions of data, depending on the definition of the d-degree.
Epsilon-seriulizability (ESR) [44, 461 allows temporary and bounded inconsistencies in copies to be seen by queries during the period among the asynchronous
updates of the various copies of a data item. Read-only transactions in this framework
are similar to weak read-only transactions with no consistency requirements. ESR
bounds inconsistency directly by bounding the number of updates. In Ref. [SO] a
generalization of ESR was proposed for high-level type specific operations on abstract
data types. In contrast, our approach deals with low-level read and write operations.
In an N-ignorant system, a transaction need not see the results of at most N prior
transactions that it would have seen if the execution had been serial [ 181. Strict transactions are @ignorant and weak transactions are 0-ignorant of other weak transactions
at the same cluster. Weak transactions are ignorant of strict and weak transactions at
other clusters. The techniques of supporting N-ignorance can be incorporating in the
proposed model to define d as the ignorance factor N of weak transactions.
Consistency-preserving execution is necessary for maintaining database consistency.
In Chapter 5 a number of commonly known concurrency control mechanisms were
discussed. This chapter investigates if any of them would work satisfactorily in mobile
database systems.
Any scheme or mechanism, such as sorting, searching, concurrency control mechanism, system recovery, etc., has system overhead. In most cases a mechanism with
least system overhead is preferred, even though it may not be efficient. This is especially true for mobile database systems where system overhead can create a serious
performance problem because of low-capacity and limited resources. This is one of
the main reasons for not considering conventional currency control mechanisms for
serializing concurrent transactions for mobile database systems. However, they do
provide a highly useful base for modified CCMs or for developing new ones. Some
of these conventional CCMs can analyzed as follows:
Locking-Based CCMs
Two-phase incremental locking and simultaneous release is the most commonly used
concurrency control mechanism. This scheme can be implemented on distributed
database systems in three different ways: (a) centralized two-phase locking (primary
site approach), (b) primary copy locking, and (c) distributed two-phase locking. It is
useful to analyze if they are suitable for mobile database systems
Centralized Two-Phase Locking: In this scheme, one site (node) is responsible
for managing all locking activities. Since the locking request traffic is likely to be very
high, the central node should be almost always available. In a mobile database system,
this requirement limits the choice of central node. A mobile unit cannot be a central
node because (a) it is a kind of personal processing unit, (b) it is not powerful enough
to manage locking requests, (c) it cannot maintain the status (locked or free) of data
items, (d) it is not fully connected to other nodes in the network, and (e) its mobility
is unpredictable. Base stations are the next choice, but they also have a number of
problems related mainly with functionality issues. A base station is a switch and
is dedicated to providing services to mobile units. Adding transaction management
functionality is likely to overload them, which would not be recommended by wireless
service providers. Theoretically, this may be the best choice, and many researchers
have selected base stations for incorporating database functions; however, in reality
this is not an acceptable solution. A fixed host can be configured to act as a central
node, but it is not equipped with a transceiver. As a result, it has to go through a base
station to reach any mobile unit. No matter what component is identified as a central
node, the problem of single-point failure cannot be avoided in this scheme.
Primary Copy Two-Phase Locking: This scheme eliminates a single point of failure and minimizes other problems of central node approach by distributing the locking
responsibility among distributed to multiple sites. Each lock manager is now responsible for a subset of data items. The node executing a part of the transaction sends
lock requests to appropriate lock manager. This approach does not solve the problem
of identifying suitable sites for distributing locking responsibility. The choices are
either base station or fixed hosts or both.
Distributed Two-Phase Locking: This scheme simply maximizes the extent of
lock distribution. Here all nodes can serve as a lock manager. In the case of database
partition this algorithm degenerates to centralized two-phase scheme. It is obvious
that this scheme does not suggest a better selection of node for lock manager.
The other acceptable option for lock manager is to include separate database servers
connected to base stations through wired network. One of the database servers can be
identified as the central node for managing transactions under a centralized scheme,
a subset of them for a primary copy scheme, and all for a distributed scheme. Out of
all options, this seems to be a middle ground.
The communication overhead for managing locking and unlocking requests is
another important problem to investigate. If a mobile unit makes a lock request on
behalf of a transaction, it is executing and then (a) it will send the request to lock
manager site (wireless message), (b) the lock manager will decide to grant or to refuse
the lock and send the result to the mobile unit (wireless message), and (c) the mobile
unit makes the decision to continue with forward processing or block or rollback
depending upon lock manager’s decision. Thus, each lock request will generate two
wireless messages, which would become quite expensive with an increase in the
workload. Furthermore, every rollback will generate an additional message overhead
by restarting the transaction.
The amount of overhead closely related to the degree of consistency the database is
programmed to maintain. To maintain stronger degree of consistency requires more
resources compared to maintaining weaker degree of consistency. Thus one way of
reducing the cost is to maintain weaker consistency level, and in many data processing
situations a weaker consistency is acceptable. This is especially true for mobile
database systems because mobile users are not likely to issue CPU-intensive large
update transactions through their mobile units. If such a transaction is issued from a
laptop, then it could be executed at database servers with the strongest consistency
It would be hard to achieve maximum benefit only through a new CCM that
maintains a weaker level of consistency. A new way of structuring and executing
ACID transactions is also necessary. Very few CCMs for mobile database systems
have been developed, and this section discuses a few of them.
Distributed HP-PPL CCM
In Ref. [28] a concurrency control mechanism called Distributed HP-2PL (DHP2PL) is presented. This CCM is based on two phase locking and it is an extension
of HP-2PL [ l ] CCM. It uses conflict resolution scheme of Cautious Waiting [19]
mechanism to reduce the degree of transaction roll-backs.
In this scheme, each base station has a lock schedular which manages the locking
requests for data items available locally. Each transaction, i.e., the holder of the
data item (Th)and the requestor of the data item (T,.)is assigned a unique priority.
Thus when a requestor and a holder conflicts then their associated priority and their
execution status (committing, blocked, etc.) are used to resolve the conflict. The
steps are as follows.
On a conflict check the priority of the holder and the requestor.
If Priority (T,) > Priority (TtJ then check the status of (Th). If ( T f Lis) not
comtnitting (i.e., still active then check if it is a local transaction.
If (TtL)is a local transaction then restart it locally. A local transaction accesses
only those data items which are stored at the base station where the transaction
If ( T h ) is a global transaction then restart it globally. A global transaction accesses data at more than one base stations. Roll-back of a global transaction
requires communicating with all those base stations where the global transaction has performed some update operations.
If (Th)is in committing process then it is not restarted rather the (Tr)is forced
to wait until (Th)commits and releases all its lock. Adjust the priority of (TtL)
as follows:
Priority (TlJ := Priority (T,) + someJixed priority level.
if Priority (T,) 5 Priority (TI,)then block (T,) until (Th)commits and releases
its locks.
A Cautious waiting approach is incorporated in the above method to minimize the
impact of disconnection and unnecessary blocking. The modified algorithm is given
If Priority (TT)
> Priority (Th)and T h is still active (not committing), then
global or local restart (TtJ.
IfTf,is a mobile client, then
I f the time T h spent at mobile unit > threshold, then ping the mobile unit.
(The ping is done by the base station to check f Tt, is active.)
I f there is no response, then restart TfL
Block T,. This check is repeated at the end of a threshold.
Else block T,. This checking is pegormed again when the time spent at
the mobile unit is > threshold.
Else Block T,
E ndq
The threshold is a function of average system performance which is used as a
tuning parameter. This acts as a timeout value which helps to decide the status of a
mobile unit. If the base station does not get a response from the mobile unit within
the threshold value, then a disconnection is assumed. This may not be true but its
effect is similar to a disconnection. The holder Th is restarted even though it has a
higher priority. This may increase the chances of missing the deadline for T,.
Two more CCMs are discussed below. One takes the approach of weaker consistency, and the other uses transaction restructuring for developing CCMs for MDS.
CCM Based on Epsilon Serializability
A CCM based on epsilon serializability (ESR) [45] is presented here, which tolerates
a limited amount of inconsistency. The mechanism is based on a two-tier replication
scheme [ 121 that produces an epsilon serializable schedule. The scheme provides
availability, accommodates the disconnection problem, and is scalable. It reduces
transactions commit time and number of transaction rejections. ESR approach keeps
the amount of inconsistency within a limit specified by epsilon. When epsdori
0, ESR reduces to conventional serializability situation. For example, in banking
database a report that prints total summary in units of millions of dollars can tolerate
inconsistency of a few hundreds dollars. Divergence control methods guarantee ESR
the same way as concurrency control guarantee serializability. The concurrency
control method that is presented here is a divergence control method to maintain ESR,
which can be applied to a database whose state space is metric, Database state space
depends on database semantics. Many practical applications with different semantics
such as bank accounts, seats in airline reservation, and so on, are examples of metric
state space. Bank database contains client names, addresses, account numbers, and
account amounts but updates happen only to amount. Metric space S is defined as a
state space having the following properties:
A distance function dist (u, v) is defined over every u, v E S on real numbers;
dist (u, v ) is the difference between u and v, which represent database states.
+ dist (v, w)= dist (u, w).
Triangular inequality, i.e., disl (u, v)
Symmetry, i.e., dist (u, I)) = dist (v, u).
In the mechanism, ESR [45,52] is used to achieve acceptable reduction in consistency. ESR is an abstract framework, and an instance of ESR is defined by concrete
specification of tolerated inconsistency. The CCM that is discussed here can also
be applied on fragmentable, reorderable objects [57], which include aggregate item,
such as sets, queues, and stacks.
The two-tier replication does not use traditional mechanisms (like two-phase locking or timestamping) and it provides availability and scalability, accommodates a
disconnection problem, and achieves convergence. The basic idea of two-tier replication is first to allow users to run tentative transactions on mobile units, which makes
tentative updates on the replicated data locally. When the mobile node connects to the
database server, then these transactions are transformed to corresponding base transactions and re-executed at the servers. The base transactions are serialized on the
master copy of the data and mobile units are informed about any failed base transactions. But the problem with this approach is that the mobile unit executes transaction
without the knowledge of what other transactions are doing. This situation can lead
to a large number of rejected transactions [3]. Another drawback is that transaction
commit at MU tends to be large because these transactions know their outcome (i.e.,
committed or rejected) only after base transactions have been executed and the results
are reported back to the MU. The CCM discussed here the two-tier replication scheme
[ 121 is modified to reduce the number of rejected transactions and to reduce commit
time of transactions executed at the MU. The BS can broadcast information to all the
MUs in its cell.
A central server holds and manages the database D = { D z } ,where i E N is set of
natural numbers and Di E S where 5’is a metric space. Let di be the current value
of the data object Di. The data objects are replicated on the MU’S and let ni be the
number of replicas of Di in MDS. A limit A on the amount of change can occur on
the replica at each MU, thus Ai denotes the change allowed in each replica of data
object Di on any MU. If the transaction changes the value of the data item by at most
Ai in a MU, then they are free to commit; they do not have to wait for results of
the execution of the base transaction on DBS. This reduces the commit time of the
transactions and also the number of rejected transactions, which could happen due to
the base transaction not being able to commit. To control the validity of Ai, a timeout
parameter is defined whose value indicates a duration within which the value of A,;
is valid. Timeout values of the data item should be some multiple I of broadcast
cycle time T . The value I depends on the frequency of the incoming updates for
the data item, and also it should be sufficiently large so that the Mu’s can send their
updates within duration 1 x T . The server will not update the value of the data item
until time I x T has elapsed. It is assumed that the MUs take into consideration the
uplink time and send their updates before the timeout expires at the server. The client
can disconnect from MDS during the timeout period and can perform updates. If the
client disconnects for a period longer than timeout, then when it reconnects it should
read the new values of A. If the updates are within the new limit set by A, then the
MU can send the updates to the server; otherwise the MU will have to block some
transactions so that total updates are within A. The blocked transactions will have
to wait until the new values of A arrive at the MU. The steps of the algorithm go as
At a DBS
1. A, is calculated for each data object D,. A2 is calculated using the function
A, = .f, (d,, n L ) A
. function f,(d,, n,) is associated with each data object D,,
and it depends on the application semantics.
2. A timeout value T is linked with A, values of the data item.
3 . DBS broadcasts the values of ( d 2 ,A,) for each data item and a timeout
these values at the beginning of the broadcast cycle.
4. The DBS either receives pre-committed transactions (transactions which have
made updates to the replicas on the MU and committed) or can receive request
transactions (transactions which are directly sent to the DBS by the MU). A
transaction that violates the limit is not executed at an MU, because it could
change the value of replica D, by more than A, at the MU. It is sent to the DBS
as request transaction for execution on the master database.
5 . The DBS serializes the pre-committed transactions according to their order
of arrival. After the timeout expires, the DBS executes a request transaction,
reports to the MU whether the transaction was committed or aborted, and
repeats the procedure from the first step.
MU has the value of (&, A,) and timeout T for every data item Di it has cached.
MU executes transaction t,. It changes the current value of D, by A,-tt. Let
A,-ci be the current value of the total change in D, since its last broadcast of
value A,).
The value A7-tt is added
The following cases are possible depending
on the value of A,-tz and AZpc:
1. If A7,-tt 5 Ai and Ai-c 5 Ai, then t , is committed at MU and it is sent
to DBS for re-execution as a base transaction on the master copy.
2. If
5 Ai and Ai-c > A,L,then t , is blocked at MU until new set of
( D i ,Ai) is broadcasted by the server.
3. If A t - t c> Ai then t , is blocked at MU and submitted to the server as a
request transaction.
Relationship with ESR
The mechanism for maintaining ESR has two methods: (a) divergence control (DC)
and (b) consistency restoration. This section discuses these methods and show their
use in developing the concurrency control mechanism.
A transaction imports inconsistency by reading uncommitted data of other trancactions. A transaction exports inconsistency by allowing other transaction to read
its uncommitted data. Transactions have import and export counters. The following
example shows how these counters are maintained.
In the above execution, t z reads from t l . So it is counted as tl exporting one
conflict to t 2 and tz importing one conflict from t l . So an export counter of tl is
incremented by 1, and an import counter of t 2 is incremented by 1. Transaction t:3
does not import or export any conflicts. The divergence control (DC) method sets
limit on conflicts by using import and export limits for each transaction. Thus, update
transactions have export limit and query transactions (read-only) have import limit,
which specify the maximum number of conflicts they can be involved in. When import
limit > 0 and export limit > 0, then successive transactions may introduce unbounded
inconsistency. For example, tl may change the value of a data item by a large amount
and t 2 will read this value and operate on it as import and export counters are not
violated. Later if tl aborts, t z would have operated on a value that was deviated from
consistent value by a large amount. This situation requires consistency restoration,
which is done by consistency restoration algorithms.
In this concurrency control mechanism, DC sets limits on the change allowed in
each data item value at MU and does not allow transactions to violate this limit. If it
does, then it is sent as a request transaction to DBS for execution. In this scheme a
transaction at MU will see an inconsistent value of data item for a maximum period
of T (the timeout period) after which it receives new consistent values of the data
items. During T , the value of data item di may diverge from the consistent value
by a maximum of N , x Ai, where Ni is the number of replicas of d i . In this way
transactions are allowed to execute on inconsistent data item but the inconsistency
in data value is bounded by Ni x Ai. So in this CCM the DC includes the function
f i ( d i ; ai),which calculates Ai for each d, and also for the algorithm executed at MU
to execute transactions. Thus, the consistency restoration includes the execution of
request and pre-committed transactions at DBS and broadcasting of the consistent
value of the data item to the MU.
This example explains the working of the CCM discussed in this section. Figure 7.12 illustrates the execution of concurrent transaction under this CCM.
Suppose a data item X represents total number of movie tickets. X belongs to
metric state space. Let N , be the number of replicas of X . Initially suppose
A' = 180 and N , = and X is replicated at MU1, MU2 and MU3. The functions
f x ( X , N,) that calculates A, is A, = f z ( X , N z ) = ( X / 2 ) / N , = X / 2 N z =
30. Here X is divided by 2 to keep some tickets for the request transaction,
which cannot be executed at the MU. This function depends on the application
semantics and the policy the application developer wants to follow. Each data
item will have different function depending on the semantics of that data item.
X , T ) , where 7 is timeout within which the MU should send committed
transaction for re-execution at the server, is broadcasted by the DBS server to
MU'S. The following three cases arise:
Case 7: Transactions t l , f2, and f 3 arrive at MU1, MU2, and MU3, respectively. Consider the case where t~ books 20 ticket3, t 2 books 30 tickets, and
t 3 books 40 tickets. Figure 7.13 shows the state of the system at this instant.
Suppose A, repreqents change in value of data item X . Each MU that has a
replica of X will maintain the value As-c.
At MUl: Initially
= 0.
books 20 tickets, so AT- t , = 20 and AT-< =
+ A,-,, = 20. As A, -c
< A,, tl is committed at MU1 and so X is updated to 160 and tl is sent to
DBS for re-execution on the master copy.
At MU2: Initially Az-c = 0
books 30 tickets, so A,-,, = 30 and
= AxPC+ & - t 2 = 30. As AL-c
t 2 is committed at MU2 and X is updated to 150 and t a is sent to DBS
for re-execution.
< A,,
At MU3: Initially
= 0.
Ax--ts = 30 and Ax-c = AxPC+
= 40.
Since Axcc > A,, t 3 is not executed at MU3 and is sent as request transaction
to DBS for execution.
t 3books 40 tickets and makes
DBS receives t n , t 2 , and tl in this order. Since t 3 is a request transaction,
it is executed after timeout 'T has expired and after the execution of t 2 and
t l on the master copy. So the execution at DBS is X = 180, t 2 , X = 150, 21,
X = 130, t 3 , X = 90; and after the execution, A is recomputed using the function
.fx;(X,N,). Thus, A, = f z ( X ,N,) = X / 2 N , = 15. The DBS broadcasts (X =
90, A, = 1 5 , ~and
) each MU now can update the value of X by not more that
15 and sends the transaction for re-execution within T . Figure 7.13 illustrates
case 1.
x = 90
X = 180
X = 160
X = 150
x = 180
(a) Transactions are sent to the server
(b) New values of A and X are broadasted
Fig, 7.13 Intermediate state in CCM.
Transactions on MU see an inconsistent value of the number of tickets only
for period T ; after that, DBS sends their consistent value. The transactions
that want to know number of tickets available will get an approximate value
of number of tickets. Inconsistency in the value of data objects is bounded by
refreshing the data object value at a regular interval of 7 and setting a limit on
A on the maximum update that can be made during that period.
Case 2: MU3 receives the values ( X = 90, A, = 15, T ) from the DBS. For
every new timeout value, Ax-C is reset to zero. Transactions t 4 and t 5 arrive at
MU3. t 4 books 10 tickets and t,5 books 8 tickets. Suppose the execution order
is t 4 , t 5 . After the execution of t 4 , & - t 4 = 10 and Ax-c = Ax-c + A,-t4 = 10.
As As-c < A,, t 4 is executed at MU3 and is sent to the DBS for re-execution.
Before 7 expires, transaction t 5 arrives at MU3 where A,I:-,, = 10 and A:,;-c =
8. This makes AZcc= Ax-c + Ax-ts = 18. As Ax-C > A,, t 5 is not executed
at MU3 and sent to DBS for execution as a request transaction.
Case 3: MUs receive values ( X = 80, A, = 0, 'T) from DBS. t 6 arrives at
MU2 and books 2 tickets. At MU2 initially, Axcc = 0. t 6 books 2 tickets and
makes Arc--ta= 2. At this point,
= A x pc + Ax-t6 = 2. As Axpc > A,,
tBis not executed at MU2 but is sent as a request transaction to the DBS.
All update transactions that arrive at MU will be sent to DBS as request
transaction because no change is allowed to the replica at MU since A, = 0.
Only read transactions at MU can access data item X .
The distributed execution of a transaction requires collaboration among nodes to
commit the transaction. The collaboration is initiated and managed by the coordinator,
which makes sure that every subtransaction is executed successfully and ready to
commit. If any of its subtransactions cannot commit, then the parent transaction is
aborted by the coordinator.
The entire process of commit has two phases: (a) checking the intention of each
node participating in the execution of a transaction (participants) and (b) collecting
the intensions of participants and committing the transaction. The entire process is
atomic, and the commit protocol is referred to as Atomic Commitment Protocol (ACP).
The most common ACP used in conventional distributed database systems is called
a Two-Phase Commit (2PC) protocol. There is a Three-Phase Commit (3PC) protocol
[4] which claims to be more efficient than 2PC but requires a higher number of
messages compared to 2PC for making a commit decision. So far, no system has
implemented 3PC, but it continues to be an interesting research topic.
7.14.1 Two-Phase Commit Protocol - Centralized 2PC
A distributed database system with multiple nodes is assumed to describe 2PC. A
transaction T, originates at a node which assumes the role of coordinator for T,.
The coordinator fragments T, and distributes them to a set of participants. The
coordinator may or may not keep a fragment for itself. Thus a coordinator and a
set of participants together executes T, leading either to a commit or to an abort as
decided by the coordinator. The protocol makes sure of the following:
Participants’decision: All participants reach a decision for their fragments.
All decision can be either Yes or No.
Decision change: A participant cannot change its final decision.
Coordinator’s decision: The coordinator can decide to commit Ti only if all
participants and the coordinator agree to commit their subtransactions. It is not
that in this situation the coordinator has no other option than to decide commit;
it can still abort the transaction.
When the failure scenario is included, then the following additional steps are
required for making some decision.
No failure: In the absence of any failure, if all processing nodes (participants
and coordinator) agree to commit, then the coordinator will commit T,.
With failure: Failure of one or more participants or the coordinator may delay
the decision. However, if all failures are repaired within acceptable time,
then the coordinator will reach a decision. This identifies the non-blocking
property of centralized 2PC. The non-blocking property is essential for any
APC. However, it may not be strictly enforced; that is, a failure may generate
infinite blocking situation.
The working of centralized 2PC is described in the following steps [4]:
I . Transaction fragmentation and distribution: A transaction T, arrives to a
node. This node servers as the coordinator for T I . The coordinator fragments
Ti into subtransactions and distributes these fragments to a set of participants.
These nodes begin executing their subtransactions of Ti.
First phase of centralized 2PC - Voting phase
2. Voting: The coordinator multicasts a message (vote request - VR) to all participants, asking them to vote if they can commit their subtransaction of Ti,
3. Participants’ vote: When a participant receives VR message from the coordinator, it composes its response (vote) and sends it to the coordinator. This
response can be a Yes or a No. If the vote is Yes, then the participant enters into
an “uncertainty” period after sending it to the coordinator. During this period
a participant cannot proceed further (make any unilateral decision in behalf of
its subtransaction of Ti) and just waits for an abort or commit message from
the coordinator. If the vote of the participant is No, then it does not wait for
coordinator’s response and aborts its subtransaction and stops.
Second phase of centralized 2PC - Decision phase
4. Commit decision and dispatch: When the coordinator receives votes from all
participants and has its own vote, it performs an AND operation among these
votes. If the result is aYES, then the coordinator decides to commit otherwise
it decides to abort Ti. It multicasts the decision to all participants and stops.
5. Participants decision: All participants receives a coordinator’s decision and
act accordingly. If the decision is to abort, all participants abort their fragments
and then stop.
Node Failure and Timeout Action
In order to make sure that the non-blocking property of centralized 2PC is effectively
implemented, the occurrences of infinite wait because of node failure must be dealt
with. One of the schemes to enforce non-blocking property is to use timeout action. A
timeout value identifies how long aparticipant should wait for the anticipated message
before its takes some action.
In the description of centralized 2PC participants wait for VR messages from the
coordinator at the beginning of step 3, and the coordinator waits for participants’ Yes
or No decision at the end of step 3. Similarly, all participants either wait for the
coordinator’s commit or abort message in step 5 . If a participant times out at the
beginning of step 3, then it can unilaterally decide to abort because it is not in its
uncertainty period. At the end of step 3, the coordinator may time out waiting for Yes
or No messages from some or all participants. It may decide to abort and send abort
messages to those participants who did not send their vote and who send Yes votes.
The timing out of participants at the beginning of step 4 is more involved because
participants are in their uncertainty period and they cannot change their vote from
Yes to No and abort their subtransactions. It is possible that the coordinator might
have sent the commit message and it reached only to a subset of participants. If a
participant times out in its uncertainty period and decides to abort, then it would be
a wrong action. To take care of this immature abort by a timed-out participant, a
cooperative termination protocol can be used. A cooperative termination protocol
helps a participant to gather information about the last message from the coordinator
which this participant missed and timed out.
Cooperative Termination Protocol: When a participant in uncertainty period fails
to receive a commit or abort message from the coordinator, then it has two options: (a)
Ask the coordinator about its last message or (b) Ask one of is neighbor participants.
In case (a) if the coordinator is available to respond, then it can get the desired
information and decide accordingly. To use (b), every participant must know the
identity of all other participants. This can be easily provided by the coordinator at
the time of sending an VR message in step 2. The following three cases arise when
(b) is used:
1. Participant P1 asks P2 about the final outcome. If P2 has decided to commit
or abort (it did receive coordinator’s decision message), then it can inform PI
about its decision and P1 can act accordingly.
2. P2 is not in uncertainty period and has not voted yet. It decided to abort and
informs P1. P1 also aborts.
3. P2 has votedyes but has not received a decision from the coordinator either. P2
is in a similar situation, that is, it timed out in its uncertainty period as P1 and
cannot help. P1 and P2 can continue to ask other participants, and hopefully at
least one participant might have received the coordinator’s decision. It informs
P1, and PI acts accordingly and so does P2. If a11 participants are timed out
and did not get coordinator’s decision, then possibly the coordinator has failed
and they can abort and stop.
The performance of a commit protocol largely depends on the number of messages
it uses to terminate (abort of commit) a transaction. To evaluate the cost of communication, two parameters are used: (a) time complexity and (b) message complexity.
Time Complexity: This parameter evaluates the time to reach a decision. It includes
the time to complete a number of other necessary activities such as logging messages,
preparing messages, etc. A smaller value is highly desirable. The decision time in the
absence of any kind of failure (coordinator or participants of both) is obviously smaller
compared to the time with failure. In the absence of failures, the protocol uses three
message rounds. A message round is the total time the message takes to reach from
its source to the destination. The first message round is the broadcast of VR messages
to the participants from the coordinator; in the second round, all participants send
their votes; and in the third round the coordinator broadcasts its decision (commit or
abort). In the presence of failures, two additional rounds are required: (a) a timed-out
participant enquires the coordinator’s decision and (b) a response from a participant
who received coordinator’s decision (this participant is out of its uncertainty period).
Thus with no failure of any kind, three message rounds-and with failure, five message
rounds-are required to terminate a transaction.
Message Complexity: Message complexity evaluates the number of message exchanged between destinations and sources to reach a decision. In a centralized 2PC,
message exchange takes place between one coordinator and n, participants when there
is no failure. The total number of messages exchanged is 3n, in the three steps of the
The coordinator sends VR message to 12 participants = n messages.
Each participant sends one vote message (Yes or No) to coordinator = rr vote
The coordinator sends decision message to ‘II participants = 12 messages.
In the presence of failure, each timed-out participant who voted Yes initiates
cooperative termination protocol. In the worst-case scenario, all participated
could be timed out and initiate the protocol. If there are m, such timed-out
participants with Yes vote, then 711 5 n,.
rr), participants will initiate the protocol and send n - 1 decision request messages. The requestor participant rn,? will get a response from at least one of the
‘rt, participants and would come out of its uncertainty period. This cycle will
continue until m participants come out from their uncertainty period. The total
number of messages used in this entire process will be
m(n,- 1) +
C(n m,+ i )
2 m ( n - 1)
rnd2/2 m / 2
To minimize the time or message complexity or both, two variations of 2PC
exist: (a) decentralized 2PC and (b) linear or nested 2PC.
Decentralized 2PC
In this scheme the coordinator minimizes the message complexity by sending its vote
along with VR message to participants. If the coordinator’s vote is No, then participants know the decision and abort their subtransactions and stop. If the coordinator’s
vote is Yes, then each participant sends its vote to all other participants. After receiving all votes, each participants decides. If all votes are Yes, then the transaction
commits; otherwise it is aborted.
Time Complexity: In a decentralized 2PC there are two message rounds: (a) The
coordinator sends a VR message and its vote, and (b) the participant sends its Yes vote
and transaction commits. When the coordinator sends its Yes vote to participants, it
implies that “I am ready to commit and if you are also, then go ahead and commit”
and, therefore, there is no need for the coordinator to send a Commit vote. Thi\
reduces one message round compared to centralized 2PC.
Message complexity: The reduction in time complexity unfortunately increases
the message complexity. In a centralized 2PC the coordinator makes the final decision
but in distributed 2PC everybody participates in the decision process. This requires
that each participant communicates with all other participants to know their votes. If
there are n participants, this process requires nz messages. Thus the total number
of messages to commit a transaction in failure as well as in no failure cases is n 2
(participant to n - 1 participants) + n (coordinator to n participants). In the case
of n > 2, decentralized 2PC always takes a greater number of messages than a
centralized 2PC.
Linear or Nested 2PC
In linear 2PC the message complexity is reduced by collecting votes serially. All
participants and the coordinator are ordered linearly. Each participant has a left and
a right neighbor and a coordinator has only one neighbor. Figure 7.14 illustrates the
Fig- 7.74 Linear ordering of participants and coordinator.
The protocol works as follows:
1. The coordinator sends its Yes or No vote to participant
2. PI performs Coordinator’s vote A PI’Svote = X . X =Yes or No.
3. PI sends X to 1’2 and the process continues until the result reaches to P,
4. If the outcome of P, computation is Yes, it decides to commit and sends this
message to P,,- 1 .
5. The return message containing the commit decision finally reaches to the coordinator and completes the commit process.
Time Complexity: There is no message broadcast in a linear 2PC, so it requires the
same number of rounds as the number of messages to make the final decision. Thus
with n participants it will require 2.n rounds, which is much larger than centralized
and decentralized 2PC.
Message Complexity: With n participants, this protocol requires 2n messages: n
forward messages and n return messages which is much smaller than the message
complexity of decentralized and centralized 2PC.
Table 7.6 compares the message and time complexity of centralized, decentralized,
and linear 2PC with no failure. It is hard to identify the most efficient protocol for
all systems because of the wide ranging values of parameters such as message size,
communication speed, processing delay, etc., which are highly system-dependent.
However, it can be seen that the centralized 2PC offers a good compromise.
Table 7.6 Message and time complexity in various 2PC
n2 + 'n
2 n,
7.15.1 Commit Protocols for Mobilaction
The mobility and other characteristics of MUs affect Mobilaction processing especially its commitment. Some of the common limitations are: (a) An MU may cease
to communicate with its BS for a variety of reasons, (b) it may run out of its limited battery power, (c) it may run out of its disk space, (d) it may be affected by
airport security, (e) physical abuse and accident, (f) limited wireless channels for
communication, and (8) unpredictable handofs.
A mobile computing environment creates a complex distributed processing environment; therefore, it requires a distributed commit protocol. We have assumed the
two-phase commit approach as the basis of developing our mobile commit protocol.
One of the essential requirements of distributed processing is that all subtransactions
of T, must be ready to commit. In MDS a complete knowledge of this state becomes
relatively more complex because of mobility. It is crucial that the scheme to acquire
this knowledge must use minimum message communication, and it is also important
that this scheme should not be dependent on the mobility of the involved M U s .
The different types of data (temporal and spatial) in mobile computing provide
more freedom in designing commit protocols. Like conventional distributed database
systcms, a transaction in MDS may be processed by a number of DBSs and MUs;
therefore, some commit protocol is necessary for their termination. Legacy commit
protocols such as 2PC (two-phase commit), 3PC (three-phase commit) 141, etc., will
not perform satisfactorily mainly because of limited resources, especially wireless
channel availability. For example, the most commonly used 2PC uses three message
rounds in the case of no failure and uses five in the case of failure for termination [4].
Note that it requires additional support (use of timeout) for termination in the presence
of blocked or failed subtransactions. Thus, the time and message complexities are too
high for MDS to handle and must be minimized to improve the utilization of scares
The mobility of MU adds another dimension to these complexities. It may force
MDS to reconfigure the initial commit setup during the life of a transaction 1221. For
example, a proper coordination among the subtransactions of a transaction under a
participants-coordinator paradigm may be difficult to achieve with the available resources for its commitment. Mobile database systems, therefore, require commitment
protocols which should use a minimum number of wireless messages, and M U and
DBSs involved in T, processing should have independent decision-making capability
and the protocol should be norz-blocking [4].
The mobility and other characteristics of MUs affect transaction processing, especially
its commitment. Some of the common limitations are: (a) An MU may cease to
communicate with its BS for a variety of reasons, (b) it may run out of its limited
battery power, (c) it may run out of its disk space, (d) it may be affected by airport
security, (e) physical abuse and accident, (f) it has limited wireless channels for
communication, and (g) unpredictable handofl.
Like conventional distributed database systems, a transaction in MDS may be
processed by a number of nodes such as DBSs and MUs; therefore, some commit
protocol is necessary for their termination. Conventional commit protocols such as
2PC, 3PC [4], etc., could be molded to work with MDS; however, they will not perform
satisfactorily mainly because their resource requirements may not be satisfied by MDS
on time. For example, the most commonly used centralized 2PC uses three message
rounds in the case of no failure and uses five in the case of failure for termination
[4]. It requires additional support (use of timeout) for termination in the presence of
blocked or failed “subtransactions.” Thus, the time and message complexities are too
high for MDS to handle and must be minimized to improve the utilization of scares
resources (wireless channel, battery power, etc.)
The mobility of MU adds another dimension to these complexities. It may force
MDS to reconfigure the initial commit setup during the life of a transaction [2 1,22,23].
For example, a proper coordination among the subtransctions of a transaction under
participants-coordinator paradigm may be difficult to achieve with the available resources for its commitment. For example, a mobile unit may not receive coordinator’s
vote request and commit messages and it may not send its vote on time because of
its random movement while processing a subtranaction. This may generate unnecessary transaction aborts. These limitations suggests that MDS commit protocol must
support independent decision-making capability for coordinator and for participants
to minimize cost of messages. A new commit protocol is required for MDS which
should have the following desirable properties:
It should use a minimum number of wireless messages
MU and DBSs involved in T, processing should have independent decisionmaking capability, and the protocol should be non-blocking.
An analysis of conventional commit protocols indicates that timeout parameter
could be used to develop a commit protocol for MDS. In conventional protocols,
timeout parameter is used to enforce non-blocking property. A timeout identifies
the maximum time a node can wait before taking any decision. The expiration of
timeout is always related to the occurrence of some kind of failure. For example, in
conventional 2PC the expiration of timeout indicates a node failure and it allows a
participant to take a unilateral decision.
If a timeout parameter can identify a failure situation, then it can also be used to
identify a success situation. Under this approach the end of timeout will indicate a
success. The basic idea then is to define a timeout for the completion of an action and
a s u m e that at the end of this timeout the action will be completed successfully. For
example, a participant defines a timeout within which it completes the execution of
its subtransaction and sends its update through the coordinator to DBSs for installing
it in the database. If the updates does not arrive within timeout, then it would indicate
a failure scenario. The coordinator does not have to query the participant to learn
about its status.
Recently timeout parameter has been used in a nonconventional way for developing
solutions to some of the mobile database problems. This section presents a commit
protocol which is referred to as Transaction Commit on Timeout (TCOT) [21,22]. It
uses timeout parameter to indicate a success rather than a failure.
The TCOT protocol is discussed below in detail. A transaction T, is fragmented
into several subtransactions, which are distributed for execution among a number of
DBSs and the MU where T, originated. These nodes are defined as Commit Set of
T,; the MU where T, originates is referred to as Home MU ( n / f U ~ )and
; the BS of
ILIU~Jis referred to as Home BS ( B S H ) .
Definition 7.21 A commit set o f a T, is dejined as the set of DBS and the M U H ,
which take part in the processing and commit of T,. A DBS is identijied as a static
rnembel; and the MU is a mobile member of a commit set.
TCOT strives to limit the number of messages (especially uplink). It does so by
assuming that all members of a commit set successfully commit their fragments within
the timeout they define after analyzing their subtransactions leading to commit of T,.
Unlike 2PC or 3PC, no further communications between the CO and participants take
place for keeping track of the progress of fragments. However, the failure situation
is immediately communicated to CO to make a final decision.
It is well known that finding the most appropriate value of a timeout is not always
easy because it depends on a number of system variables, which could be difficult to
quantify. However, it is usually possible to define a value for timeout, which performs
well in all cases. An imprecise value of timeout does not affect the correctness but
affects the performance of the algorithm.
Every CO (new or existing) must know the identity of each member of a commit
set. Every ~ I U H
stores the identity of it5 current CO for each transaction requested
there. When M U H moves to.another cell, then during registration it also informs the
BS about its previous CO. As soon as M U F Isends T, to B S R , the latter assumes the
role of CO for T,. In the dynamic approach also the transfer of CO does not require
extra uplink or downlink messages because the notification process is a part of the
Types of Timeout
TCOT protocol uses two types of timeout: Execution Timeout ( E t )and Update Shipping Timeout (&).
Execution Timeout (Et): This timeout defines a value within which a node of
a commit set completes the execution (not commit) of its execution fragment or
subtransaction e i . It is an upper bound of the time a DBS or the ~ L ~ Urequires
complete the execution of ei.
The CO assumes that the M U H or a DBS will complete the execution of its ei
within Et. The value of Et may be node-specific. It may depend on the size of ei and
the characteristics of the processing unit; thus, E t ( M U i ) may or may not be equal
to Et(APUj), ( i # j ) . We identify M U H ’ stimeout by & ( M U ) and identify DBS’s
timeout by E , ( D B S ) . The relationship between these two timeouts is & ( M U )
= E t ( D B S ) &A. The A accounts for the characteristics such as poor resources,
disconnected state, availability of wireless channel, etc., compared to DBS. It is
possible that a MU may take less time than its Et to execute its e i . We also do not
rule out the possibility that in some cases Et(DBS) may be larger than E t ( M U ~ ) .
Et typically should be just long enough to allow a fragment to successfully finish its
entire execution in a normal environment (i.e., no failure of any kind, no message
delay, etc.)
Shipping timeout (St): This timeout defines the upper bound of the data shipping
time from M U H to DBS.
In E t , the cached copy of the data is updated at the MU. To maintain global
consistency, all data updates done by the M U H must be shipped and installed at the
database located at DBS. Thus, at the end of Et the CO expects the updates to be
shipped to the DBS and logged there within St.
7.1 6.1 TCOT Steps-No Failure
In TCOT three components, M U H , CO, and DBSs, participate. The steps in the
absence of any kind of failure are:
Activities o j b l U ~ :
- A Ti originates at MUf1. The B S H is identified as the CO. AJUt, extracts
its ei from T?,,computes its Et, and sends Ti - ei to the CO along with
the Et of c i . M U H begins the processing of e i .
- While processing
e i , M U H updates its cache copy of the database, composes update shipment, and appends it to the log.
- During processing, if it is determined that e, will execute longer than Et,
then M U H extends its value and sends it to CO. Note that this uses one
extra uplink message. The frequency of such extension requests can be
minimized with a careful calculation.
- If the local fragment ei aborts for any reason, then M U f , sends an Abort
message to CO (failure notification).
- After execution of ei M U H sends log of updates to the CO. The updates
must reach to CO before St expires. It could be possible that updates may
reach CO much earlier, in which case it may decide commit sooner.
- In the case of read-only
e i , M U H sends a commit message to CO. This
is not an extra message, it just replaces shipping update message.
- Once the updates are dispatched to CO, M U H declares commit of e,.
Note that the underlying concurrency control may decide to release all
the data items to other fragments. If for some reason Ti is aborted, then
fragment compensation may be necessary.
- If M U H fails to send updates to CO within SLand it did not extend E t ,
then the CO aborts e,.
Activities of CO:
- Upon receipt of T, - e, from M U H ,the CO creates a token list for Ti,
which contains one entry for each of its fragments. Figure 7.15 shows a
token list entry for et of Ti. In the case of CO change, a token is used to
inform the new CO the status of fragment and commit set members. The
CO splits Ti - e, into e,7’s(i # j ) and sends them to the set of relevant
e, E, (MU,) or E, (DBS,) Coordinator Id Commit s A ,
Fig. 7.75 An entry of a token list.
- After receiving Et from a DBS, the CO constructs a token for that fragment
and keeps it for future use.
- H a new Et (extension) is received either from M U J , or from a DBS, then
the CO updates the token entry for that fragment.
- CO logs the updates from M U H .
- If the CO has MUH’Sshipment before St expires and commit messages
from other DBSs of the commit set, then the CO commits T,. At this
time the updates from the M U H are sent to the DBSs for update to the
primary copy of the databases. Note that no further message is sent to
any member of the commit set of T,.
- If CO does not receive updates from M U H within the timeout or does
not receive commit message from any of DBSs of the commit set, then
it aborts T, and sends a Global Abort message (wired message to DBSs
and wireless to MU) to those members of the commit set who committed
their fragments.
Activities of DBS:
- Each DBS, upon receiving its fragment, computes Et and sends it to the
CO. DBS begins processing its fragment and updates its own database.
- If it is determined that the fragment will execute longer than Et, then this
value is extended and the new value is sent to the CO.
- At the end of e,,
it sends a “commit message” to the CO.
- If DBS cannot complete the execution of its e, for any reason and did not
extend Et, then it sends an Abort message to the CO.
Discussion: One may argue that either Et or the “commit message” is sufficient
for making a commit decision. This is not entirely correct. Et identifies when a
fragment will finish its execution and will be ready to commit. Thus, at the end of
Et, CO will assume that the DBS has committed its fragment, which may not be true
(fragment may not have been processed because of the failure of the DBS). Since
a DBS does not ship updates, it must use a message for informing the status of the
fragment. On the other hand, if there is only “commit message,” then the CO could
never get this message from a DBS for some reason and wait for ever to make the
final commit decision. Thus, for making the final decision and doing it efficiently,
both Et and “commit message” are necessary. Note that a DBS communicates with
the CO through wired channel and any extra message does not create any message
TCOT, unlike 2PC, has only one phase commit operation. No vote-request or
commit message is sent to commit set members. The task assignment message to
these members provides necessary information and directives for completing commit. Only in the case of abort, one extra wireless message is used. In reality, not
many transactions are aborted and this extra message not likely to generate noticeable
In the case of a read-only fragment, M U I does
~ not send any update to the CO;
but similar to a DBS, it sends only a “commit“ message.
Node Failure-Fragment Compensation
The process of compensation is not related to commit; rather, it comes under recovery
[ 171 but it becomes an issue for long running transaction. In TCOT a member of
TL’scommit set may commit its fragment, and the underlying concurrency control
(two-phase locking scheme is assumed) may decide to release its data items to other
concurrent fragments before the CO declares the commit of T,. For example, if e, (77%)
is committed by MUITbut T, is aborted, then e, must be compensated. When M U I I
receives a message to abort e, from the CO, then, if possible [17], a compensating
transaction for e7 is executed. At the end of compensation, MU11 informs CO and
sends new updates if there is any. Figure 7.16 illustrates the relationship among Et ,
St,abort, and compensation. After St the M U H can make data items available to t‘,
(1 # 3 ) . This means that after St an e, may be compensated.
e, can be aborted
e, can be aborted
Execution timeout (E,)-
Shipping timeout (S,)
Data available to ei
e, may be compensated
Fig. 7.16 Relationship between l3t and St, abort, and compensation.
7.1 6.3 TCOT with Handoff
Updates from M U H and dispatch of commit message from DBSs in the case of a
handoff must be sent to the right CO if it changes. The change in CO is notified using
a token. The following steps define the commit process in the presence of a handoff.
M U H moves to a different cell and it registers with the new BS.
If MDS employs dynamic selection of CO, then the M U H sends the identity
of its last CO in the registration process and accepts the new BS as its next
CO. The new BS gets the token from the last CO, which provides necessary
The new CO identifies other members of the commit set from the token and
notifies them about the change of CO. Note that the communication between
the new CO and DBSs is through wired channel. The processing of T, resumes
A doze mode of M U H will mainly affect its Et. M U H may not be aware of its
movement, but it knows when it enters into the doze mode. Therefore, before entering
doze mode, M U H can always request for extension to its Et. If granted, then the
fragment will not be aborted; otherwise a global abort will be initiated.
7.16.4 Special Cases
A number of special cases may arise during commit, and TCOT manages them as
St expires before DBSs sends commit message: It is possible that M U H
commits its ei and sends its updates to the CO, before DBSs send their commit
messages to the CO. In this case the CO will wait for the commit messages.
DBSs send commit messages before St expires: The CO will wait for St to
expire before making any decision.
SLexpires but no updates or no commit message: The CO will send abort
message to the members of the commit set.
Note that the abort could be received at any time. If it is received prior to commit,
then a local abort with corresponding undo is needed. If, however, it is received
after the local commit, then a compensation is needed. Further, when a fragment
is executed, the decision to commit or abort is made locally. However, the implicit
assumption is that a global commit occurs.
7.1 6.5
An Alternate TCOT Protocol
In the first version of TCOT, M U H is responsible for extracting ei from Ti, computing
El, and sending Ti ei to the CO. In this approach, every Ti is examined by M U H ,
which is not necessary. This can be improved by sending the entire Ti to the CO and
letting the CO do the fragmentation, estimate Et , and send the information back to
M U H . This will use one extra wireless downlink message but reduces the workload
of M U , since many Ti’s may not be processed by M U H . The other advantage of
this is related to token passing. The CO can send the token to M U H , which in turn
can send it to the new CO during registration. The steps, which differ from the first
version of TCOT. are:
M U H forwards Ti to the CO.
The CO fragments Ti, computes Els of all the fragments, creates tokens, and
sends them to the members of the commit set. (This step uses one extra downlink message)
computes St for its fragment.
7.16.6 Correctness
A commit decision by a CO is said to be “correct” if the decision to commit is
unanimous. Suppose the CO decides to commit Ti when at least one member of the
commit set is undecided. This is possible only if the CO declares commit before the
expiration of either S, or absence of commit message from at least one DBS. This,
however, cannot happen. Further, suppose that the M U H failed and could not send
updates to the CO within St or the "commit message" is not received by the CO. In
this situation, the CO will abort T,. Since our algorithm is based on timeout, it is not
possible that at any stage the CO will enter into an infinite wait.
This chapter introduced a reference architecture of mobile database system and discussed a number of transaction management issues. It identified a number of unique
properties of mobile database system and discussed the effect of mobility on its functionality.
It demonstrated that location of the database and the location of the origin of
the query must be considered to enforce ACID properties of transactions. To handle
these requirements, the concept of Location Dependent Data and Locution Dependent
Commit were introduced. Thus in mobile database systems a user initiates (a) a
location-dependent query, (b) location-aware query, or (c) a location-independent
query. The concept of data region was introduced to accommodate cellular structure
in mobile database processing and transaction commit.
It identified unique system requirements for concurrency control mechanisms and
transaction commitment. First it analyzed the relationship between mobility and
transaction processing. A clear understanding of this relationship is necessary for the
development of mobile transaction model and its management.
It argued that conventional 2-phase or 3-phase commit protocols were not suitable
for mobile database systems and illustrated that a commit protocol which uses least
number of messages and offer independent commit decision capability was highly
desirable. It introduced one-phase commit protocol with above properties.
A data replication scheme for connected and disconnected operations was discussed for mobile database \ystem. Under this scheme, data located at strongly
connected sites are grouped in clusters. Bounded inconsistency was defined by requiring mutual consistency among copies located at the same cluster and controlled
deviation among copies at different clusters. The database interface is extended with
weak operations.
This chapter provided necessary material for the development of mobile database
system framework and mobile transaction model.
1. Highlight the essential differences of mobile database system with conventional
database systems. What are the problems in using mobile units or a base station
or a fixed host as (a) a client, (b) a server, or (c) a peer?
2. Consider the architecture of a given mobile database system. What types of
scenario a transaction may encounter during its execution? Explain your own
ideas in managing these situations successfully.
3. Develop your own mobile transaction model and a way of executing them on
a mobile database system.
4. Implement a strict two-phase locking mechanism in a mobile database system
and count the total number of messages it requires to (a) commit a transaction,
(b) roll-back a transaction, and (c) execution a transaction (not commit).
5. Consider modifying TCOT to manage transaction failure more efficiently.
1. R. J. Abbott and Hector Garcia-Molina, “Scheduling Real-Time Transactions: A
Performance Evaluation,”ACM Transactions on Database Systems, Vol. 17, No.
3. 1992.
2. Alonso, R., D. Barbara, and H. Garcia-Molina. “Data Caching Issues in an
Information Retrieval System,“ ACM Transactions on Database Systems, Vol.
15, No. 3 , September 1990.
3. BarbarB, Daniel “Certification Reports: Supporting Transactions in Wireless Systems“. In ZCDCS, 1997.
4. P. A. Bernstein, V. Hadzilacos and N. goodman, “Concurrency Control and Recovery in Database Systems,“ Adison-Wesley, Reading, MA, 1987.
5. P. K. Chrysanthis, “Transaction Processing in a Mobile Computing Environment,“
in Proceedings of the IEEE Workshop on Advances in Parallel and Distributed
Systems, Princeton, NJ, Oct. 1993.
6. S. B. Davidson, H. Garcia-Molina, and D. Skeen. “Consistency in Partitioned
Networks,” ACM Computing Surveys, Vol. 17, No. 3, September 1985.
7. M. H. Dunham, A. Helal, and S. Baqlakrishnan. “A Mobile Transaction Model
that Captures Both the Data and the Movement Behavior,” ACM/Balter Journal
on special topics in mobile networks and applications, Vol. 2, No. 2, 1997.
8. G . H. Forman and J. Zahorjan, “The Challenges of Mobile Computing,” IEEE
Computer, Vol. 27, No. 6, April 1994.
9. H. Garcia-Molina and G. Wiederhold, “Read-only Transactions in a Distributed
Database,“ ACM Trunsuctions on Systems, Vol. 7 , No. 2, June 1982.
10. H. Garcia-Molina and K. Salem, “Sagas,“ in Proceedings of ACM SIGMOD
Conference, 1987.
11. J. Gray and A. Reuter, Transaction Processing: Concepts and Techniques, Morgan Kaufmann, San Francisco, 1993.
12. J. Gray, P. Helland, P. E. O’Neil, and D. Shasha, “The Dangers of Replication
and a Solution,“ in Proceedings ofACM SIGMOD Conference, 1996.
13. A. K. Elmagarmid, Y. Lie, and M. Rusinkiewicz, “A Multidatabase Transaction
Model for INTERBASE,“ in International conference on Very Large Databuses
(VLDB),Brisbane, Australia, Aug. 1990.
14. L. B. Huston and P. Honeyman, “Partially Connected Operation,” Computing
Systems, Vol. 4, No. 8, Fall 199.5.
15. T. Imielinksi and B. R. Badrinath, “Wireless Mobile Computing: Challenges in
Data Management,” Communications of the ACM, Vol. 37, No 10, Oct. 1994.
16. J. J.Kistler and M. Satyanarayanan, “Disconnected Operations in the Coda File
Systems,“ACM Transactions on Computer Systems, Vol. 10, No. 1, Feb. 1992.
17. H. Korth, E.Levy, and A. Silberschatz, “A Formal Approachto Recovery by Compensating Transactions,“ in Proceedings of the 16th VLDB Conference, Brisbane,
Australia 1990.
18. N. Krinshnakumar and A. J. Bernstein, “Bounded Ingnorance: A Technique for
Increasing Concurrency in a Replicated System,“ACM Transactions on Database
Systems, Vol. 19, No. 4, Dee. 1994.
19. V. Kumar and M. Hsu, “A Superior Two-Phase Locking Algorithm and its Performance,” Information Sciences, Vol. 54, No. 1-2, 1991.
20. V. Kumar, M. H. Dunham and N. Prabhu, “A Mobile Transaction Framework
Supporting Spatial Replication and Spatial Consistency,“ Special Issue on Mobile
Databases International Journal qf Computer Systems Science & Engineering,
Vol. 20, No 2, March 2005.
21. V. Kumar, N. Prabhu, M. H. Dunham, and A. Yasemin Seydim, “TCOT - A
Timeout-based Mobile Transaction Commitment Protocol,” Special issue of IEEE
Transaction on Computers,Vol. 5 1, No. 10, Oct. 2002.
22. V. Kumar, “A Timeout-based Mobile Transaction Commitment Protocol,” in 2000
ADBIS-DASFAA Symposium on Advances in Databases and Information Systems,
in cooperation with ACM SIGMOD-Moscow, Sep. 5-8, 2000, Prague, Czech
23. V. Kumar and M. Dunham, “Defining Location Data Dependency, Transaction
Mobility and Commitment,” Technical Report 98-cse- 1,Southern Methodist University, Feb. 98.
24. K.-I. Ku and Y.-S. Kim, "Moflex Transaction Model for Mobile Heterogeneous
Multidatabase Systems," Proceedings of the 10th International Workshop on Issues in Data Engineering, 2000.
25. Rajan Kuruppillai, Mahi Dontamsetti and Fil J. Cosentino, "Wireless PCS,"
McGraw-Hill, New York, 1997.
26. M. Mouly and M.-B. Pautet, The GSM System for Mobile Communications, Cell
& Sys Publications, France, 1992.
27. E. Pitoura and B. Bhargava, "Maintaining consistency of data in mobile di\tributed environments," in Proceedings ofl5th International Conference on Distributed Computing Systems, 1995.
28. K.-Y. Lam, T.-W. Kuo, W.-H. Tsamg, and G . C. K. Law, "Concurrency Control
in Mobile Distributed Real-Time Database Systems," Information Systems, Vol.
25, No. 4, June 2000.
29. D. Lee, W.-C. Lee, J. Xu, and B. Zheng. "Data Management in LocationDependent Information Services," IEEE Pervasive Computing, Vol. 1, No. 3,
July-September 2002.
30. Madria, S. K. and Bharat Bhargava, "A Transactional Model to Improve Data
Availability in Mobile Computing", Distributed and Parallel Databases, Vol. 10,
Issue 2, Sep. 2001.
31. E. Moss, Nested Transactions, The MIT Press, Cambridge, MA, 1985.
32. L. B. Mummert, M. R. Ebling, and M. Satyanarayanan, "Exploiting Weak Connectivity for Mobile File Access," in Proceedings ofthe 15th ACM Sympohium
on Operating Systems Principles, Dec. 1995.
33. B. D. Noble, M. Price, and M. Satyanarayanan, "A Programming Interface for
Application- Aware Adaptation in Mobile Computing," Computing Systems, Vol.
8, No. 4, Winter 1996.
34. M. T. Ozsu, and P. Valduriez, Principles of Distributed Database Systems, Prentice Hall, Engleewood Cliffs, NJ, 1991.
35. C. Papadimitriou. The Theory of Datababe Concurrency Control, Computer
Science Prew, 1986.
36. E. Pitoura and B. Bhargava, "Building Information Systems for Mobile Environments," in Proceedings ofthe Third International Conference on Injbrmation
and Knowledge Management, Washington, D.C., Nov. 1994.
37. E. Pitoura and B. Bhargava, "Maintaining Consistency of Data in Mobile Distributed Environments," in Proceedings of the 15th IEEE International Coqference on Distributed Computing Systems, May 1995.
38. E. Pitoura, Replication Schema to Support Weak Connectivity in Mobile Information Systems,“in Proceedings of the 7th International Conference on Database
and Expert Systems Applications (DEXAY6), LNCS 1 134, Springer Verlag, Sep.
39. E. Pitoura and G. Samaras. Data Management for Mobile Computing, Kluwer
Academic Publishers, Boston, MA, 1998.
40. E. Pitoura and B. Bhargava, “Maintaining Consistency of Data in Mobile Distributed Environments,“ Proceedings qf 15th International Conference on Distributed Computing S.ysterns, 1995.
41. E. Pitoura and G. Samaras, “Locating Objects in Mobile Computing,” IEEE
Transaction on Knowledge and Data Engineering, Vol. 13, No. 4, 2001.
42. E. Pitoura and I. Fudos, “Distributed Location Databases for Tracking Highly
Mobile Objects,“ The Computer Journal, Vol. 44, No. 2, 2001.
43. C, Pu, G. Kaiser, and N. Hutchinson, “Split-Transactions for Open-Ended Activities,“ Proc. Fourth International Conference on VLDB, Sep. 1988.
44. C. Pu and A. Leff, “Replica Control in Distributed Systems: An Asynchronous
Approach,” in Proceedings ofthe ACM SIGMOD Conference, I99 1 .
45. C. Pu, “Generalized transaction processing with epsilon-serializability,” in Proceedings of Fourth International Workshop on High Perjiormance Transaction
Systems, Asilomar, CA, Sep. 1991.
46. K. Ramamritham and C. Pu, “A Formal Characterization of Epsilon Serializability,” IEEE Transactions on Knowledge and Data Engineering, Vol. 7, No. 6,
47. M. Satyanarayanan, J. J. Kistler, L. B. Mummert, M. R. Ebling, P. Kumar, and
Q. Lu, “Experience with Disconnected Operation in a Mobile Comp uting Environment,” in Proceedings of the I993 USENIX Syrnposium on Mobile and
Location-Independent Computing, Cambridge, MA, Aug. 1993.
48. Y. Seydim, M. H. Dunham, and V. Kumar, “Location Dependent Query Processing,“ Proceedings of MobiDE, 200 1.
49. A. Sheth and M. Rusinkiewicz, “Management of Interdependent Data: Specifying
Dependency and Consistency Requirements,“in Proceedings @‘theWorkshop on
the Management of Replicated Data, Houston, Texas, Nov. 1990.
50. M. H. Wong and D. Agrawal, “Tolerating Bounded Inconsistency for Increasing
Concurrency in Database Systems,”in Proceedings of the I 1 th ACM PODS, 1992.
5 1. P. S. Yu, D. M. Dias, and S. S Lavenberg, “On the Analytical Modeling of Database
Concurrency Control,“ Journal uf the ACM, Vol. 40, No. 4, Sep. 1993.
52. K.-L. Wu, P. S. Yu, and C. Pu, “Divergence Control for Epsilon-Serializability,”
in Proceedings of International conference on Data Engineering (ICDE), 1992.
53. D. G. Walborn, and P. K. Chrysanthis, “Pro-Motion: Management of Mobile
Transactions,” Personal Technologies,Vol. I , No. 3, September 1997.
54. D. G. Walborn, and P. K. Chrysanthis, “Pro-Motion: Support for Mobile Database
Access,“ in Proceedings ofthe 12th ACM Annual Symposium on Applied Computing, San Jose, CA, Feb. 1997.
55. G. Weikum and G. Vossen, Transactional Information Systems, Morgan Kaufmann, San Francisco, 2002.
56. L. H. Ye0 and A. Zaslavsky, “Submission of Transactions from Mobile Workstations in a Cooperative Multidatabase Processing Environment,“ in Proceedings
of Distributed Computing Systems, 1994.
57. D. G. Walborn, and P. K. Chrysanthis, “Supporting Semantics Based Transaction
Processing in Mobile Database Applications,“ in Proceedings of the 14th IEEE
Symposium on Reliable Distributed Systems, Sep. 1995.
Mobile Database
This chapter deals with recovery in a mobile database system, which is more complex
compared to conventional database recovery. It first introduces fundamentals of
database recovery and briefly describes conventional recovery protocols and uses them
to focus on application recovery where information gathering and their processing
for recovery is quite complex. The chapter first identifies those aspects of a mobile
database system which affect recovery process. It then discusses recovery approaches
which have appeared in the literature. Similar to other areas such as transaction
modeling, concurrency control, etc., database recovery is also in the development
stage, so the coverage here is mostly limited to state -of-the art research and little on
commercial products. A number of recovery schemer have been developed [3,.5, 11,
1.5, 17, 18, 19,20, 22, 23, 241, and this chapter discusses a few of them.
Database recovery protocols recover a database from transaction or system failures,
that is, they restore the database to a consistent state from where transaction processing
resumes. These failures may occur due to a number of reasons such as addressing
error, wrong input, RAM failure, etc. In a concurrent execution environment when a
failure occurs then a transaction may be active or blocked or being rolled back or in the
middle of a commit. The task of a recovery protocol is to identify the right operation
for for recovery for each transaction. These operations are (a) Roll forward or Redo
and (b) Roll backward or Undo. Depending upon the execution status of a transaction,
one of these operations is selected. Thus, in a recovery process some transactions are
undone and some transactions are redone. To implement these operations, Transaction
log is required, which is generated and maintained by the system. The log contains
committed values of data items (Before Image - BFIM) and modified values of data
items (After Image - AFIM). The log is a crucial document for recovery; therefore,
it is generated and maintained by a protocol called Write Ahead Logging - WAL. The
protocol guarantees that the contents of a log is reliable and can be used for Undo
and Redo operations.
After a failure the database system reboots and, by using log, applies Redo and
Undo operations on transactions which were in the system when it failed. A Redo
completes the commit operation for a transaction, and an Undo rolls back a transaction
to maintain atomicity. These operations give us four different recovery protocols: (a)
Undo-Redo, (b) Undo-No Redo, (c) No Undo - Redo, and (d) No Undo - No Redo [XI.
Undo-Redo: This protocol applies Redo and Undo to recover the database systems.
This means that during transaction execution it can write to the database intermediate
values of its data item. If the transaction was active when the system failed, then the
transaction is Undone and it is Redone if the transaction was ready to commit.
Undo - No Redo: This protocol does not support Redo and recovers the database
by applying Undo operation only. This means that the system forces intermediate
updates of transactions to he database immediately.
NO Undo - Redo: This protocol makes sure that no intermediate results of a transaction are installed in the database. Thus, if a transaction cannot be Redone at the
time of recovery, then it is removed from the system.
NO Undo - NO Redo: This protocol does not apply Redo and Undo and recovers
the database by using the shadow copy of data items. Thus, during execution a
transaction creates a show copy of data items it modifies. During recovery it uses
actual and shadow copies of a data item to select the right version to install in the
Recovery is a time-consuming and resource-intensive operation, and these protocols require plenty of them. The most expensive operation is managing the log. This
operation is essential for recovery, so for a Mobile Database System an economical
and efficient scheme of its management is necessary.
A Mobile Database System (MDS) is a distributed system based on client server
paradigm, but if functions differently than conventional centralized or distributed
systems. It achieves such diverse functionalities by imposing comparatively more
constraints and demands on MDS infrastructure. To manage system-level functions,
MDS may require different transaction management schemes (concurrency control,
database and application recovery, query processing, etc.), different logging schemes,
different caching schemes, and so on.
In any database management system, distributed or centralized, the database is
recovered in a similar manner and the recovery module is as an integral part of the
database system. Database recovery protocols, therefore, are not tampered with user
level applications. A system which executes applications, in addition to database
recovery protocol, requires efficient schemes for Application recovery [ 12, 131. The
application recovery, unlike database recovery, enhances application availability by
recovering the execution state of applications. For example, in MDS or in any distributed system a number of activities related to transactions' execution, such as
transaction arrival at a client or at a server, transaction fragmentation and and the
distribution of these fragments to relevant nodes for execution, dispatch of updates
made at clients to the server, migration of a mobile unit to another cell (handoff), etc.,
have to be logged for recovering the last execution state. With the help of the log
the application recovery module recreates the last execution state of application from
where normal execution resumes.
Application recovery is relatively more complex than database recovery because
of (a) the a large numbers of applications required to manage database processing, (b)
presence of multiple application states, and (c) the absence of the notion of the "last
consistent state." This gets more complex in MDS because of (a) unique processing
demands of mobile units, (b) the existence of random handoffs, (c) the presence of operations in connected, disconnected, and intermittent connected modes, (d) locationdependent logging, and (e) the presence of different types of failure. These failures
can be categorized as Hardfailure and Softfailure [ 171. Hard failures includes loss of
mobile unit (stolen, burnt, drowned, dropped, etc.), which cannot be easily repaired.
Soft failures include system failure (program failure, addressing errors, battery ran
out, processing unit switched off, etc.) and are recoverable.
An application can be in any execution state (blocked, executing, receiving data
slowly, and so on). In addition to this, the application may be under execution on
stationary units (base station or database server) or on mobile units or on both. These
processing units, especially the mobile unit, may be (a) going through a handoff, (b)
disconnected, (c) in a doze mode, (d) turned off completely. The application may
be processing a mobilaction or reading some data or committing a fragment, and so
on. If a failure occurs during any of these tasks, the recovery system must bring the
application execution back to the point of resumption.
In application recovery, unlike data consistency, the question of application consistency does not arise because the application cannot execute correctly in the presence
of any error. Thus, the most important task for facilitating application recovery is the
management of log. The database recovery protocols provide a highly efficient and
reliable logging scheme; unfortunately, even with modifications, the conventional
logging scheme would impose unmanageable burden on resource constrained MDS.
What is needed is an efficient logging scheme, which stores, retrieves, and unify
fragments of application log for recovery within the constraints of MDS.
Log is a sequential file where information necessary for recovery is recorded. Each
log record represents a unit of information. The position of a record in the log
identifies the relative order of the occurrence of the event the record represents. In
legacy systems (centraliLed or distributed) the log resides at fixed locations which
survive system crashes. It is retrieved and processed to facilitate system recovery
from any kind of failure. This persistence property of log is achieved through the
protocol called Write Ahead Logging (WAL) [41.
This static property of log ensures that no additional operation other than only its
access is required to process it for recovery. The situation completely changes in the
systems which support terminal and personal mobility by allowing the processing
units to move around. As a result they get connected and disconnected many times
during the entire execution life of transactions they process. The logging becomes
complex because the system must follow the WAL protocol while logging records at
various servers.
An efficient applicaion recovery scheme for MDS requires that the log management
must consume minimum system resources and must recreate the execution environment as soon as possible after MU reboots. The mobile units and the servers must
build a log of the events that change the execution states of mobilaction. Messages
that change the log contents are called write events [22]. The exact write events depend on the application type. In general, the mobile unit records events like (a) the
arrival of a mobilaction, (b) the fragmentation of mobilaction, (c) the assignment of
a coordinator for mobilaction, (d) the mobility history of the mobile unit (handoffs,
current status of the log, its storage location, etc.), and (e) dispatch of updates from
mobilaction to DBS?. The DBSs may record similar events in addition to events
relating to the commit of mobilaction.
8.2.1 Where to Save the Log?
Schemes that provide recovery in the PCS (Personal Communication System) system
saves the log at the BS where the mobile unit currently resides [ 19,221. It is important
to note that managing log for PCS failure is relatively easy because it does not support
transaction processing. However, the concept can be used to develop efficient logging
schemes for MDS.
There are three places the log can be saved: (a) MSC (Mobile Switching Center),
(b) Base Station (BS), and (c) Mobile Unit (MU). The reliability and availability
of mobile units, however, make it a less desirable place to save the log. MSC and
BS are suitable places; but from cost and management viewpoints, MSC is not a
convenient location. An MSC may control a large number of BSs; in the event
of a failure, accessing and processing the log for specific transaction may be timeconsuming. An MSC is not directly connected to database servers (Figure 7.1),
which provide necessary log management applications. BSs, on the other hand, are
directly connected to DBSs and also to mobile units. Therefore, fromconnectivity and
availability aspects, BSs are comparatively better candidates for saving an application
log. Under this setup a mobile unit can save log at the current BS and the BS then
can archive it on DBSs.
Effect of Mobility on Logging: In conventional database systems, the log generation and its manipulation are predefined and fixed. In a mobile environment, this may
not always be true because of the frequent movements and disconnections of mobile
units. A mobiluction may be executed at a combination of mobile units, base stations
and fixed hosts. Furthermore, if a fragment of mobilaction happens to visit more than
one mobile unit, then its log may be scattered at more than one base stations. This
implies that the recovery process may need a mechanism for log unification (logical
linking of all log portions). The possible logging schemes can be categorized as
Centralized logging-Saving of log at a designated site: Under this scheme a
base station is designated as logging site where all mobile units from all data regions
save their log. Since the logging location is fixed and known in advance, and the
entire log is stored at one place, its management (access, deletion, etc.) becomes
easier. Under this scheme, each mobile unit generates the log locally and, at suitable
intervals or when a predefined condition exists, copy its local log to the logging base
station. If a fragment or mobiluction fails, then the local recovery manager acquires
the log from the base station and recover the mobiluction. This scheme works, but it
has the following limitations:
It has very low reliability. If the logging base station fails, then it will stop
the entire logging process; consequently, transaction processing will stop until
the BS recovers. Adding another backup base station will not only increase
resource cost but will increase log management cost as well.
Logging may become a bottleneck. The logging traffic at logging base station
may become unmanageably heavy, causing significant logging delays.
For a lightly loaded system with little MU movement, however, this scheme provides
a simple and efficient way of managing the log.
Home logging: Every mobile unit stores its log at the base station it initially registers. Although a mobile unit will roam around in the geographical domain freely
and continue to access data from any sites, all logging will still be at its base station.
This scheme has the following limitations:
Under this scheme the entire log ofmobiluction may be scattered over a number
of base stations if its fragments are processed by different mobile units with
different base stations. To recover the mobiluction, all pieces of log will require
linking (logically).
It may not work for spatial replicas (location-dependent data). Consider a
location-dependent query which comes to a mobile unit for processing but
whose base station is not the one that stores the location dependent data. This
may happen if a traveler from Kansas City issues a query on hisher mobile unit
for Dallas Holiday Inn data. This scheme can cause excessive message traffic.
Since the logging location is not distributed, it has poor availability and excessive message traffic during transaction execution.
At a designated base station
Under this scheme a mobile unit locally composes the log and, at some predefined
intervals, saves it at the designated base station. At the time of saving the log a mobile
unit may be in the cell of the designated base station or at a remote base station, In
the latter case, the log must travel through a chain of base stations, ending up at the
designated base station. This will work as long as there is no communication failure
anywhere in the chain of base stations.
At all visited base stations
In this scheme a mobile unit saves the log at the base station of the cell it is currently
visiting. The entire application log is stored in multiple base stations, and at the time
of recovery all log portions are unified to create the complete log. It is possible that
two or more portions of the entire log may be stored at one base station if the mobile
unit revisits the station. A number of logging schemes were developed under these
two approaches, some of which are discussed below.
Lazy scheme: In lazy scheme [22], logs are stored on the current base station and
if the mobile unit moves to a new base station, a pointer to the old base station is
stored in the new base station. These pointers are used to unify the log distributed
over several base stations. This scheme has the advantage that it incurs relatively
less network overhead during handoff as no log information needs to be transferred.
Unfortunately, this scheme has a large recovery time because it requires unification
of log portions.
The log unification can be performed in two ways: (a) distance-based scheme and
(b) frequency-based scheme. In a distance-based scheme [19] the log unification is
initiated as soon as the mobile unit covers the predefined distance. This distance
can be measured in terms of base station visited or in terms of cell site visited. In
the frequency-based scheme [19], log unification is performed when the number of
handoffs suffered by the MU increases above a predefined value. After unifying the
log, the distance or handoff counter is reset.
Pessimistic scheme: In the pessimistic scheme [22], the entire log is transferred at
each handoff from old to new base station. This scheme, therefore, combines logging
and log unification. Consequently, the recovery is fast, but each handoff requires
large volumes of data transfer.
The existing mobile network framework is not efficient for full-fledged database
transactions running at DBSs and mobile units. In the above schemes the location
change of MU has to be updated by DBSs, which would be a big disadvantage.
To overcome this, mobile IP was introduced. In Ref. [25] log recovery based on
the mobile IP architecture is described where base stations store the actual log and
checkpoint information and the base station or the home agent as defined i n Ref.
12 11 maintains the recovery information as the mobile unit traverses. This scheme
has the advantage that log management is easy and the database servers need not be
concerned with the mobile unit’s location update, but it suffers when the mobile unit
is far away from home. Consequently, recovery is likely to be slow if the home agent
is far from the mobile unit. The other problem with using mobile IP is triangular
routing where all messages from the database server to the mobile unit have to be
routed through the home agent. This invariably impedes application execution. The
schemes discussed so far do not consider the case where a mobile unit recovers in a
base station different from the one in which it crashed. In such a scenario, the new
base station does not have the previous base station information in its VLR (Visitor
Location Register), and it has to access the HLR (Home Location Register) to get this
information [8], which is necessary to get the recovery log. HLR access may increase
the recovery time significantly if it is stored far from the MU. A similar disadvantage
can be observed in the mobile IP scheme of Ref. [2S], where the mobile unit needs
to contact the home agent each time it needs recovery.
In this section a number of recovery schemes have been discussed. These schemes
take different approaches; however, they build their scheme on same mobile database
platform. The platform contains a set of mobile unites and base stations. These
units save logs and checkpoint necessary activities and make sure that necessary
information is available for recovering from failure efficiently and economically.
8.3.1 A Three-Phase Hybrid Recovery Scheme
A three-phase checkpointing and recovery scheme is discussed in Ref. [ 111 which
combines coordinated and communication-induced checkpointing schemes. All base
stations use coordinated checkpointing, and the communication-based checkpointing
is used between mobile units and base stations. Following steps briefly describe the
working of the algorithm. Further details can be found in Ref. [ 1 11. The algorithm
uses mobile units M U , , MU2, MU3, and MU4, as well as base stations MSS1.
hfSS2, and M S & , for describing message traffic.
Initially, a coordinator (base station) M S S l broadcasts a request message with
a checkpoint index to MSS2 and MSS;<.
Each M S S sets up a timer Tlazy.It uses a lazy coordination scheme to reduce the number of messages, therefore, it is especially suitable for mobile
database systems. In this approach, infrequent snapshots are taken which only
occasionally impose high checkpoint overheads of coordinated snapshots on
the low-bandwidth network connecting all mobile units. This approach also
prevents the global snapshot from getting out of date; as a result, the amount
of computation for recovery from failure is minimized.
Mobile unit MU2 or MU3, whichever is active, takes a checkpoint before
message i n 2 or m3 arrives from MSS2 or MSS3 during T l n z y .
MU1 or MU4 takes a checkpoint when Tlazyhas expired, and it receives a
checkpoint request from M S S l or M S S s .
MSS2 and MSS, responds (send a response message) to MSS1.
MSSl broadcasts a commit message to all M S S s after receiving response
messages from other base stations.
MU:$migrates from M S S 3 to MSSz and sends a message to wake MU4 if it
is in doze mode.
MU2 takes a checkpoint before it disconnects itself from the network. If MU,
is already in disconnected mode, then it does not take any checkpoint.
In case MU1 fails, it stops executing and sends a recovery message to M S S l .
MSSl broadcasts a recovery messages to all MSSs.
Each M S S sends recovery message to all its M U s . These M U s roll back to
their last consistent state.
Fig. 8.1 An example of snapshot generation.
Low-Cost Checkpointing and Failure Recovery
In Ref. [23] a low-cost synchronous snapshot collection scheme is presented in
which allows minimum interference to the underlying computation. The working of
the algorithm is explained with the following example. Figure 8. I illustrates the flow
of messages which manage the snapshot process. The processing noes are represented
as Po, P I , PL,and l'3, and m l , mz, 7713, m4, I T I S , and r n represent
the messages.
21 1
The node Pz first collects local snapshots at the point X time point.
Assume that nodes PI,,?'l and Pz are dependent, so a snapshot request message
is sent to PI and F'3 by P2. Node P3 sends message m.4 to node PI after taking
its own snapshot.
Their are two possibilities when message m q reaches P I : (a) PI has not processed any message since its last local snapshot or (b) PI has already processed
a message from any node since its last snapshot. In this example, since PI has
not processed any message, as a result it takes its tentative snapshot and records
this event before processing message r n d . It then propagates the snapshot.
Node Po takes a local snapshot since it has not received any message from any
node and sends a message m5 to P I . When rri5 reaches P I , it finds that m.5 is
not a new message to force a snapshot so PI does not take a snapshot.
When a node P, fails, then it rolls back to its latest checkpoint and sends rollback
requests to a subset of nodes. When a node Pj receives its first rollback message,
then (a) it rolls back to its latest checkpoint and (b) it sends a rollback request to a
selective set of nodes. Node P3 may receive subsequent rollback messages as a result
of PI 's failure, but it ignores all of them. In the case of mobile units, all their rollback
requests are routed through their base stations.
A Mobile Agent-Based Log Management Scheme
Mobile agents have been successfully used in managing a number of application and
system activities. It has also been used to develop a scheme to manage an application
log in MDS (Mobile Database Systems). A mobile agent is an autonomous program
that can move from machine to machine in a heterogeneous network under its own
control. It can suspend its execution at any point, transport itself to a new machine,
and resume execution from the point it stopped execution. An agent carries both the
code and the application state. Actually a mobile agent paradigm is an extension of
the cliendserver architecture with code mobility. Some of the advantages of mobile
agents as described in Ref. [ 141 are:
Protocol Encapsulation: Mobile agents can incorporate their own protocols
in their code instead of depending on the legacy code provided by the hosts
Robustness and fault-tolerance: When failures are detected, host systems
can easily dispatch agents to other hosts. This ability makes the agents faulttolerant.
Asynchronous and autonomous execution: Once the agents are dispatched
from a host, they can make decisions independently and autonomously. This is
particularly useful to the wireless environment where maintaining a connection
throughout an executing mohilaction may not be economical or necessary. In
such cases, the agents can visit the destination, perform any required processing,
and bring the final data to the origin thereby removing the need for a continuous
wireless connection. For example, an agent can take a mobiluction from a
mobile unit, execute it at the most suitable node (could be remote), and bring
the result back to the mobile unit.
Agents do have disadvantages, and the one which is likely to affect the logging
scheme is its high migration and machine load overhead [ 2 ] . This overhead must
be minimized for improving the performance. The present scheme uses agent services with the only when needed approach. It is not possible to develop a scheme,
which optimizes the performance at all levels and in all different situations. For this
reason, some recovery schemes improve the performance by targeting to minimize
the communication overhead, some might concentrate on total recovery time, some
may optimize storage space, and so on. Thus, each scheme involves certain tradeoffs. When these issues are taken into consideration, it becomes necessary to build
a framework that supports the implementation of the existing schemes and should
also be able to support any new scheme. The framework should support the activationldeactivation of a scheme, depending on the particular environment in which
it offers best performance. Such a framework should abstract the core base station
software (which handles the registration, handoff, etc., activities) from handling the
recovery procedures, thus allowing for better recovery protocols to be implemented
without the need for changing the core software. The framework may also support a
rapid deployment of the recovery code without much human intervention.
In MDS, the coordinator module resides in the base station. It splits mobilaction into fragments if necessary, and it sends some of them to a set of DBSs. This
requirement asks for specific intelligence to be embedded in the base station code.
Mobilactian initiated by mobile unit may use different kinds of commit protocols
like 2-phase commit or 3-phase commit or TCOT (Transaction Commit on Timeout)
[9]. The coordinator module needs to support all of these. If such a module at a
base station does not support a particular protocol, then there should be an easy way
to access such a code. An extension to this is that, when a new efficient protocol is
introduced, all base stations should be able to upgrade to this as easily as possible
and with little or no human intervention. From the perspective of mobile unit log
recovery, an architecture is required which supports intelligent logging and is able to
incorporate any future developments without any difficulty.
Some recovery schemes specify that the logs move along with the mobile unit
through a multitude of base stations. The new base stations should be able to handle
the logs in the same way as the previous one did or log inconsistency might result. It
is argued that the flexibility and constraints mentioned above could be successfully
incorporated on a mobile-agent based architecture under which the code necessary for
recovery and coordination can be embedded in the mobile agents. The coordinator can
be modeled as a mobile agent and can be initiated by the mobile unit itself if necessary.
If during a handoff the new base station does not support a specific logging scheme,
then the agent in the previous base station which supports this can clone itself and the
new replica can migrate to the current base station without any manual intervention.
The same technique can be used in quickly populating the base stations with any new
protocols. The mobile agent with the new protocol embedded in it can be introduced
in any base station and it can replicate and migrate to other base station.
Architecture of Agent-Based Logging Scheme
An architecture is presented where mobile agents are used to provide a platform for
managing logging. The architecture supports the independent logging mechanisms.
It is assumed that each base station supports the functionality of mobile agents. The
main components of the architecture are:
Bootstrap agent (BsAg): This agent handles a base station failure. Any agent that
wishes to recover should register with the bootstrap agent. The base station initiates
the bootstrap agent. Once loaded, this agent starts all the agents that have registered
with it. These agents have the capability to read the log information they have created
and act accordingly. The need for such an agent may be obviated if the mobile agent
provides an automatic revival of the agents with their state intact.
Base Agent (BaAg): This agent decides which logging scheme to use in the current
environment. Such functionality can be decided by its own intelligence or can be given
as an input. For every mobile unit, it creates an instance of an agent that handles the
recovery of mobilactions based on the relevant logging scheme.
Home Agent (HoAg): This agent handles rnohilactions for each mobile unit. It
is responsible for maintaining log and recovery information on behalf of the mobile
unit. The mobile unit sends log events to this agent, which is responsible for storing
them on the stable storage of the base station. The HoAg is a base station interface
to the mobile unit for Mobilactions
Coordinator Agent (CoAg): This agent resides at base station and acts as the
coordinator for all mobilactions.
Event Agent (EvAg): In addition to the above framework, the base station provides
mobile agents with an interface to the various events taking place like registration of
a mobile unit, failure of a mobile unit, handoff of a mobile unit, etc. This approach
abstracts away the core base station functions from application recovery support.
When a mobile unit suffers handoff, its HoAg should know about it so that it can
perform the required operations. The EvAg is the interface for the base station to the
agent framework for dissemination of such information.
Driver Agent (DrAg): The migration of a mobile agent during a handoff involves
the movement of its code and the actual data. This might generate considerable
overhead [2] even if the actual log transfer is not much.
Interaction Among Agents for Log Management
These agents collaborate with each other to facilitate log management.
Interaction of CoAg and HoAg: An MU sends Mobilaction to its HoAg, which
forwards it to the corresponding CoAg. If the CoAg needs to contact the MU, it does
so through the MU’S corresponding HoAg. When CoAg sends a write event to the
HoAg, it stores it in its local store before sending it to the MU. Similarly if any events
come to the MU through user input, MU sends the corresponding log messages to the
Action of agents when handoff occurs: The HoAg moves along with the mobile
unit to the new base station in a handoff. Based on schemes like Lazy and Frequencybased, the agent may or may not take the stored logs along with it to the new base
station. When a handoff occurs, a driver agent (DrAg) is sent along with the necessary log information to the new base station instead of the whole HoAg with all its
intelligence for log unification. The DrAg has a very light code whose main function
is to see whether the code for HoAg is present in the new base station. If so, it requests
the resident BaAg in the new base station to create an instance of the HoAg for the
mobile unit. If any compatible code is not present, then the DrAg sends a request to
the previous base station’s BaAg, which clones the necessary HoAg and sends the
copy to the new base station. When the mobile unit moves out of a base station, its
log information is not deleted automatically but it is stored unless notified otherwise
by the agent of the mobile unit. This facilitates the unification of logs when logs are
distributed over a set of base stations.
8.3.6 Forward Strategy
All schemes reviewed earlier have assumed instant recovery of the mobile unit after a
failure, but Ref. [8] acknowledges the possibility where the mobile unit might crash
in one base station and recover in another base station. A time interval is defined
between the mobile unit failing and its subsequent rebooting as Expected Failure
Time (EFT). This scheme concentrates on such scenarios where the EFT is not so
trivial that the recovery occurs instantaneously. Base station detects the failure of
a mobile unit and agents do not play any part in such detection. For example, if
the communication between two mobile units breaks down because of the failure of
one of the mobile units, then the corresponding BS will immediately know about this
event. Similarly, base station also knows which mobile unit has executed power-down
registration, which mobile unit has undergone a handoff, and so on.
A base station also continuously pages its mobile units.’ If the mobile unit suffers a handoff, then the communication with the last base station is not broken until
’Sprint PCS system pages its mobile units after every 10 to 15 minutes without generating any overhead
to learn their status, and a mobile unit also continuously scans the air by using its antenna to detect the
strongest signal.
the connection with the new base station is established (soft handoff). These features of PCS allow MDS to detect mobile unit failure. Thus, while a mobile unit is
executing its fragment, its status is continuously monitored by the base station and
any change in mobile unit’s situation is immediately captured by the Event Agent
interface. Since this detection is system-dependent, EFT (Expected Failure Time)
tends to be an approximate value. The detection can be passed on to the HoAg in
many ways. The MDS can provide an interface, which would allow the agents to
wait for an event. Another approach would be to provide an agent readable system variable which would be set on any such event. The agent will periodically
poll the variable to check if it is set. Both approaches are possible and easy to implement in languages such as Java in which many agent systems like IBM’s Aglets
and General Magic’s Odyssey have been developed [(i]. Since handoff does not
occur in the above case as pointed out in ref. [8], the new base station does not
know the location of the old base station. This situation leads to the new base station contacting the Home Location Register (HLR) for the previous base station
[8, 18, 19, 231. This might be a hindrance to fast recovery if the HLR happens to
be far from the querying base station. Actually the Visitor Location Register (VLR)
is first queried for the previous base station information, which is stored in VLR if
both base stations happen to fall under the control of the same VLR. If base stations are under different VLRs, then the HLR of the mobile unit has to be queried.
Such information is stored in the HLR when a mobile unit first registers with a base
In the lazy scheme [8], the base station starts building up the log immediately
upon failure of mobile unit. In the schemes presented in Ref. [19], the mobile unit
explicitly issues a recovery call to the base station and the base station begins the
log unification. This raises certain questions in the event of the mobile unit crashing
and recovering in a different base station. If the log is to be unified immediately
upon a failure, then it might be necessary for the new base station to wait for the
old base station to finish its unification and then present its log. If the failure time
is large or the total log size is small, then unification will be over by the time the
new base station queries the previous base station. In such a case, recovery can be
fast. In the case of a relatively small EFT (Expected Failure Time) or a large log size
(to be unified), the new base station must wait first for the unification and then for
the actual log transfer. This results in increased recovery time and network cost. In
such cases it might be preferable for the log unification to be done in the new base
station if the list of base stations where the log is distributed is known. Such a list
is transferred in schemes provided in Ref. [19] and not for those in Ref. [S]. In
the approach where the log is unified after a recovery call, the recovery time might
not be small enough if the log size to be unified is small. In this case the unification has to begin after getting the list of base stations involved from the previous
base station. Also, if the mobile unit has not migrated to a new base station before recovery, then the log has to be unified, which is likely to increase the recovery
Reducing Recovery Time
The scheme of log unification is based on the number of handoffs occurred since
the last log unification or the start of the transaction whichever is later. The log
is unified periodically when the number of handoffs occurred crosses a predefined
When a handoff occurs, the Truce information is transferred from the old base
station to the new base station. This trace information is an ordered list of elements
giving information about the base stations involved in storing mobile unit’s log. Each
array element consists of two values: (a) the identify of this base station (BS-ID) and
(b) the size of the log stored at BS-ID1 (Log-Sizei). When a handoff occurs, then
BS-ID of the new base station and a Log-Size value of zero are added to the end of
the trace. The Log-Size value is updated whenever mobile unit presents base station
with some log information. Optional parameters can also be present in the trace
information. Since the trace does not contain the actual log contents and is mostly an
array of base stations identities and log sizes, it does not present a significant overhead
during the handoff. The scheme also assumes the presence of EFT (expectedfuilure
time) value which can be stored as an environment attribute accessible to HoAg of
the mobile unit at the base station. If such support cannot be given by the system,
then HoAg can also estimate EFTfrom mobile unit’s activities. If the agent estimates
the EFT, then this value is also stored in the trace information. When the system
detects mobile unit failure, it informs the agent framework through the Event Agent
interface. This agent notifies the appropriate HoAg that starts the EFT clock. This
clock is stopped to get the Recorded-EFTvalue, when the HoAg receives mobile unit
recovery call, which can come from the mobile unit in the same base station or from
a different base station in which the mobile unit has recovered. In either case, the
agent residing in base station where the EFT clock is started. It estimates the new
EFT as
(K1 x Recorded-EFT ) + (K2 x EFT), where K1
+ K2 = 1
The new EFT is a weighted sum of the previous EFT and the Recorded-EFT. K 1
indicates the reliance on the Recorded-EFT, while K 2 indicates the reliance on the
previously calculated EFT. The values of K1 and K2 are functions of the environment.
In a network where the failure time is relatively stable, K2 is given more weight; and
in a network where the failure time varies frequently, K1 can be given more weight.
To improve storage utilization, unnecessary records from the log is deleted. This
garbage collection is optional and is done upon log unification. When a mobile unit
log is unified at a base station, a garbage-collect message is sent to all the base stations
hosting the mobile unit logs as specified in the trace BS-ID list. The previous base
stations purge these logs on receiving this message. The BS-ID and the Log-Size
lists are erased from the trace information at the current base station to reflect the
unification, and a ringle entry is created in the trace with the current base station
identity and the unified log size.
Forward Log Unification Scheme
Since the trace information contains the size of the log stored at different base stations,
the HoAg can estimate the time for log unification based on the network link speed
and the total log size. This time is called the Estimated Log Unijication Time (ELUT),
which can be measured as: Max (BSi-Log-Size/Network link Speed + Propagation
Delay), for all base stations in the trace. The exact characterization of the ELUTvalue
depends other factors such as whether base stations are located in the same VLR area or
different areas, queuing delay, etc. The HoAg should take into consideration as many
parameters available from the system as possible to estimate the ELUT accurately.
Log unification is started if (6 * ELUT) 5 EFT or else it is deferred until a recovery
call is heard from the mobile unit.
The Unification factor “6” describes what fraction of the log unification will be
done by the time the failure time of the mobile unit comes to an end. The default
value can be kept as 1 , which indicates that the log unification starts only if it can be
totally completed by the time the mobile unit is expected to complete its reboot. If
the mobile unit reboots in a different base station while the log is being unified in the
previous base station, it has to wait for the unification to complete. Variations of this
scheme are possible if the HoAg can estimate the effective handoff time. Based on
this value, if there is still a long time for the next handoff, then the log unification
can start immediately upon a failure, as it is more probable that the failed mobile unit
will recover in the base station where it failed rather than in any other base station. In
the event the log unification is not performed because (6 x ELUT) 5 EFT, the HoAg
waits for the mobile unit to recover. If the recovery happens in the same base station,
then the log unification starts; but if the mobile unit reboots in a different base station,
then the HoAg transfers the trace information and the log stored at this base station
when requested. In this case, the new base station has to perform the log unification
after getting the trace information from the previous base station. This trace contains
the newly calculated EFT value.
8.3.8 Forward Notification Scheme
This scheme addresses the issue of time spent in getting the previous base station
information from the HLR. To minimize this time, a scheme involving forward notifications is proposed. When a mobile unit fails in a particular base station and if
the actual failure time (total duration before mobile unit is rebooted) is not too high,
then there is a high probability that the mobile unit will recover in the same VLR or
in a BS that is in adjacent VLRs. Thus a VLR and its adjacent VLRs cover a large
area, and the situation where the mobile unit reboots in a nonadjacent VLR does not
occur frequently. If the mobile unit happens to restart in a non-adjacent VLR, then it
must have been extremely mobile and most of the recovery schemes are not designed
for such unrealistic situation. The other implication is that the mobile unit had been
in the failed state for a longer period and so it is likely that the coordinator could
have decided to abort the rnohilaction. Each VLR also stores mobile unit’s status
information (normal, failed, and forwarded).
When a mobile unit fails, its corresponding HoAg informs the VLR about this
failure. The VLR first changes the status of the mobile unit in its database from
normal to failed. The VLR then issues a message containing its own identity (e.g.,
identity of theVLR that sends this message), the identity of the failed mobile unit, and
the identity of the we propose in which the mobile unit crashed to its adjacent VLRs
that the mobile unit has failed. The adjacent VLRs store these messages until explicit
denotify messages are received. The mobile unit is recorded in these adjacent VLRs
with the status as forwarded. The following scenarios may arise when the mobile unit
Case 1-The mobile unit reboots in the same base station where it crashed:
In this scenario, the HoAg informs the VLR that the mobile unit has recovered. The
VLR then issues a denotify message to all the adjacent VLRs indicating that the
forward notification information is no longer valid. The status of the mobile unit is
changed back to normal from failed.
Case2-The mobile unit reboots in a differentbase station but in the same VLR:
First the mobile unit registers with the base station and the registration message is
logged on to the corresponding VLR. This VLR identifies the status of the mobile
unit as failed, and then it proceeds as in case 1 and sends denotify messages to the
adjacent VLRs. The status of the mobile unit is changed back to normal from failed.
The new base station then proceeds to perform log unification from the previous base
Case 3-The mobile unit reboots in a different base station and a different
VLR: The mobile unit requests for registration. The corresponding VLR identifies
the mobile unit as a forward notified mobile unit and returns the identity of the
previous base station and the identity of the VLR to the HoAg of the mobile unit in
the recovered base station. The base station then proceeds to perform log unification
from the previous base station. Simultaneously, the new VLR sends a recovered
message to the previous VLR regarding the recovered status of the mobile unit and
also sends a registration message to the HLR regarding the registration of the mobile
unit in the new location. The status of the mobile unit is changed to normal from
forwarded in the new VLR. Upon receiving the recovered message, the previous
VLR sends a denotify message to all adjacent VLRs except the one in which the
mobile unit recovered and removes the registration of the mobile unit from itself as
well. In the situation where the mobile unit recovers in a nonadjacent VLR that has
not received the forward notifications, the new base station has to get the previous
base station information from the HLR and then send the previous VLR a recovered
message. Upon receiving this message, the previous VLR acts similar to the previous
VLR of case 3 . The forward notification scheme is unsuitable if the mobile unit
suffers failures with a very small EFT. In that case the mobile unit recovers in the
same base station where it failed. Hence, the forward notifications and subsequent
denotifications generate communication overhead. To alleviate this, we might delay
the sending of these notifications immediately on failure of the mobile unit. The
HoAg waits for an initial buffer time before it notifies the VLR regarding the failed
status of the mobile unit. ‘l’his time can be estimated by the HoAg in a way similar
to the estimation of ELUT without compromising the performance. We can reduce
the overhead further if we can reduce the number of recipients of the notifications.
If notifications are sent to only those VLRs the base stations of which are nearer to
the base station in which the mobile unit fails, the communication overhead can be
This chapter discussed a number of recovery algorithms for mobile database systems.
Some schemes were discussed in more details than others. l’hese discussions on
mobile database recovery clearly indicated that the entire process of chekpointingand
logging for rccovery are comparatively complex than conventional database rccovery.
There are are still quite a few research problems need innovative solutions. Until they
are resolved the mobile database system will continue to remain in research domain.
1. Discuss the problems of managing transaction log of a mobile database system
in a conventional way. Do you thmk it would even work?
2. If log management is a problem then do you think a shadow approach would
be good for mobile database recovery? Investigate and present your ideas.
3. Why the use of mobile agents provides a good way of handling database activities of mobile database systems?
1. A. Acharya and B. R. Badrinath, “Checkpointing Distributed Applications on
Mobile Computers,“ 3rd International Conference on Parallel and Distributed
Infomation Systems, 1994.
2. G. Eleftheriou and A. Galis, “MobileIntelligentAgents for Network Management
Systems,” London Communications Symposium, London, 2000.
3. S. Gadiraju, V. Kumar, and M. H. Dunham, “Recovery in the Mobile Wireless
Environment Using Mobile Agents,” IEEE Transactions on Mobile Computing,
Vol. 3, No. 2, April-June 2004.
4. J. Gray and A. Reuter, ‘liansactionProcessing Concepts and Techmques. Morgan
Kaufmann, San Mateo, CA, 1993.
5. M. M. Gore and R. K. Ghosh, "Recovery of Mobile Transactions," 1Ith International Workshop on Database and Expert Systems Applications, September 4-8,
6. J. Kiniry and D. Zimmerman, "A Hands-on Look at Java Mobile Agents," IEEE
Internet Computing, Vol. 1, No. 4, 1997.
7. D. Kotz, R. Gray, S. Nog, D. Rus, S. Chawla, and G. Cybenko, "AgentTCL:
Targeting the needs of Mobile Computers," IEEE Internet Computing, Vol. 1,
No. 4, 1997.
8. P. Krishna, N. H. Vaidya, and D. K. Pradhan, "Recovery in Distributed Mobile
Environments," IEEE Workshop onAdvances in Parallel and Distributed Systems,
Princeton, October 1993.
9. V. Kumar, M. H. Dunham, Nitin Prabhu and A. Y. Seydim,"TCOT - A Timeout
based Mobile Transaction Commitment Protocol," Special issue of IEEE Transaction on Computers, Vol. 51, No. 10, Oct. 2002.
10. Y.-B. Lin and I. Chlamtac, Wireless and Mobile Network Architectures, John
Wiley & Sons, New York, N. Y., 2001.
11. C.-M. Lin and C.-R. Dow, "Efficient Checkpoint-based Failure Recovery Techniques in Mobile Computing Systems," Journal of Information Science and Engineering, Vol. 17, 2001.
12. D. B. Lomet, "Application Recovery: Advances Toward an Elusive Goal," Workshop on High Pqformance Transaction Systems (HPTS 97),Asilomar, CA, Sep.
13. D. Lomet and G. Weikum, "Efficient Transparent Application Recovery In ClientServer Information Systems," in Proceedings of ACM SIGMOD Conference,
Seattle, WA. June, 1998.
14. D. B. Lange and M. Oshima, "Seven Good Reasons for Mobile Agents," Communication of the ACM, Vol. 42, No. 3 ,1999.
15. Y. Morita and H. Higaki, "Checkpoint-Recovery for Mobile Computing Systems,"
Springer Lecture Notes in Computer Science, Vol. 2070,2001.
16. V. K. Narasayya, "Distributed Transactions in a Mobile Computing System,"
1EEE Workshop on Mobile Computing Systems and Application, June 1994.
17. N. Neves and W. K. Fuchs, "Adaptive Recovery for Mobile Environments," Communications of the ACM, Vol. 40, No. 1, Jan. 1997.
18. T. Park and H. Y. Yeom, "An Asynchronous recovery Scheme Based on Optimistic Message Logging for Mobile Computing Systems," 20th International
Conference on Distributed Computing Systems, April 2000.
19. T. Park, N. Woo, and H. Y. Yeom, "An Efficient Recovery Scheme for Mobile
Computing Environments," Eighth International Conference on Parallel and Distributed Systems (ICPADS),2001.
20. C. Pedregal and K. Ramamritham, "Recovery Guaranteed in Mobile Systems,"
International Workshop on Data Engineering on Wireless and Mobile Access,
Seattle, August 20, 1999.
21. C. Perkins, "Mobile Networking Through Mobile IP," IEEE internet computing,
Jan. 1998.
22. D. K. Pradhan, P. Krishna, and N. H. Vaidya,"Recovery in Mobile Environments:
Design and Trade-off Analysis," 26thlnternationul Symposium on Fault-Tolerant
Computing (FTCS-26),June 1996.
23. R. Prakash and M. Singhal, " Low-Cost Checkpointing and Failure Recovery
in Mobile Computing Systems," IEEE Transactions on Parallel and Distributed
Systems, Vol. 7 , No. 10. Oct., 1996.
24. D. VanderMeer, A. Datta, K. Datta, K. Ramamritham, and S. B. Navathe, "Mobile
User Recovery in Context of Internet Transactions," IEEE Transactions on Mobile
Computing, Vol. 2, No. 2, April-June 2003.
25. Y. B. Yao, K. F. Ssu, and W. K. Fuchs, "Message Logging in Mobile Computing,"
IEEE Fault-Tolerant Computing Symposium, June 1999.
Wireless Information
This chapter introduces the topic of data dissemination through wireless channels. The
data dissemination discipline gives an illusion that the space is an infinite size persistent data storage from where a user can download desired information. For example,
information about airline schedule, weather, stock quotes, etc., can be downloaded
from the broadcast. Initially, data dissemination system appeared as an information
dissemination tool similar to radio broadcast, but with advances in wireless and satellite communication, it is becoming an information management system as well. This
chapter discusses data dissemination technology and development of schemes such
as indexing, push and pull, data staging, surrogates, and so on, for incorporating
transactional facility. The discussion in this chapter is based mostly on research reports because a truly data broadcast system has not been developed and deployed for
commercial use. It also discusses in detail the architecture and working of a reference
data dissemination and processing system called DAYS (DAta in your Space).
The discipline of data dissemination through wireless channel, that is, data broadcast,
has added another dimension in the area of mobile computing. The mobile database
systems, discussed in preceding chapters, provided terminal and personal mobility
in information management, and the wireless data dissemination took mobile systems one step further and allowed the user to tune and access and process desired
information from anywhere in the world.
Accessing data from wireless channel is a very useful facility because it allows users
to get desired data through many computationally enabled devices such as cellular
phones, PDAs, other new devices. Manufacturers continue to develop increasingly
powerful mobile devices while decreasing their size and cost. If it is assumed that
there is an abundance of wireless channels, then servers can continue to push all data
users can ever need on these channels and users can pull whatever they require. This
is an ideal scenario. In reality, wireless channels are always less than the number
required to satisfy users’ demands. Thus, the task of data dissemination technology
is to develop ways for satisfying users’ data demand with limited wireless resources
Data broadcast is predominately user-independent. The users are passive in that
they can only read what is contained in a broadcast. While this model fits well into
some types of data dissemination (such as local traffic information), it is not general
enough for many different types of applications. Some examples can help to identify
its usefulness and limitations.
American Automobile Association (AAA) provides support services for drivers
in the United States. One of the major support functions is to provide Tourbooks
which contain travel information as well as hotel/motel information for areas
across the United States. When a traveler today is planning a vacation to Florida,
he can obtain for free a tourbook on Florida. A perfect application of broadcast
would be to broadcast tourbook information.
The Kansas City airport has thousands of arriving and departing flights daily.
Determining the gate and time for various flights can be challenging for persons
travelling to the airport. Current support requires either calls to specific airlines
or tuning into predefined stations on local radios or to visit an airline web site.
Kansas City airport could, instead, provide a broadcast to a local area.
It is possible to obtain this information from the web site of the airline; however, this
requires an access to the web and the URL, and the mobile unit must have a browser
installed. An approach might be to have changes made to web data be automatically
used as the source for the broadcast. Thus triggers associated with web data would
force changes to the broadcast data.
The traditional view of access to data from a broadcast is shown in Figure 9.1.
The mobile client reads data from the wireless broadcast. The Sewer maintains the
primary data repository and pushes data (broadcasts data) to users through the base
The architectural model used for data broadcast is shown in Figure 9.2. Clients
tune and download desired data from a broadcast.
Fig. 9.1 Traditional mobile data access from a broadcast.
Fig. 9.2 Broadcast data access model.
Data Broadcast Mode
The mode of data transfer is essentially asymmetric, that is, the capacity of the transfer
of data from the server to the mobile client downstream communication is significantly
larger than the client or mobile user to the server upstream communication. The
effectiveness of a data dissemination system is evaluated by its ability to provide a
user his required data ubiquitously. There are two basic modes of data dissemination.
These modes are motivated mainly by limited power consideration. The lifetime of a
battery is expected to increase only 20% over the next 10 years 1221. A typical AA cell
is rated to give 800 mA/hour at I .2 V (0.96 Whour). The constant power dissipation
in a CD-ROM (for disk spinning itself) is about 1 W, and the power dissipation for
display is around 2.5 W. The available power source is likely to last for 2.7 hours and
to preserve battery power; these activities must be disabled whenever possible. The
Hobbit chip from AT&T allows the operation in two modes: (a) active mode - the
full operational mode where CPU and all other components are in running state and
(b) doze mode - the power conserving mode where the CPU is inactive. The power
consumption in the active mode is 250 mW, and the power consumption in doze mode
is 50 pW. The ratio of power consumption in the active mode to doze mode is 5000.
When the mobile unit (palmtop) is listening to the channel, the CPU must be in the
active mode for examining data buckets in the broadcast. The CPU consumes more
power than some receivers, especially if it has to be active to examine all incoming
buckets. Therefore, it will be beneficial if the CPU can be switched to the doze mode
whenever it is not being used and switched back to active mode when the data of
interest arrives on the broadcast channel. This facility is called selective tuning.
Transmitting and accessing data also consumes power. A number of factors like
the terrain, landscape, the height and kind of trees, foliage, season, rain, etc., play an
important role in determining the power required in data dissemination. With distance
the power requirement increases significantly 1261. For large cells the energy required
for transmission could reach tens of watts. For example, a Wavelan card consumes
1.7 W with the receiver powered on and 3.4 W with the transmitter powered on.
The effective bandwidth of wireless network is only a fraction of the bandwidth
that is available in wired networks. The current ATM (Asynchronous Transfer Mode)
standards are designed to yield a bandwidth of up to 622 Mbps. This bandwidth is
projected to go up to gigabits [20]. The wireless bandwidth varies from 1.2 kbps for
slow paging channels to about 2 Mbps of the wireless LAN.
Data broadcast can be managed with three different modes to satisfy user needs.
These modes are further elaborated later in this chapter as Push and Pull technology.
Broadcast Mode: In this mode the broadcast server periodically broadcast most
popular data on some wireless channels from which users can listen and, if necessary,
download the required data. There is no uplink channel involved in this mode. Simple
filtering of broadcast data stream according to a user specified filter [6] is applied to
access data.
On-Demand Mode: This mode allows a client to request specific data which is not
available in the current broadcast or may never appear in the broadcast. The client
sends the query for the required data through an uplink channel.
Hybrid Mode: In this mode, broadcast and on-demand modes are combined. The
server allows individual data requests from clients through uplink channel and allows
data broadcast through downlink channel. It also, if necessary, broadcasts on-demand
data if its popularity matches the popularity of broadcast data.
Pull Process
Pull process is user (client)-oriented. A user assumes that the desired information is
available in the wireless space, and he pulls it by tuning the channel. For example, a
user keys in a URL on the web browser and pulls the desired information. The server
is not concern with the individual user’s access. It is also immaterial whether the
user finds the desired data or encounters an error or delay occurs in downloading the
data. In day-to-day activities, pull process is frequently applied: borrowing a book
from a library, renting a movie or music CD, buying an airline ticket, and so on. It is
clear from these examples that in pull the user initiates a conditional information flow
where the condition is defined by the user with an understanding that the condition is
likely to be satisfied-for example, renting a movie with a particular title, purchasing
a ticket for a particular destination, and so on. Using an e-mail facility may appear
to follow pull process, but actually it is not so. A recipient of an e-mail does not
select the e-mails he receives; rather they are dropped in the user’s space without his
knowledge and they just appear on his e-mail directory, some as spam but some quite
useful. It is also clear that what a user intends to pull may or may not be present in
the pulled information. For example, pulling information from Google with some
condition brings quite a lot of trash along with the desired information. An intelligent
pull technique such as a semantic web has yet to be fully developed.
Advantages of Pull: It is user-friendly and provides interactive capability to users
for accessing the information through query. The user does not need to search in the
wireless information space by tuning several channels.
Disadvantages of Pull: In wireless data dissemination platform, the pull approach
is resource-intensive. A user requires a separate channel to send the request as a SQL
query or in some other form to the server for the desired information. The server,
after receiving the request, composes the result and must send it to the user on a back
channel (downstream) known to the user. Thus every pull needs two channels for
completing the process successfully. If there are a large number of users and they
need identical information, then each user will occupy two channels with identical
data on all back channels. This cannot be easily afforded because of narrow bandwidth
available for wireless communication. It appears from these limitations that pull is
good for special cases of data retrieval.
Push Process
In the push process, the server broadcasts data (pushes data) on one or multiple channels. For example, it can push weather information on one channel, traffic information
on another channel, and so on. Clients, depending upon their data requirements, tune
the appropriate channel. In a push system a client cannot send a specific query to the
server, nor is the server broadcast client-specific.
The push technology was introduced somewhere around April 1996 by an internet
company called PointCast Inc. The company started push scheme by broadcasting
selected news and stock quotes to a client’s machine at predefined intervals [ 141. The
client tuned and downloaded information at these intervals. This was the beginning of
an effective way of reaching a larger number of customers. Developers and researchers
found the push scheme quite useful; since then, it was deployed on the internet in
many ways such as webcasting or netcasting. Sometimes it is also called PointCusting
to honor the company which invented it.
The main objective of push technology was to handle the problem of information
overload due to low bandwidth which restricted users to receive multimedia contents.
The push scheme provided an effective means to pre-deliver much larger packages of
audio, large graphics, or short video clips.
The push technology can be augmented with a number of mechanisms to increase
its scope and effectiveness. For example, message indexing can be implemented to
speed up broadcast search, caching can be used to reduce data miss, data staging can
be augmented to enhance data availability, personalization of channel contents can
help to satisfy specific user, the smart-pull approach can assist users to get specific
information, and so on. These topics are discussed in detail in subsequent sections.
Push Application
The push technology has been deployed for sometime in many real-world activities
such as in the financial world to broadcast stock quotes, mutual funds costs, real state
costs and inflation status, news, cable television broadcast, etc. Nearly all software
manufacturers use push to broadcast application and system updates and fixes to
clients’ machines. Many companies use this technology for advertisement. In fact,
most of the commercials on broadcast media such as television, radio, etc., are pushbased. Companies are at a great advantage for making use of the push technology
which allows them to make instant changes in the broadcast or refresh it entirely based
on users’ feedback to increase their effect on consumers. It is not now necessary for
them to rely on a human operator to search a site for outdated material. The push
technology applies to entertainment and leisure equally effectively.
The push technology is especially useful in the intranet market. Companies can
push on their intranet corporate information to employees using a predefined schedule.
It guarantees identical message delivery, which is highly desirable, to all employees.
Accessing Information from Broadcast
Clients can access and download required information in a variety of ways, which
depends upon how the broadcast was composed and pushed on the channel by the
server. In a channel the push is strictly sequential. Data are dropped in the channel,
one at a time. This can be viewed as a string of different categories of data. For
example, if the broadcast is composed of weather information, traffic information,
and dining places information, then they will appear on the broadcast sequentially in
the order they were dropped in the channel. The client will receive the broadcast in
the order sent by the server.
At the client’s end the Fimplest way to access the information is sequentially.
In most cases this access is time consuming. A client, if interested only i n dining
information, has to tune and wait until the dining information appears in the broadcast.
In a wireless platform, any waiting-let alone waiting for information to appear-is
quite resource-expensive, especially from a bandwidth viewpoint. An ideal scheme
is to tune when the desired information appears (e.g., selective tuning) and download
the data; that is, the waiting time for information access is zero. It is impossible
to implement the ideal scheme, but the access time can be significantly minimized
through efficient indexing and carefully composing the broadcast. Such arrangements
actually create a notion of smart-pull where client can pull exactly the information
he wanted with minimum redundancy. However, even though push applications are
not really push, there is a difference in them. The difference is the automation of the
process both for the server and the client. There are a couple of true push technology
applications-for example, products like AirMedia Live and Wayfarer (INCISA).
Push Advantages and Disadvantages
Push technology has been a favorite choice of data dissemination because of its
several advantages. It has, however, several disadvantages which makes it unsuitable,
especially for providing transactional facility [ 141.
In a large information flow it minimizes the burden of acquiring data. The server
can keep the information up to date by broadcasting it on a regular interval;
consequently, the user always has the latest information. A user is aware of the
broadcast channel carrying the information and the exact location of the data
in the broadcast. This setup significantly reduces the search time.
Sends the user the time-critical data for immediate attention.
Helps organizations (academic, business, or commercial) to identify, focus,
and reach those users with precision who are more likely to benefit from their
products or services.
Automatically delivers directly to clients’ machines software upgrades and fixes
faster and, at the same time, reduce or eliminate the shipping cost. This facility
requires a mechanism to check clients’ machines for software and configuration
and then modify these configurations.
Uses incremental updates where only new and changed information has to be
sent to the computer which significantly reduces access and download time.
Helps server to reserve more processing time for data production by avoiding
to handle numerous client requests individually.
Shortens response time.
Easily protects user privacy because push applications run mostly at the client
machine and client’s profile and the log information about the client’s behavior
are stored on the client’s computer.
Enables intelligent information filtering based on personalized user profiles
describing required information needs.
Satisfies a large client base using few resources.
The push technology, while it is useful in a number of situations and does conserve
resources and energy, has a number of limitations and disadvantages [ 141. Some
important ones are given below.
Push applications are complex, and the development cost (time and resource)
are generally high compared to creating static pages. Static pages can be viewed
by any browser on any operating system, but the push system requires specific
tools and applications.
It requires more powerful hardware and specialized software to provide push
Identifying the location of the desired information in the broadcast and downloading the multimedia contents require a huge amount of disk storage.
It suffers a number of unresolved bandwidth problems. Problems arise due
to the enormous bandwidth that push technologies can require when feeding
data to thousands of end users. Caching proxy servers, for example, as well
as multicast solutions, will likely solve many of the bandwidth problems of
push and allow it to scale. Some providers allow users to choose when the
information is downloaded, so users can schedule it for times that they will be
away from their computer.
The push scheme is still not that useful for individual users; however, the
emergence of music P2P systems has made it quite popular. Its usefulness is
still confined to organizations that have a good customer base.
In multiple push a user can get frequent interruption. For example, during a
song broadcast, some urgent message can appear to notify user of some serious
event. Although users get the information, they may have to live with constant
interruption. Such interruptions cannot be preplanned because they may occur
Push system software may suffer with incompatibility problem. Many vendorsAir Media, Alpha Microsystems, Berkeley Systems, IntraExpress, Marimba,
Pointcast, to name a few, develop application software with minimum portability and scalability. Competition to dominate the information space in this
technology is growing fast and vendors are unable to develop software compatible to all systems.
The push technology is not good for the typical knowledge worker who mines
information from a variety of sources and then draws conclusions by digesting
that information [ 141.
Creating and maintaining user profiles is time-consuming. This becomes more
expensive with number of users. One of the main reasons is that users’ information needs are constant to some degree only.
There is no reliable solution to achieve secured broadcast. Security safeguards
are highly needed.
Standards are currently lacking in this area (competing de facto industry standards are pushed by companies) [14].
Market for Push Technology
Microsoft Corp. and Netscape Communications Corp. are the two leading competitors in the push technology. Microsoft is pushing the Extensible Markup Language
(XML)-based Channel Definition Format (CDF) for defining push updates. Netscape
is using the Meta-Content Format (MCF), which was invented by Apple Computer.
For example, Marimba Inc. has begun cooperation with Netscape. Microsoft and
Netscape each have created their own push clients for use in conjunction with their
latest browsers. The push market can be divided into four basic categories [14]:
Application Distributor: The products of this category such as Marimba’s
Castanet provide automatic delivery of application software to end users.
Content aggregator: The products of this category-for example, PointCast
Business Network-gather and format the contents in a consistent wrapper and
push it to users’ workstations.
Platform provider: The products of this category-for example, BackWeb-are
similar to content aggregators, except they are actually infrastructure to deploy
content delivery systems.
Real-time data transfer: The products of this category-for example, TIBCO
and Wayfarer (1NCISA)-offer the advantage of multicasting. It is expensive to
implement, but they guarantee timely delivery of information possible.
Push information delivery models can be categorized at least into three main categories [ 141:
Push Server Model: It is the most common Push Server Model which provides
a client, a server, and development tools. A proprietary client is supplied,
and the applications may use a proprietary protocol. Both users and content
providers have control over the content. Some examples of this model are
BackWeb and Marimba’s Castanet.
Web Server Extension Model: In this model, the push vendor directs feedback
and demographic information to an external server, so that information can be
retained by the push vendor. No proprietary client is required. These run within
the user’s installed browser, such as Pointcast or the server delivers content
using e-mail, such as ChannelManager and InfoBeat.
Client Agent Model: This model uses a “client agent” to retrieve the information from the web. Each agent is designed to provide different search results
and allows us to establish an anonymous relationship between the vendor and
the subscriber. The user is responsible for deployment and the search type
In this section a novel broadcast scheme called broadcast disk is discussed. The
main idea of this scheme is to efficiently use the available bandwidth to push data
to a majority of users. This approach created the notion of multiple disks spinning
at different speeds on a single broadcast channel to create an effect of a fine grained
storage hierarchy. The broadcast data on a faster disk are pushed (repeated) more
frequently than the dataon slower disks (channel). Users tune to these disks (channels)
and download their desired data [6, 171.
Fig. 9.3 A simple broadcast disk setup.
Figure 9.3 illustrates a simple broadcast set up using broadcast disk approach.
The broadcast station has a channel on which it continuously broadcasts (pushes)
data items A, B, C and D in that order. The oval represents a broadcast disk (channel)
which if accessed (tuned) by a few mobile devices. If the broadcast station has
a number of channels with different capacity, then each channel can be used ac a
different-size disk. This arrangement can be compared with radio broadcast where
different programs are transmitted over different stations (frequencies).
The relative speed of these disk3 in the air (airdisks) significantly affects the broadcast configuration. The speed can be tweaked to satisfy a variety of information needs
of users. In a similar manner, a set of different types of information such as weather,
traffic, stock quotes, airline schedule, news flashes, and so on, can be transmitted on
different speed channels.
Bandwidth Allocation
The way a set of information is arranged and pushed on to the broadcast channels is
called schedule. In an ideal schedule the latency time and tuning time are minimum.
Latency Time: Similar to conventional disk access, it is the total time for (a) a client
request to arrive at the server and (b) the time when the desired data is available in the
broadcast channel. This time becomes important especially in interactive applications
such as video games which require fast scan.
Tuning Time: It is the total time required to tune to the channel which is broadcasting
the desired data. This time becomes important for fast changing data such as stock
quotes. The client must be able to quickly tune to the right channel to get the data.
Access Time: Another parameter which is called access time is the total time to
download the desired data from the broadcast channel to a client's local storage. In
the push approach, an increase in length of the broadcast can lead to an unacceptably
long access time for the user.
Data Broadcast
ansas City weather = 70 degree. Soochna Inc. stock = $80. Tandoori Oven = Open from --
Fig. 9.4 Access and tuning times in a broadcast.
Figure 9.4 illustrates access and tuning time. A client submits a request at To
and receives the desired response at time T7. If the client listens continuously from
the time the query was submitted and until the response is received, then the access
and tuning times can be expressed as AT = TT = (T7 To). If, on the other hand,
the client slips into doze mode intermittently, that is, tunes selectively (selective
tuning), then the actual tuning time will be 7T = (T7 - T s )+ (Ts - T4)+ (Ts - T L )+
(TI-2'0). Tn selective tuning the mobile unit will be in doze mode (DM) for (TL-TI )
+ (T4 T j ) + (TG- T5). If DM > 7T then the tuning time saves energy and the
saving will be highest only if the client has accurate information about the tuning
time for accessing data. The task, therefore, is to find optimal points in the 2D space
of access and tuning times. This is quite difficult because there is a trade-off between
these two times. The access time depends on broadcast size, and the tuning time
depends on the identification of exact data location in the broadcast which is achieved
through selective tuning. Unfortunately, selective tuning requires extra information
to be appended to the broadcast data which increases the size of the broadcast. This
increase in size affects access time. An efficient broadcast scheme, therefore, must
balance this trade-off.
The broadcast program can be addressed in terms of bandwidth allocation. An
efficient bandwidth allocation scheme is directly linked with data popularity among
the client population. Client information requirement is highly random. Different
samples of client populations may have orthogonal data requirements. In some client
population, geographical information may be highly important and accessed most
frequently while some population may frequently access stock quotes, and so on.
Thus, the relationship among data popularity, client samples, and geographical domain becomes very complex, which makes it very hard, if not impossible, to develop
an optimal schedule for all situations. However, with the help of popularity compu~
tation, broadcast indexing, and broadcast composition an efficient schedule can be
(b) Skewed broadcast disk
(a) Flat broadcast disk
(c) Regular broadcast disk
Fig. 9.5 Three broadcast schedule samples.
Figure 9.5 presents three broadcast samples [4]. Schedule (a) is a flat schedule
where data items set D1, D2, and D3 continuously appear in the broadcast. Schedule
(b) is a skewed broadcast where data item D1 appears twice one after another followed
by D2 and D3. Schedule (c) is a regular broadcast where the inter-arrival time of each
page is the same. The difference between schedule (a) and (b) is quite obvious. In (b),
data item D1 is treated as more frequently accessed than other items on the broadcast.
The benefit of a particular broadcast schedule can be understood by thcir expected
access delay.
Access Frequency and Expected Delay
Two cases (a) flat broadcast and (b) skewed and multi-disk broadcast are considered.
Flat broadcast: If there are D = { d l , d z , . . ., d i L }data items in the broadcast,
then on the average one has to wait for 0 1 2 data items to access the desired item
d,. Thus expected delay is = D / 2 broadcast units. In reality, access frequencies of
data items vary and when this value is taken into consideration, then the access delay
significantly reduces.
Skewed and Multidisk broadcast: For each di E D the probability p , that di will
be accessed is given by
The expected delay for a data item d is computed as follows. Since the broadcast
time interval = 1, the delay in a request for d is
t )d t
N is the number of transmission intervals (duration of one transmission
interval is I ) ,
t is the arrival time of the request,
t;;:, , is the waiting time when request arrives at the start of the interval i.
If the transmission of a data item d, has already initiated, then the client waits for the
next broadcast to access d,.
The expected delay for all data items D with access probability p , is given by
Table 9.1 shows the computed expected delays for different access probability of
data items D1, D2, and D3.
Table 9.1 Expected delay with access probabilities [4]
Access Probability
Expected Delay
Skewed Multidisk
1 .oo
Mean Access Time: The mean access time can be minimized if each d , is equally
spaced in the broadcast. For any two data items d l and da:
E -P2
Minimum access time
x fi)
where p = probability of data access and .f = frequency of data access.
The data of Table 9.1 demonstrates a number of important points about a broadcast
disk scheme. With equal data access probability the flat schedule has the lowest
expected delay followed by multidisk schedule while the skewed schedule has the
highest access delay. In Ref. 141 this behavior was explained in terms of fixed
bandwidth. In fixed bandwidth all data items have equal space in the broadcast. The
server composes the broadcast uniformly for pushing it in to the channel. If a data
item is placed twice (skewed schedule) in the broadcast, then this arrangement will
take away some space from other data items. As a result, clients are likely to miss
an opportunity to tune and download the desired data in the first broadcast and must
wait for the subsequent broadcast. On the other hand, in the case of nonequal access
probability, the server assigns less "space" to data with low access probability and
more to data with high access probability on the broadcast. As a result, clients manage
to tune and download the desired data from the first broadcast most of the time. Thus,
in an extreme case where the access probability of D1 was 1, the multidisk scheduled
performed the best because most of the time clients got the desired data (i.e., D1)
from the first broadcast.
In real life the access frequency for data is always nonuniform. Furthermore,
this variation in access frequency depends very much on geographical location. For
example, in a place where the change in weather is quite frequent, such as London,
England, users will like to query the broadcast system for weather more frequently
compared to residents of California, USA. This real-life scenario indicates that a
multi-disk schedule may fit better for data dissemination system.
The usefulness of data dissemination system lies in its ability to broadcast a huge
amount of data on a number of topics such as weather, stock, entertainment, traffic,
and so on. The future broadcast systems are likely to be used as a large data warehouse
storing (pushing) a large amount of data on all topics. It may provide yellow pages
services, encyclopedia, dictionary, etc. This will require not only efficient broadcast
schedules but also a faster way to reduce the search space of requested data.
So far a data broadcast has been seen as a push-based system while a mobile
database has been seen as pull-based, where users initiate all kinds of transactions.
The trend now is to integrate both facilities into one infrastructure. A new generation
of data management system is thus capable of disseminating data for universal access
and at the same time efficiently process all types of transactions with full database
support as we are used to.
The main components of such a system are (a) data access frequency, (b) broadcast
schedules, and (c) data access from the broadcast. These components are discussed
in detail below.
Data Access Frequency
The aim of the broadcast server is to achieve the highest hit rate for every type of data
it pushes. This makes it necessary that the server must first identify a high demand
set of data, arrange them in a specific order considering the size of broadcast channel,
and broadcast them. The access frequency identification can be done in many ways,
for example, by (a) monitoring current access pattern by some means, (b) reaching
active clients to look at their data access history, (c) studying the market trends, and
so on. All these approaches essentially identify the access probability.
For achieving the highest data hit rate and highest channel utilization, static and
dynamic approaches can be used. In the static approach a user notifies the broadcast
server regarding its present and future data pull and approximate duration for their
use. The server will continue to broadcast the static data set for the defined period.
In the dynamic approach the data requirements will be identified using (a) Residence
latency (RL)and Expected Departure Time (EDT) [8], (b) Popularity Factor (PF)and
Ignore Factor (IF),(c) user movement, and (d) channel tunability.
RL and EDT: When the server decides to include an item in its broadcast, it also
needs to decide the length of time the item will remain in its broadcast set. To identify
the residency duration of a data item an RL value is associated with each data set.
The RL value for a specific data set is the average length of time a mobile user resides
in a cell, and it can be computed a priori based on the advanced knowledge of user
movement patterns and cell geography. A data item’s EDT from a broadcast can be
computed by adding the item’s entry into the broadcast and data’s RL.
PF: Popularity factor of a data set D at time T identifies the number of clients in
the cell at time T who are interested in D. It can be denoted as PFS or just P F n .
One way to maintain PF of a data item at the rerver in a cell is to increment it by
1 when a client requests D. The server also records the corresponding time. Let the
timestamp of the ith increment to P F D be denoted by Th. The popularity of D goes
down after its RL value, and a corresponding decrement of 1 is performed on the
value of P F n at time (Th + RL). This reflects the anticipated departure of the client
whose request caused the 7th increment. In reality the client population is very large,
as is the database to support their requests. Since the increment and decrement are
frequently invoked operations, one way to implement them is through an abstract data
type-for example, a PF queue with these operations.
The PF approach implies a priority scheme where the most popular data get maximum favor in broadcast. Starvation is inherent in all priority schemes. One of the
side effects of a priority approach is that a client need for low P F data may never
be satisfied. This may get worse if the client is highly mobile and suffers frequent
handoffs. If it is assured that a client’s need for a low PF data will be satisfied at least
once in each cell it visits, then the effect of starvation on client population can be
reduced. A simple approach could be based on waiting time of a low PF data item.
Under this scheme if the waiting time exceeds a predefined limit, then the data item
is pushed into the next broadcast. This scheme will work, but individually defining
a waiting time for individual data item would be time-consuming and difficult to
enforce fairness. A better approach is developed here through the concept of Ignore
Fuctor (IF).The task of IF is to ensure that less popular but long-neglected data items
have a chance to end in the broadcast with a high degree of fairness. The value of IF
of a data item can be computed as follows.
Ignore Factor: Suppose that a data item D was last included in the broadcast which
ended at time To. Data item D was dropped from a subsequent broadcast after To. At
this instance the I F of D (i.e., I F D )is fixed at 1 181. The next request for D arrives
at TTEqr
which means that D was “ignored“ between To and TTeq;
that iu, the IF of
D at any time T, (T, > TTep)
denoted by IF;% is equal to NumBroadcast(T,, TTFq)
+ 1, where NumBroadcast(T,, TTeq)
denotes the number of broadcast between TTeq
and T,. If a broadcast period of Ps is considered, then
Equation (9.5) is valid only for (Tz- TTeq)
5 RL. This is because a client who
requested data item D at time TTen
and no other request for D came after T T C y .
However, by the definition of RL given above the client is expected to depart at T d e p =
TTrqRL; if it happens, then there is no point in including D in the broadcast. Thus,
after T d e p , unless other requests for D arrived, the value of I F D should be reduced
to 1. It can be seen that the following corollary holds for any data item D,.
A simple way to compute IF for a data item is explained using Figure 9.6. Points
B3, and B4 denote the start of successive broadcasts. T T l rTT2,TT3,
Tr4 represent request arrival times for data item D, and TciFpl
and Tc1p.112show the
corresponding times when the client departs from the cells where requests originated.
Suppose that at B d all requests (i.e., TT1,TT2,TT3,
and TT4)have expired. In general,
at all broadcast points where the next broadcast set has to be decided-that is, at
successive broadcast points ( B l , Bz, B3, and B&all requests that arrived prior to
th broadcast preceding the next immediate broadcast are guaranteed to
Fig. 9.6 Computation of ignore factor for a data item.
have expired. This means that I F n needs to be computed based on the first request
th broadcast preceding the next immediate broadcast.
that arrived after the
For example, at B d , I F D needs to be computed based on Tr3. This means that the
server is require to keep track of the first request after the broadcast (B,) and can
ignore successive requests until the next broadcast. Thus, the server needs only to
maintain a list of
This can be easily done by keeping an ordered list in RAM
the request identity and its timestamp. The list will have
+ 1 elements with
identity 1 through
+ 1, where the timestamp that corresponds to the zth element
represents the first request for data item D after zth previous broadcast. The list is
updated at each broadcast, so an easy way is to use a circular queue. With this scheme
a data item can be accurately tracked in constant (z
The priority of a data item now can computed as follows:
x PF
where ASF is an Adaptive exponential Scaling Factor and its purpose is to increase
the inclusion probability of a data item with low PF value. Equation (9.6) explains
why the minimum value of IF was set to 1 and not 0. It can be seen that for IF =
0, the priority value is reduced to 0, which guarantees its exclusion from the next
broadcast. The equation also indicates that a data item which has been requested by a
large client population has a large P F value and relatively low IF value as compared
to a data item with a few requests. With its low PF value, it is likely to be omitted
from the broadcast which will increase its IF improving its chance to be included in
near future broadcasts.
It is possible that an item may be ignored for a long time. In this situation its IF
must dominate, which can be achieved through a larger value of ASF. ASF can be
precisely defined using Wij , which denotes the number of broadcasts client i waited
for data item j after requesting j . The Average Wait Count (AWC) for data item j can
be expressed as
where C, denotes the set of clients waiting for data item j .
Suppose Maximum Wait Count (MWC)defines the maximum number of broadcasts
a client is prepared to wait before its request is serviced. In this situation the values
of AWC and MWC is computed for computing the priority of a data item. If AWC >
DWC, then ASF is incremented by 1 ;and if AWC = DWC, then ASF does not change.
ASFis initialized to 1 for all data items, and it is reset to this value each time the item
is included in a broadcast.
Data Access Time
Data access time is the total time to download the desired data from the broadcast
to client's local storage. It has two components: (a) the identification of the starting
location of the desired data in the broadcast (i.e., from where the desired data begins)
and (b) data download from data location to the local store. The simplest way to
reach the data in the broadcast is to continuously listen to the channel after it has been
tuned and start downloading it when the data location is found. Figure 9.7 illustrates
a simple broadcast structure which allows simple sequential search for data without
selective tuning facility.
Data Server
Fig- 9.7 Simple broadcast composition.
Each type of data-for example, weather information-constitutes a broadcast segment or data. They are separated by some marker which indicates the starting of a
broadcast segment. The mobile unit may tune anywhere in the middle of a broadcast
and must wait for the marker to identify the starting of a segment. In the worst-case
scenario the unit may have to wait the entire broadcast cycle for the desired data.
This scheme is unsatisfactory from every respect: access time and energy cost.
A selective tuning is highly desirable, which means the client tunes only when the
desired data are available for download as explained earlier. Such reduction in search
space is effectively achieved by structuring the broadcast using indexing.
Broadcast Indexing
Structuring the data broadcast presents the same set of search problems as conventional data does, and in addition it has its own set of unique problems. They arise
because of the real-time constraints of the broadcast process and its limited bandwidth. The indexing scheme for data broadcast is time-based. It indicates to the user
at what time the desired data will be available from the last tuning to the broadcast
channel. For example, if the user tunes at 9:OO AM, then either the desired data will
be available to download or the index will indicate at what time after 9:OO AM the
data will be available for download. This information will allow the user to go in
doze mode or turn off the cell phone and re-tune the channel at the time indicated by
the index. Thus, one of the important properties of any index scheme is to indicate
precisely the tuning time, which is crucial in saving battery power. The other important requirement is that the indexing structure itself should take much less space
in the broadcast to allow the server to push maximum amount of user data. Thus,
indexing shrinks the data search space (i.e., broadcast space) which in turn reduces
search time and energy consumption. Figure 9.8 illustrates the position of index part
in the broadcast.
Fig. 9.8 Indexed broadcast composition.
Indexed broadcast allows selective tuning. The advantage of selective tuning can
be maximized by designing powerful indexing schemes. A number of schemes have
been developed in the last few years to handle efficiently varied data access needs of
clients. A partial list of the work is given here [l, 2, 7, 17, 18, 19, 23, 301. In this
section some of the earlier and also most recent index schemes are discussed in detail.
(1, m)Indexing structure
Fig- 9.9 Organization of ( 1 , m ) indexing scheme.
A simple indexing scheme called (1, n s ) scheme was discussed in Refs. [ 171 and
[19]. This scheme and its variants are described here in detail. Under this scheme
the index is broadcasted m, times during a broadcast of an entire file. This is done
by prefixing the entire index in front of
fraction of the file. The entire structure is
explained in terms of data bucket and index segment. The data bucket contains the
file data and the index segment contains the index. Thus, the index segment precedes
a data bucket. To broadcast an entire file a number of index segments is required.
Figure 9.9 illustrates the organization of ( I , rn) indexing scheme.
An index segment contains two pointers Nand L. N points to the last data segment
in the broadcast and L points to the data segment to be broadcasted next. To access
the desired data block the user executes the following steps:
Tune in to the right broadcast channel. If there is more than one broadcast
channel, then some directory is available to identify the correct channel for
If this is the data block, then continue tuning for the next index segment.
When the next index segment appears, tune to the index segment and get the
pointer ( N )to the next data segment. In the case of a multilevel indexing this
search will require continuous tuning until the index for the desired data is
After accessing the desired index, the mobile unit can go into doze mode and
resume tuning for the data when it appears in the broadcast. The client can then
download all the records of the data item.
The expressions for index tree levels, latency, tuning time, and optimum division
of the entire file in to data buckets are given below. The complete analysis of this
indexing scheme can be found in Ref. [ 191.
For a fully balanced index tree:
k = number of level in the index tree
n = size of a index segment in terms of (attribute value, offset) pairs
Index = the number of buckets in the index tree.
C = coarseness of the index attribute.
Latency =
Tuning Time:
+ ($ + 1) x Data) + C
1+ k + C. When a client starts tuning, the first probe gets the pointer
x ((m. 1) x Index
to the next index bucket. From here k probes are needed to follow the pointers in the
index block. In addition to this C more probes are required for getting the desired
records from the data block.
Optimum m: m* =
4 E .The entire file is therefore dividedinto m*equal data
Distributed Indexing
Distributed indexing scheme does not introduce a different way of organizing the
broadcast; it only restructures and distributes the index segment to optimize the use
of broadcast space.
Fig. 9.70 The organization of relevant index.
In the ( I , rn) indexing scheme the entire index segment is replicated in the broadcast even though the following data segment contained only a part of the file. This
observation suggests that only the part of the entire index which covers the following
data segment is sufficient and need to be included. This portion of the entire index
was referred to as relevant index and shown in Figure 9.10.
Index buckets (Non-Replicated Root NRR) = b l , b2, b3, b4, b5, b6, b7, b8, b9
Rep ( b l ) = (I, a l )
Rep (b2) = (al)
Rep (b3) = (al)
Rep (b4) = (I, a21
Rep (b5) = (a2)
Rep (b6) = (an)
Rep (b7) = (I,a3)
Rep (b8) = (a3)
Rep (b9) = (a3)
Ind ( b l ) = (bl, c l , c2, c3)
Ind (b2) = (b2, c4, c5, c6)
Ind (b3) = (b3, c7, c8, c9)
Ind (b4) = (b4, clO, c l l , c12)
Ind (b5) = (b5, c13, c14, c15)
Ind (b6) = (b6, c16, c17, c18)
Ind (b7) = (b7, c19, c20, c21)
Ind (b8) = (b8, ~ 2 2~, 2 3 ~
, 24)
Ind (b9) = (b9, ~ 2 5~, 2 6~, 2 7 )
Data buckets pointers = c l - c78
Data ( b l ) = (0, ...,8 )
Data (b2) = (9, ..., 17)
Data (b3) = (18, ..., 26)
Data (b4) = (27, ...,35)
Data (b5) = (36,...,44)
Data (b6) = (45, ...,53)
Data (b7) = (54, ...,62)
Data (b8) = (63, ...,71)
Data (b9) = (72, ...,80)
Fig. 9.7 7 Organization of a file for broadcast.
Three different index distribution schemes have been presented here. These algorithms differ in the degree of replication of index. Figure 9. I 1 is used to explain the
working of each scheme. This figure shows the layout of a file with 81 data buckets.
Each square box at the lowest level represents three data buckets-for example, data
bucket 0, data bucket 2, and data bucket 3. The index tree is built on these data
buckets. Each index bucket has three pointers, for example, index bucket bl has three
pointers. The three pointers of the bucket c is represented just by one pointer pointing
to a data bucket-for example, data bucket 0.
Nonreplicated Distribution: There is no index replication. Index segments
are disjoints.
Entire Path Replication: The path from the root to an index bucket-say, B-is
replicated just before the occurrence of B.
Partial Path Replication: This is also called Distributed Indexing. If there
are two index buckets-say, B and B'-then it is enough to replicate just the path
from the least common ancestor of B and B', just before the occurrence of B'.
In this arrangement, some additional information is included for navigation to
find the correct data segment.
Fig. 9.12 Nonreplicated distribution.
The working of these three schemes are described in Figures 9.12,9.13, and 9.14.
In these figures, the current broadcast is represented in three levels. The broadcast
channel is organized by taking the first level followed by the second and then finally
by the third level. In order to understand the data access, consider that a client requires
a record in data bucket 66. The client makes the initial probe at data bucket 3.
Nonreplicated Distribution: Figure 9.I 2 illustrates the broadcast structure for this
scheme. The bcast-pointer at bucket 3 directs the client to the beginning of the next
broadcast in which the clients probes a3, b8, c23, and bucket 66. Since the root
of index is broadcast only once for each broadcast, the initial probe will result in
obtaining the offset to the beginning of the next broadcast. In order to determine the
occurrence of the required record, the client has to get to the root of the index. Hence,
the probe wait for this scheme will be quite significant and will offset savings in the
broadcast wait due to the lack of replication. The offset at data bucket 3 could have
directed the client to index bucket b2,in which case the client could make the following
successive probes: b2,b3, a2, a3, b8, c23, and bucket 66. The client need not have
made an extra probe at b3. There are three pointers per index bucket, four levels in
the index tree, and one extra probe was made. The number of extra probes grows
linearly with the increase in the number of pointers in the index bucket, and it also
grows linearly with the number of levels in the index tree. This becomes substantial
as the number of data buckets and the capacity of the index bracket increases. The
tuning time is no longer logarithmic in the number of data buckets.
Fig. 9.13 Entire path replication.
Entire Path Replication: Figure 9.13 illustrates the index distribution when the
entire path from root of the index tree to each index buckets b, is replicated. The
replication is just before the occurrence of h, . The offset at data bucket 3 will direct
the client to the index bucket I that precedes secondal. Then, the client makes the
following successive probes: jirsta3, b8, c23, and bucket 66. The latency suffers
from the replication of index information. In this example, the root was unnecessarily
replicated six times, as demonstrated below.
fig. 9.14 Partial path replication-distributed indexing.
Partial Path Replication - Distributed Indexing: Figure 9.14 shows that latency
can further be improved by replicating only a part of the entire path. In this arrange-
ment the root I is no longer replicated many times. The offset at the data bucket 3 will
direct the client to secondal. However, to make up for the lack of root preceding
secondul, there is a small index called the control index within secondal. If the local
index (in secondul) does not have a branch that would lead to the required record,
then the control index is used to direct the client to a proper branch in the index tree.
The control index in secondal directs the client to i 2 . At i 2 the root is available and
the client makes the following probes: jirsta3, b8, c23, and bucket 66. In the case
where a record in bucket 11 was being searched by the client, reading the bucket
secondal would provide the client with the required information to successively tune
in at 152,c4, and bucket I 1. In this case, having the root just before secondal would
have been a waste of space (this is true if the search key was in any data buckets 9
through 26). The additional space that is necessary to store the control index is a
small overhead compared to the savings resulting from partial index path replication.
Replicated buckets can be modified by removing the entries for records that have
been broadcast before the occurrence of that bucket. This will result in some space
savings, which, when amortized over all the replicated buckets in the broadcast, will
make up for the space taken up by the control index.
Control index at first-a,
Control index at second-a,
! 26
Control index at third-a,
Control index at second-a,
Control index at third-a,
Control index at second-a, P T B e E ]
1 8 0 - k
' T d
Control index at third-a,
Control index at first-a,
Control index at first-a,
Control index at i,
Control index at i,
171-7 Begn I
r i i 7 ~egln
Fig. 9.75 Control index.
Figure 9.15 shows the control index for index buckets that are part of the index
tree described in Figure 9.19 and whose layout is shown in Figure 9.14. The first part
of each control index element denotes the search key to be compared with, during the
data access protocol. The second part denotes the pointer to be followed in case the
comparison turns out to be positive. For example, if a record in bucket 5 8 is being
searched for, then the control index at secondul directs the client to the beginning
of the next beast. However, if a record in bucket > 26 is being searched for, then the
search is directed to i2. Otherwise the search in the control index fails and the rest of
the secondal is searched.
Distributed indexing Algorithm
Given an index tree, this algorithm provides a method to multiplex it together with
the corresponding data file on the broadcast channel. Thus, the distributed indexing
method is not a new method of index construction but a method of allocation of a file
and its index on the broadcast channel.
The distributed indexing algorithm takes an index tree and multiplexes it with data
by subdividing it into two parts:
I. The replicated part
2 . The nonreplicated part
The replicated part constitutes the top r. levels of the index tree, while the nonreplicated part consists of the bottom ( k - T ) levels. The index buckets of the ( T 1)th
level are called nonreplicated roots (NRR). The index buckets in NRR are ordered
left to right, consistent with their occurrence in the (r. 1)th level.
Each index subtree rooted in NRR will appear only once in the whole broadcast
just in front of the set of data segments it indexes. Hence, each descendant node of'
a of the NRR index will appear only once in a given version of a broadcast. On the
other hand, the number of replications of each node of the index tree that appears
above NRR is equal to the number of children it has.
R = root of the index tree.
B = an index bucket belonging to NRR
Br = ith bucket in NRR.
Path(C, B) = sequence of buckets on the path from index bucket C to B (excluding
Data(B) = set of buckets indexed by B .
Ind(B) = part of index tree below B (including B ) .
LCA(B,, B k ) = least common ancestor of B, and B k in the index tree.
Let NRR = {Bl,
B2 . . . B,} and let first bucket in NRR is Rep(&) = Path([. BI),
Thus, Rep(&) = Path(LCA(B,-,, B,), B,) for z = 2 , . . . .t.
Thus, Rep(B) refers to the replicated part of the path from the root of the index
tree to index segment B . Ind(B) on the other hand refers to the non-replicated portion
of the index. Figure 9.15 shows the values of Rep, Tnd, and Data for each of the index
buckets in NRR. Each version of the broadcast is a sequence of triples: < Rep(B),
Ind(B), Data(B)> YB ENRR in left to right order.
Let P I ,Pz . . . P, denote the sequence of buckets in Path(1, El). Control index is
stored in each of the P, index buckets.
Let Last(P,) denote the value of the attribute in the last record that is indexed by
bucket P,.
Let NEXTn(z) denote the offset to the next occurrence of P, (which in turn is
the index bucket at level i in Path(1, B). Let 1 be the value of the attribute in the last
record broadcast prior to B and let begin be the offset to the beginning of the next
broadcast. The control index in P, that belongs to Rep(B) (i.e., it precedes Ind(B)
and Data(B) have the following i tuples:
[ I , begin]
[Last(P& N E X T o ( l)]
[Last(P3),NEXTB (2)]
... ...
[Last(P,), NEXTB (i- 1)]
The control index in bucket Pi is used as follows: Let K be the value of the attribute
of the required records. If K < 1 , then the search is directed to the beginning of the
next broadcast (i.e., the begin pointer is followed). If the result of the comparison is
false, then ( K > Last(Pj)) is checked for smallest such j to be true. If j 5 i , then
N E X T B ( ~ 1) is followed, else the rest of the index in bucket Pi is searched as in
conventional indexing.
The access protocol for a record with attribute value K is as follows:
I . Tune to the current bucket of the broadcast. Get the pointer to the next control
2. Tune again to the beginning of the designated bucket with control index. Determine, on the basis of the value of the attribute value I( and the control index,
whether to:
Wait until the beginning of the next broadcast (the first tuple). In this
case, tune to the beginning of the next broadcast and proceed as in step 2.
Tune in again for the appropriate higher level index bucket; that is, follow
one of the "NEXT" pointers and proceed as in step 2.
Probe the designated index bucket and follow a sequence of pointers (the
client might go into the doze mode between two successive probes) to
determine when the data bucket containing the first record with K as the
value of the attribute is going to be broadcast.
Tune in again when the bucket containing the first record with K as the
value of the attribute is broadcast and download all the records with K as
the value of the attribute.
Let Index denote the number of buckets in the index tree. Let Level[r] be the number
of nodes on the rth level of the index tree and let Index[r.] be the size of the top r
levels of the index tree. Let AIndex, denote the additional index overhead due to the
replication of the top r' levels of the index tree. Finally, let h' denote a nonreplicated
root (NRR).
Latency: The latency is a sum of the probe and the broadcast waits. The detailed
computation of the following probe wait, the broadcast wait, and A In d e x , is described in [ 171.
broadcast wait
+ 11
(Index - I~idex[r]
Levellr 11
- x (Data
+ 11
+ Iridex+AIndex,.) + C
Tuning Time: Tuning time primarily depends on the number of levels of the index
tree and the coarseness C of the given attribute. The initial probe of a client is for
determining the occurrence of control index. The second probe is for the first access
to control index. The client is directed to the required higher level index bucket by
the control index. Next, the number of probes by the client is equal to at most k , the
number of levels in the index tree. The last pointer in the index tree points to the next
occurrence of the required data bucket. Finally, the client has to download C buckets
of the required records. Thus, the tuning time using distributed indexing is bound by:
Optimizing the Number of Replicated Levels: Optimizing the number of replicated levels only affects the latency. This optimizing can be accomplished by choosing
r' in such a way that, the following expression is minimal:
Index - Index[r]
Leveikr 11
1,evelIr 11
Given a particular index tree, Equation (9.8) is evaluated for r' ranging from 1 to k
(the number of levels in the index tree). The value of r' obtained from Equation ( 9.8)
is the optimal number of replicated levels.
In general, the distributed indexing algorithm has a much lower latency than the
(1 m ) indexing scheme. Both (1,r n ) indexing and distributed indexing have a lower
latency than tune-opt. Distributed indexing achieves almost the optimal latency (that
of 1o,tency-opt).
The tuning time due to t u n e a p t and (1,m)indexing is almost the same. The tuning
time of distributed indexing is also almost equal to that of the optimal (tune-opt);the
difference is always just two buckets. The tuning time of latency-opt is very large
and is very much higher than the other three. A detailed comparison between (1, m)
indexing and distributed indexing is presented in Ref. [28].
Nonclustering Index
Usually at most one index is clustered. Other indexes are defined over nonclustered
attributes. In this section, we discuss index allocation for nonclustered attributes. To
this end, we generalize the distributed indexing algorithm developed in the previous
section. The proposed generalization is based on the observation that even if a file
is not clustered on a particular attribute, it can always be decomposed into smaller
fragments that are clustered.
As in the case of clustered index. we first define two benchmark algorithms that
are one-dimensional optimal solutions: one which provides optimal latency but has a
very poor tuning time and another which provides optimal tuning time but has a poor
Nonc/uster-/atency_opt~This algorithm is similar to the latency-opt algorithm.
The best latency is provided by this algorithm because no index is broadcast with
the file. Clients tune into the broadcast channel and listen continuously until all the
required records are downloaded. For a file of size Datu, the latency is Data. This is
because the records are nonclustered and hence distributed across the file. The tuning
time is the worst and equal to Data (clients have to be in the active mode throughout).
Noncluster-tune-opt: This algorithm is similar to the tuneapt algorithm. The index of the file is broadcast in front of the file. Index entries point to the first occurrence
(in the current broadcast) of a record with a given attribute value. Additionally, all
records that have the same attribute value are linked by pointers. The client that needs
all records with attribute value K tunes into the broadcast channel at the beginning of
the next broadcast to get the index. It then follows the pointers from one index level
to another in a successive manner, to the first occurrence of a record with attribute
value K . It then downloads all consecutive records with that attribute value. Then it
follows the pointer to the next occurrence of records with the same attribute value;
this is done until the end of the current broadcast. Assuming that the nonclustering
attribute has a coarseness of C (buckets), the tuning time is equal to ( k + C),where k
is the number of levels in the index tree of the nonclustered attribute. This method has
a poor latency because the client has to wait until the beginning of the next broadcast
even if the required data are broadcasted immediately after the initial probe of the
Nonclustered Indexing Algorithm
The method of organizing the index for a nonclustering attribute is a generalization
of distributed indexing scheme. The structure of the file is as follows:
The file is partitioned into a number of segments called metu segments. Each
meta segment holds a sequence of records with nondecreasing values in the
nonclustering attributes. Even though the entire file is not clustered on the
index attribute, the meta segments are clustered based on the index attribute.
The scattering factor of an attribute is defined as the number of metu segments
in the file.
Each meta segment is further divided into a number of data segments. Each
data segment DS(K) is a collection of records with the value of nonclustering
attribute equal to K .
The last element of each data segment DS(K) has an offset to the next occurrence of the data segment DS(K). The last DS(K) of a broadcast has an offset
to the fir\t occurrence of the data segment DS(K) in the next broadcast.
There is an index for each meta segment, and it indexes all the values of the
nonclustered attributes, rather than being restricted to indexing just the values that
occur in the current meta segment. Index entries corresponding to attribute values that
are present in the current meta segment will point to the appropriate data segments
within the meta segment. For attribute values that do not occur in the current meta
segment, the pointer in the index tree will point to the next occurrence of the data
segment for that value. The nonclustered index is organized as in distributed indexing
for each meta segment separately.
Each meta segment is partitioned by a set of index segments. Each index segment
is a set of index buckets. Let IS(K) denote the index segment immediately following
the data segment DS(K) The first element of IS(K) is an offset to the beginning of
the next meta segment. Clients looking for records whose attribute value 1’ is l e s e r
than K use this offset. The remaining elements of IS(K) are built as a directory with
offsets to the next data segments D S ( P K < P 5 L ) , where L denotes the largest
value of the attribute. The directory here corresponds to Rep(B) followed by Ind(B),
where B is a bucket belonging to NRR as defined in distributed indexing. As in the
case of distributed indexing, even here the index segment contains a control index.
However, the first tuple in the control index is a new element. This new element
indicates the total number of buckets # B in the broadcast. Each data bucket has an
offset to the next index segment. The access protocol for following the pointers i n
IS(K) is exactly as in distributed indexing.
Figure 9.16 shows a file that has a nonclustering attribute b. It shows various
meta segments and data segments. The file is partitioned into data segments
for attribute b. The data segments for b are DS(bl), DS(b2), and DS(b3). Figure
a2 b l c l
a2 b l C3 DS(b1)
. .
a4 b l c2
Index segment
Meta segment
a3 b2
a1 b2 c l
Index segment
a1 b3 c l
a3 b3 c2 DS(b3)
a4 b3 c l
Index segment
a' b1
a4 b l c
Meta segment
1 Index segment I-
Meta segment
a3 b3 c3
a1 b3 c3 DS(b3)
a4 b3 c2
Index segment
a1 b l c l
a2 b l c l
a4 b l c l Ds(bl)
a1 b l c3
Index segment
a4 b2 c l
a2 b2 c3
a2 b2 c2
a3 b2 c3 Ds(b2)
a4 b2 c2
a1 b2 c3
Index segment]
a2 b3 c l
a4 b3 c3 DS(b3)
a1 b3 c2
1 IS (bl): non
b2 0
b3 1
Fig- 9.16 Example of nonclustered indexing.
9.16 also shows the index segment for bl and b3. The index segment in this
example appears after every data segment.
Each data bucket contains a pointer to the next occurrence of the index segment
for 0. Additionally, every data segment of attribute b contains a pointer to the next
data segment that contains records with the same value of the attribute. The pointers
for attribute value bl is shown in Figure 9.16. Finally, each data segment is followed
by an index segment which provides a directory to the nearest occurrence of data
segments for other values of b.
Immediately following (the second) DS(b1) is a pointer to the next occurrence of
DS(bl). This is followed by the index segment IS(b1). Consider the index segment
IS(bl), the first element is m n because there is no value for the attribute b that is lesp
than bl. The second value indicates that DS(b2) occurs after eight buckets. Note that
even though b2 does not occur in the current meta segment, there is an entry for it.
The third element indicates that DS(b3) occurs in the next bucket. For search keys
less than b3, the first element (only element) in IS(b3) directs the client to the next
The access protocol for records with the attribute value K is as follows:
Probe the current bucket and get the pointer to the next index segment. Go into
the doze mode until the next occurrence of the index segment.
Upon tuning in at the next index segment. get the number of buckets B in the
current broadcast. Then follow the pointers to get to the offset for DS(K). The
client might go into the doze mode between successive probes. Go into the
doze mode until DS(K).
Upon tuning in at DS(K), download all the consecutive records of the current
data segment and get the offset to the next occurrence of DS(K). Assume that
b denotes the number of buckets passed from the point the first index segment
was encountered. Repeat until ( b + offset < # B ) ; then exit.
Let C denote the coarseness of the nonclustered attribute. Let M denote the scattering
factor-i.e., the number of metusegments of the attribute. Data denotes the total number
of data buckets, and Index denotes the number of buckets occupied by the index tree.
Latency: Each metasegment has its own index tree that is distributed according to
the distributed indexing technique. Let AIndex denote the average index overhead
per metasegment. The broadcast wait is equal to the size of the whole broadcast, i.e.,
M * (Index + A Index) + Data
Note that the broadcast wait is slightly less than that given by the above formula.
This is because on the average only half of the last meta segment has to be accessed.
This is also true for the noncluster-latency-opt and noncluster-tune-opt algorithms.
This small difference is ignored for simplicity. The probe wait is analogous to the
probe wait in the case of distributed indexing with respect to a meta segment. Let r'
denote the average number of optimal replicated levels (within each meta segment)
in all the meta segments. Hence, the latency is:
+ A4 x (Index + AIndex)
+ ~ x ~ Data
+ Data
Tuning Time: In the first probe the client fetches a pointer to the next index segment.
After getting to the index segment a number of probes have to be made to find the
required data segment DS(K). The number of probes required for getting to DS(K) is
at most ( k + 1) (as in distributed indexing), where k is the number of levels in the index
tree of the indexed attribute. Once the first data segment D S ( K )is encountered, then
G probes have to be made to get all the required records. Furthermore, in the worst
case 11.1extra probes may have to be made. This is because the data segments may
not occupy an exact multiple of number of buckets, in which case the last bucket of a
given data segment might contain only a few records belonging to this data segment.
Nevertheless, this bucket has to be probed. This factor also needs to be added to the
tuning time of non-cluster-tune-opt for a general case. Therefore. the tuning time is
bounded by J + ( k + 1 ) + C + M , i.e. 2 + k + C + M .
The tuning time achieved by nonclustered indexing is always substantially better than
the tuning time due to nonclusterlatency-opt. The latency of nonclustered indexing
depends on the scattering factor M . Nonclustered indexing achieves a tuning time
close to that of the optimum (noncluster-tune-opt algorithm). Nonclustered indexing
achieves a latency close to that of the optimum (nonclusterlatency-opt algorithm),
when the scattering factor is small.
Tf the latency is very important, then noncluster_latency-opt is used. If the tuning
time is important, then either non-cluster-tune-opt or nonclustered indexing is used.
Nonclustered indexing and noncluster-tunespt have almost the same tuning time;
hence, when tuning time is of concern, the decision as to which of the two algorithms
to use depends on the latency for the two algorithms.
Multiple Indexes
Since all indexes and data share the same broadcast channel, it is important to specify
how indexes and data are going to be multiplexed.
Let each record of the file have n attributes. Assume that the attributes are ordered
according to the frequencies of their access. Let the leftmost attribute be the most
frequently accessed one, and let the rightmost one be the least frequently requested.
Let the sorted attributes be: w i , u2, ..., a,.
Partition the file into meta segments based on each attribute separately. The number
of meta segments for the attributes increase with the value of the subscript. Usually
only attribute a,l is clustered and the rest are nonclustered. Let us assume that the
indexes are available for the first I attributes. The total index overhead will depend on
the subscript of the index attribute-in general, the lesser the subscript of the attribute,
the lesser the index overhead.
Let I = { a l , ..., a l } be the indexed attributes. Partition the file separately for
each attribute belonging to I . Allocate the file and the index for all the 1 attributes
as in nonclustered indexing (except possibly the first attribute that is allocated as in
distributed indexing). While allocating the index for a particular attribute, the indexes
of the other ( I - 1) attributes are treated as part of the file. The index segment of
each index attribute has to take into account the additional offset introduced by the
presence of the index segment of other attributes. Each data bucket of the file stores
a pointer to the next occurrence of the control index for all attributes in I .
If an attribute has a clustering index, then the access protocol for accessing records
based on that attribute is similar to that of accessing records in distributed indexing.
For nonclustering attributes the access protocol is similar to that of nonclustered
Notice that contrary to disk -based files, the latency for accessing records based
on some attribute is dependent on the presence or absence of the index for other
attributes. Each additional index increases the overall latency while decreasing the
tuning time for the indexed attribute.
I Index segment of attributes a and b I
a1 b l c1
DS(b1) a1 b l c2
a1 b l c3
-~ Index segment of attribute b / -
DS (al)
zikE z l
I Index segment of attribute bl-
IS (b2): b2, 4
b4 23
-.l bR c
- .l
a1 b3 c2
a1 b3 c3
Index segment
segment of
of attributes
attributes a
a and
and b
a2 b l c l
a2 b l c3
Index segment of attribute b l
a2 b2 c2
zz Eiz:
Index segment of attribute b l
a2 b3 c l
a2 b3 c2
a2 b3 c3
a3 b2 c3
Index segment of attribute b
. .
a4 b l c3
I Index segment of attribute b l
::,"f :l
__ _ _
Index segment of attribute b l
b3 c1
a4 b3 c2
a4 b3 c3
index segment of attribute b l
index segment of attributes a and b
Fig. 9.77 Example of multiple attribute indexing.
Consider Figure 9.17, where the records have three attributes: a , 0 , and c. The file
is lexicographically sorted (with u as the most significant attribute, followed by O and
then by c). Let n and b be the attributes over which the file is indexed, i.e., I = { a , O}.
The file is partitioned into data segments for attributes a and b. The data segments
for u are denoted by DS(al), DS(a2), DS(a3), and DS(a4). The data segments for
the attribute bare DS(bL), DS(a2), and DS(a3).
A data segment corresponding to the attribute [email protected]), contains a pointer (following
the last record of the data segment) to the next data segment, that contains records with
the same value for the attribute [email protected]). These pointers are shown for attribute value b2.
Each data segment corresponding to attribute u(b) is followed by an index segment,
which provides a directory to nearest occurrences of data segments for other values
of a(b). Additionally (not shown in the figure), each data bucket contains a pointer
to the next occurrence of the control index for a, and the control index for b. In the
figure, the index segment for attribute b occurs at every index segment for attribute
(L. This is not true in general.
Immediately following the (first) data segment DS(b2) is a pointer to the next
occurrence of DS(b2). This is followed by the index segment IS(b2). Consider the
index segment IS(b2). The first element indicates that if the attribute's value is less
than or equal to h2 (i.e., bl or b2), then the client has to probe the fourth bucket ahead
of the current bucket. The second element indicates that if the requested attribute
value is b3, then the client has to probe the first bucket following the current bucket.
The third element indicates that if records with value of b4 (for attribute b) is being
searched for, then the client has to tune after 23 buckets. Note that even though b4
does not exist in the current meta segment, there is still an index entry for it.
We use the following notations in the analysis:
C,: the coarseness of attribute a,(in buckets).
M,: the scattering factor of the attribute.
Index,: the size of the index tree of attribute 0,.
kL:the number of levels in the index tree corresponding to attribute a,.
the average number of optimum replicated levels in the index tree of attribute a,.
ATndex( 1 ) : the average index overhead (per meta segment) due to attribute a,.
Latency: Each meta segment of attribute a, has (Index, + AIndex(i)) number of
extra buckets due to distributed indexing on the attribute. The total number of extra
buckets E, due to indexing the attribute a, is
The broadcast wait is
= ill7x
+ AIndex(i))
For an attribute a, that is indexed, the probe wait is
~ e v e l [,+I]
+ it~x~evel[r,+l]
Thus the latency for an attribute a,that is indexed is:
For an attribute ai that is not indexed, the probe wait is 0.The broadcast wait and
the latency for such an attribute is
Tuning Time: The tuning time for indexed attribute a, is calculated below. In the
first probe. the client fetches a pointer to the next index segment for the attribute
ai. After getting to the index segment, a number of probes have to be made in that
index to get to the required data segment D S ( K i ) . The number of probes required
for getting to DS(E(,) is (Ici I), where ki is the number of levels in the index tree
for ui. Once the first data segment DS(K,) is encountered, then Ci probes have to
be made to get all the required records. Furthermore. Mi extra probes may have to
be made to get all the required records. This is because the data segments may not
occupy an exact multiple of number of buckets in which case the last bucket might
contain only a few records belonging to this data segment. The tuning time for the
indexed attribute a i is bound by:
+ 1)+ C, + M ,
i.e., 2
+ k, + C, + hf,
For a nonindexed attribute u, the client looses the ability of selective tuning.
In the worst case, the whole length of the meta segment for attribute ul has to be
scanned to get to the next record with the requested value of n 7 . This is because the
last indexed attribute is ul. After this, the number of probes required is (C, M 7 )as
described above.
Thus, the tuning time for records on attribute a, that is not indexed is bound by
Dynamic Organization
Reorganizing broadcast files is substantially cheaper than reorganizing disk-based
files. Indeed, in case of broadcasting, each new broadcast starts from “scratch”
because the previous broadcast disappears. The new broadcast can substantially
differ from the preceding one, both in terms of data contents and with regard to
index. The reorganization cost is limited to the server’s memory reorganization. The
reorganization of a broadcast itself simply amounts to a different downloading order
by the server. Hence. there is minimal need for dynamic data organization methods.
In fact, dynamic indexing methods such as B-trees are generally inappropriate for
broadcasting since in order to ensure the “locality” of changes, they require reservation
of an extra pointer space which would unnecessarily increase the overall broadcast
size and consequently the latency.
The basic indexing scheme as discussed earlier has overhead related to index management. A scheme called Exponential Index [30] used an innovative approach to
reduce index management overhead. It is a parameterized index which can be tuned
to optimize the access latency with the tuning time bounded by a given limit and vice
Displacement in buckets
Indicates the range of buckets preceeding the target bucket.
For example 5-7 buckets before the traget bucket.
Fig. 9.18 Structure of exponential index.
Figure 9.18 illustrates the structure of exponentialindex scheme. Each data block is
associated with an index table. An entry of the index table has two fields displacement
in bucket and MaxKey. The displacement in bucket is a range of buckets where one of
the values of this range identifies the number of buckets one has to traverse to reach
the desired bucket. For example, if the value of the displacement in bucket is 4-7,
then more than 4 and fewer than 7 buckets are needed to be traversed to reach the
desired bucket. An example of a broadcast is given in Figure 9.19.
Fig. 9.19 A simple exponential index.
In this example, stock data for 16 companies is maintained at the server. The
data is composed in the broadcast in an ascending order of these companies’ names.
Each company data block is associated with an index table which has four entries.
The structure and number of entries in the table are the same for all companies. The
index tables for DELL and MSFT are shown in the figure. The entire broadcast has
been arranged in I6 buckets. The range of buckets (B-range) is shown here just for
information. In fact their values can be computed by the position of an entry in the
index table. For example, the i = 3 (3rd entry of DELL index table) entry is for
“SUNW.“ The range of the buckets for i = 3 can be computed as 2”’ to 22 - 1,which
is 4 to 7. The index table of “MSFT” is a replication of the “DELL” table where some
of the entries are different. So in a replication of the index table, the structure does
not change but the contents does change to point to new buckets.
The number of entries in the index table depends upon the size of the broadcast
in buckets. It is important to find a good balance of the size and the number of index
tables because their granularity and number significantly affect tuning and latency
times. The data access from a broadcast under this scheme can be explained with an
example. Suppose a user want to access stock information for the “NOK” company.
The client tunes to the current broadcast and hits “DELL.” He downloads the index
table IT-1 and discovers that the position of “NOK” is after “MOT“ that is after bucket
4 and before “SUNW” that is before before bucket 7. This gives us buckets 5 and 6.
The client goes into doze mode and wakes up when bucket 5 arrives. He tunes and
downloads index table of bucket 4 (IT-2).The first entry of IT-2 indicates the B-range
value for “NOK,” which is 1 - 1. This gives us the displacement of 1 bucket from the
current position of “MSFT.” The client stays active and tunes and download “NOK”
The total tuning time to get the answer of the query is 3 buckets (i.e., bucket 1 and
5 for initial search and bucket 6 for data download). The worst tuning time for this
scheme is Llog,(N - 1) l] buckets where N is the total number of buckets in he
entire broadcast. The worst tuning time for this example is ( N = 16) 5 buckets.
Generalized Exponential Index
In the above example the index base, which is defined as the base for defining the size
of index table, was 2. To generalize the scheme, it can be replaced by any number, i.e.,
r 2 1, where r is the index base. With this index base the B-range can be expressed
j= I
The indexing overhead may be reduced by reducing the number of index table.
One way to do this is to group an I number of buckets into one bucket (i.e., data
chunk). This will reduce the number of index tables and its size (number of entries);
as a result, more data items can be accommodated in the same-size broadcast. One
side effect of this arrangement is that, on the average,
number of buckets will be
searched to find the desired data. A solution to this search problem, presented in Ref.
[30],is to construct a plain index for all buckets in the group. In the plain index an
index entry describes the maximum key value for each bucket, and the intra-chunk
A Broadcast
Fig. 9.20 A generalized exponential index with r = 2 and I = 2.
tuning time is either one (for the first bucket in the chunk) or two buckets (for the
remaining buckets). This is achieved by defining a global index for other data chunks
and defining a local index for ( I - I) buckets within the local chunk. Figure 9.20
illustrates the layout of generalized exponential index with T = 2 and I = 2.
The data search procedure is very similar to the earlier example. Suppose a client
wants the \tack information of “NOK.” He tunes and download the index table (TT- 1 )
stored in “DELL” data block. The desired data information is not in the local index of
17‘ - 1, so the search is extended to the general index portion where “NOK” falls in a
key range specified by the second entry (2-3 SUNW). The client goes into doze mode
and wakes up when the firs bucket of chunk 3 (bucket 5) appears in the broadcast. In
the index table of bucket 5 , “NOK” falls in the key range specified by the first local
index entry and the client accesses the next bucket (bucket 6). The total tuning time
is 3 buckets.
The performance of exponential index can be tuned with T and I parameters.
Parameter T controls the number of index entries and I the chunk size. Indexing
overhead increases with decreasing value of r and tuning time is reduced by increasing
the value of I . Detailed information about the performance can be found in Ref. [30].
Basic indexing schemes discussed so far are unable to handle location-dependent information such as information about Kansas City weather, O’Hare airport congestion,
traffic congestion at a segment of 1-435, and so on. In order to get location-specific
information from the broadcast, the index must contain necessary pointer to correct
One of the best ways to accomplish this is through the dissemination of highly personalized Location-Based Services (LBS) which allows users to access personalized
location-dependent data. For example, a traveler using his mobile device to search for
a vegetarian restaurant in some city. The LBS application would interact with other
location technology components or use the mobile user’s input to determine the user’s
location and download the information about the restaurants in proximity to the user
by tuning into the wireless channel which is broadcasting Location-Dependent Data
(LDD). The following example illustrates the type of indexing required for LDD.
Suppose a user issues a query “Heaven Coffee in Plaza please” to access information about the Plaza branch of Heaven Coffee in Kansas City. In the case
of location independent set up the system will list all Heaven coffee shops in
Kansas City area. It is obvious that such responses will increase access latency and are not desirable. These can be managed efficiently if the server has
location-dependent data-that is, a mapping between a Heaven Coffee shop and
its physical location.
The tree-based and exponential index schemes discussed earlier are not satisfactory
and effective in broadcasting location-dependent data. In addition to providing low
latency, they lack properties which are used to address LDD issues. In this section a
new indexing scheme called location index is discused for broadcasting LDD.
Location Index Scheme
The example identifies the need for a mapping function to access location dependent
data from the broadcast. This will be especially important for pull based queries for
which the reply could be composed for different parts of the world. The mapping
function is necessary to construct the broadcast schedule [ 121.
Information Content (IC)
Location Hierarchy (LH)
Fig, 9.21 Information contents and location hierarchy sets.
Mapping Function
A Global Property Set (GPS) [ 121, Information Content (IC) set, and Locution Hierarchy (LH)are required to construct location index. These sets are defined as follows:
Global Property Set (GPS): It is a set of objects or entities which are required
to answer a query. For example, traffic, stock quote, weather, airline, state, country,
city, etc., are the members of GPS. Thus, GPS = {q,
e 2 , . . . , en}; where e,’s are real
world entities.
lnformation Content (/C)
set: It is a set of stand-alone entities. Thus, IC =
. . . , in},where i i ’ s are real-world entities such as traffic, stock quote, theater, etc. An IC does not contain any geographical object such as city, state, etc., and
the relationship IC c GPS is always true.
{ i l ,i 2 ,
Location Hierarchy (LH): It is a tree of locations. The leaf nodes are the smallest
location in the hierarchy. For example: Country --7’ state city is a location hierarchy.
The relationship L H c GPS is always true.
A mapping function is required for correct association between a member of IC and
LH. Figure 9.21 illustrates IC set and LH samples. The mapping scheme must be able
to identify and select an IC member and an LH node for (a) correct association, (b)
granularity match, (c) and termination condition. For example, Weather E ZC could
be associated with a country or a State or a City or a Town of LH. The granularity
match between the Weather and an LH node depends on the user requirements. With a
coarse granularity, weather information is associated with a Country to get country’s
weather and with town in a finer granularity. If a town is the finest granularity, then it
defines the terminal condition for association between IC and LH for weather. This
means that a user cannot get weather information about subdivision of a town. In
reality, weather of a subdivision does not make any sense.
A simple heuristic mapping approach scheme based on user requirement Is developed here. Let IC = { m ,, ~
, m,k},where mi represent its element and let LH =
{ n l , 722,. . . , 7 ~ l } where
n, represents LH’s member. Define G
C G P S and for L H ( G P S L H )C G P S . G P S I =~ { P I ,P2
P2, Ps, . . ., Pn are properties of its members and GPSLH
, Qm are properties of its members. The properties of a particular
member of 1C are a subset of G P S I G . It is generally true that the (property set
(,mi E 1C) U property set (mj E 1C)) # 8;
however, there may be cases where
the intersection is not null. For example, stock E 1C and movie E IC rating do
not have any property in common. It is assumed that any two or more members
of 1C have at least one common geographical property (i.e., location). For example, stock of a company is related to a country, weather is related to a city or state,
etc. The property subset of m,i t 1C is defined as PSmiVmi t 1C and PSm.i
= { P I ,4,.
. . , PT} where r 5 ri. VPT{Pr E PSm,i + P, E G P S I ~which
implies that Y i , PSrni C G P S l c . The geographical properties of this set are indicative of whether mi € 1C can be mapped to only a single granularity level (i.e.,
a single location) or a multiple granularity levels (i.e., more than one nodes in the
hierarchy) in L H . How many and which granularity levels should an rrii map to
will depend upon the level at which the service provider wants to provide information about the m i in question. Similarly, a property subset of LH members is
defined as PSn.,Vnj E LH which can be written as PSn,j = {Q1,Q2.. . . ,Q,$}
where s 5 na. In addition, VQs { Q s E PSnj + Q s E G P S L H } which
that V j , PSrij C G P S L H .
The process of mapping from IC to LH is then identifying for some m, E IC
one or more ny E L H such that PSm, n PSn, # 8.This means that m, maps
to multiple granularity if it maps to ny and all its children and it maps to a single
granularity if maps only to ny. In reality, any time new members can join and old
member can leave IC or LH. The deletion of members from the IC space is simple, but
addition of members to the IC space is more restrictive. If a new member is to be added
to the IC space, then first a property set for the new member has to be defined. Thus,
PSmnew-m= { P I ,P2, . . . , Pt} which is added to the IC only if the condition: YP,,]
E PSpneW-, + P, E GPSrc} is satisfied. This scheme has an additional
benefit of allowing the information service providers to have a control over what kind
of information they wish to provide to the users. The following example illustrates
the mapping concept.
{ Trafiic, Stock, Restaurant, Weathel;
Important history dates, Road conditions)
{Country, State, City, Zip-code, Major-roads}
(Surjuce-mobility,Roads, High, Low,
GPSic =
Italian-jbod, StuteNume,
Temp, CityNurne, Seat-availability, Zip,
Trufic-jams, Stock-price, CountryName,
Mujo rRoadNarne, Wars, Discoveries, World)
(Country, Countrysize, StuteName, CityName,
Zip, MajorRoadName}
CountryName, High, Low}
P s ( I C S t o c k )=
Roads, High, Low,
Trafic-jams, CityNurne)
d a t e s zn h i s t o r y ) = {World, wars, Di.Ycoverie.7)
{Precipitation,StateName, CityNurne}
PS(IcRoud corrdilions) =
{ Italian-food, Zip code}
PS(1Crzcstaurant) =
{ StuteNume, CityNarne, Precipitation,
{ CountryName, CountrySize}
(StateName, State size}
{ CityName, City size}
PWffZipcode) =
{ ZipCodeNum}
pk!(LHA4ujorr o a d s ) =
{ MujorRoudName}
IC =
In this example, only P . s ( l C , ~ ~n~P~ k S
) C#~
~ ~P s~( l C~~ ~ ~ , k )
indicates that Stock can map to only a single location Country. When Trufic of I C
is considered only P s ( 1 C ~ ~n~PS,,L,
f f ~#
~ @.
) As P S ( l C ~ , , f f i indicates
TrafJic can map to only to City and none of its children. Unlike Stock, mapping of
Trafic with Major roads, which is a child of City is meaningful. However, service
providers have right to control the granularity levels at which they want to provide
information about a member of I C space.
PS(ICRoad condztzons) n PSState # @ and PS(ICRoad c o n d z t z o n s ) n I’SCzty #
G?. SoRoadconditionscanmaptotheStateaswell astothecity. As PS(ICtload condztzo7,s)
indicates, Road conditions can map to multiple granularity levels -to Zip Code and
Major roads, which are the children of the State and City. Similarly, Restaurant maps
only to Zip code, and Weather maps to the State, City, and their children Major Roads
and Zip Code.
Push-Based Broadcast Schedule
The following algorithm generates a push-based broadcast schedule. It takes L H and
I C as inputs and generates a series of clustered LDD.
BroadcastSchedule ( I C ? ,L D )
Bcast = Null;
for all I C content do
Check ( I C 7 ) ;
L D , = map (IC,, L D ) ;
Bcast = Bcast + L D , + data,;
index = index + IC,;
Map(IC,, L D ) {Comment-Maps the IC, members with L D }
found =false;
jar all properties in IC,
Ij(property7 == location)
If(1ocation = = Termination-Condition)
Termination-Condition == property,;
While (notjound) { Comment-check Termination-Condition in L D )
For all locations in L D
lj’(Termination-Condition= = location,)
Termination = Termination-Condition;
LD, = Calculatepath (Termination);
found =true;
If (notfound)
Generate (Termination-Condition)
} End while
} End Map
Generate(Termination-Condition){Comment- Generate T C , add it to L D }
for all properties in IC,
If (property, == highestlocation)
(parentJocation = = property,);
{ Comment-Locate parent-location from GPS to get area code,
zip code, and longitude and latitude. Calculate only Zipcode, Z }
for all Z’s in parent-location do
$(zipcode == Z ) then
NewLocation = new [node];
Newdocation = Z + child; {add location under Z}
Calculatepath (Termination) in L D
for all properties in I C ,
If (proper-9, = = highestlocation)
(parent-location == property,);
Path = DFS (parentlocution);(Comment - depthjrst search Return path.}
Location-Based index Scheme - LBlS
LBIS is designed to conform to the LDD broadcast. As discussed earlier, the containment property of LDD significantly limits the search of the required data to a
particular portion of broadcast. Thus, the scheme provides bounded tuning time. The
scheme contains separate data buckets and index buckets. The index buckets are of
two types: (a) Major index and (b) Minor index.
Major index: It provides information about the types of data broadcasted. For
example, if entertainment, Weather, Traffic, etc., are broadcasted, then the major
index points to this information andlor their subtypes. The number of main subtypes
varies from one information to another. This strictly limits number of accesses to
a Major index. The Major index never points to the original data. It points to the
sub-indexes called the Minor index.
Minor indexes: These are indexes which point to data. They are also called Location Pointers as they points to the data which are associated with a location. Thus, the
data search includes accessing a major index and some minor indexes. The number
of minor index varies, depending on the type of information. LBIS takes into account
the hierarchical nature of the LDD and of the containment property, and it requires
our broadcast schedule to be clustered based on data type and location. The structure
of the location hierarchy requires the use of different types of index at different levels.
The structure and positions of index strictly depend on the location hierarchy as described earlier in the mapping scheme. The scheme is illustrated with the following
Fig. 9.22 Broadcast location tree.
Two information types are used in the broadcast: Entertainment and Weather
Figure 9.22 illustrates the location tree for Entertainment and Weather. Ai
represents Areas of City, and Ri represents roads in certain area. The leaves
of Weather represent four cities. The index structure along with the broadcast is given in Figure 9.23. The major index contains Entertainment (E),
Entertainment-Movie(EM), Entertainment-Restaurant (ER), and Weather (W).
The tuple (S, L) represents the starting position (S) of the data item, and L represents the range of the item in terms of number of data buckets. The minor index
contains the variables A and R and a pointer Next. Road R represents the first
node of area A. The minor index is used to point to actual data buckets present
at the lowest levels of the hierarchy. Index information is not incorporated
in the data buckets. Index buckets are separate and contain only the control
information. The number of major index buckets is rn = N(IC), where I C =
Major index
Minor index
Fig. 9.23 Broadcast composition with LBIS.
{ i c l i c z 1. . . icn} and i c i represent information type and N represents the cardinality of I c . In this example, Ic = { i c M O v i e ,*iCWeatherlicRestaurant}and
N ( 1 C )= 3. Hence, the number of major index buckets is 3.
Mechanism to resolve the query is present in the Java-based coordinator
in MU. For example, if a query Q is presented as Q (Entertainment, Movie,
Road-1), then the resultant search will be for the EM information in the major
index, i.e., Q + E M . Information request from aclient is processed as follows.
Let an MU issue a query (Restaurant information on Road 7 please). This is
resolved by the coordinator as Q + ER. This means that one has to search for
ER unit of index in the major index. Suppose that the MU logs into the channel
at R2. The first index it receives is a minor index after R2. In this index, value
of Next variable = 4, which means that the next major index is present after
bucket 4 and MU may go into doze mode. It becomes active after bucket 4
and receives the major index. It searches for ER information which is the first
entry in this index. It is now certain that the MU will get the position of the
data bucket in the adjoining minor index. The second unit in the minor index
depicts the position of the required data R7. It indicates that the data bucket
is the first bucket in Area 4. The MU goes into doze mode again and becomes
active after bucket 6. It gets the required data in the next bucket.
The information access procedure is presented below:
Scan broadcast for the next index bucket,
found = ,false;
While not found do
R: if it is a Major Index bucket then
Find the Type and Tuple (S, L)
i f S is greater than I then
go in doze mode for S seconds
end if
Wake up at the Sth bucket and observe the Minor Index
end if
f i t is a Minor Index bucket then
if T Y P e R e q u e s t e d # Type found and (AjRjRequest # (AjR)f o u n d then
Go in doze mode till NEXT and repeat from R
end if
,find entry in Minor Index which points to data;
Compute time of arrival T of data bucket;
Go into doze mode until time T;
Wake up at T and access data;
found = true
end else
end if
end While
In a push-based system a server periodically broadcasts a schedule which is computed
off-line using user access history. This approach is also referred to as static broadcast
which does not take into account the current data access pattern. The broadcast server
composes broadcast based on popularity pattern and pushes the entire broadcast on
to the wireless channel for users. Its performance is significantly affected when
user access pattern deviates from the one which was used to construct the broadcast
schedule. In pull-based systems, which are commonly referred to as on-demand
broadcast system, clients explicitly request for data items from the server. The server
compiles the request and, based on number of pending requests for the data items,
broadcasts the data. In earlier sections the push-based broadcast as discussed where
the broadcast was supported by different kind of indexing. It is obvious that a pushbased approach cannot handle a specific request from a user satisfactorily, and it gets
worse if multiple users have orthogonal requests. This situation commonly occurs in
transactional requests where a user-initiated transaction through a mobile unit may
ask for a number of different data items-for example, a travel planner transaction
which makes reservation for car, hotel, plane, etc., and make the payment through
direct debit and credit. If the mobile unit has to process this transaction, then it will
need these data items from the server. A simpler way for the server would be to
push these data items on the broadcast channel rather than sending it through a back
channel directly to the mobile unit. This scheme may work for a handful of users
requesting data items infrequently and would break down if the number of users or
requests increases.
A better way to handle such requests is through data pull using a broadcast. This
section deals with pull-based approach for getting desired data from the broadcast and
presents a data scheduling scheme to handle on-demand multi-item requests. Earlier
works 13, 4, 5 , 9, 10, 15, 16, 24, 25, 27, 29, 311 on data scheduling have considered
only single-item requests; but in reality, users invariably attempt to download multiple
data items to process their requests. For example, database clients often access
multiple data items to complete a read transaction. Similarly, web users access HTML
document along with all its embedded objects. In addition to multi-item requests,
transactional requests have to handle issues such as consistency, application recovery,
There are a few algorithms [3, 9, 29, 311 for pull-based and some algorithms
[3,25,27] for push-based broadcast. In these approaches the server delivers data using
a periodic broadcast program, which is based on the estimation of access probability
of each data item. Its usefulness is limited to a static environment where access
probabilities do not change often. In Ref. [4] broadcast scheduling algorithms for a
hybrid push-pull environment are proposed where the server periodically broadcasts
using a broadcast program. A part of channel bandwidth is reserved for data items
which are to be pulled by the client. The client issues a request to server only after it
has waited for a predefined duration for data to become available in aperiodic pushbased broadcast. Pull-based scheduling algorithms FCFS (First Come first Serve),
MRF (Most Request First), MRFL (Most Request First Lowest), and LWF (Longest
Wait First) were studied in Refs. [9,29]. In FCFS, pages are broadcasted in the order
they are requested. In MRF, a page with the maximum pending request is broadcasted.
MRFL is similar to MRF, but it breaks ties in the favor of a page with lowest request
access probability. In LWF the waiting time, which is the sum of waiting time of all
pending requests for the page, is calculated for all the pages. The page with the longest
waiting time is broadcasted. It is shown that FCFS performspoorly compared to other
algorithms in broadcast environment when the access pattern is non-uniform [9,29].
In Ref. [3I] authors studied on-demand systems where requests were associated with
deadlines. They reported that on-demand broadcast with EDF (Earliest deadline First)
policy performs better. In Ref. [3] authors proposed a scheduling algorithm, referred
to as R x W where R stands for number of pending requests and W stands for waiting
time of the arrival of the first request, which combines FCFS and MRF heuristics.
The algorithm computes the product of R and W and selects the data item with the
maximum R x W value for the next broadcasting. In Ref. [16] the author proposed
a scheduling scheme for a push-based system with multi-item requests. The scheme
uses the access pattern dependencies of the request and the probability of their access
and presents a heuristic that exploits the page access dependencies to compute a static
off-line broadcast schedule.
The schedule presented here considers multi -item and transactional requests, which
raise new issues.
Figure 9.24 shows the architecture of a typical on-demand broadcast system. There
is a single server, which supports a large client population. A client sends queries
Fig. 9.24 On-demand broadcast setup.
or update transactions to the server through uplink channel. The server broadcasts
relevant information in response to queries over the satellite downlink from where
the user retrieves the result. Update transactions are executed at the server, and the
new values are broadcasted if there are requests for them. Similar to previous works
on broadcast scheduling, it is assumed that all data items are locally available on
the server and they are of equal size and hence they have equal service time. The
broadcast duration of a data item is referred to as broadcast tick.
One of the limitations of current broadcast scheduling schemes is that they make
broadcast decision at the data item level; that is, it composes a broadcast by considering only the requested set of data items. It does not consider the set of transactions
that requested them. The following example illustrates this data access pattern. Table
9.2 list a number of transactions ( t Zand
) the corresponding data items (dL)they need.
For example, transaction tl needs data items d l , da, and d7. The Total records the
total number of transactions that require d,. For example, data item dl is required by
transactions t l , t 3 , and t 4 . The server broadcasts data items requested by the clients
using a scheduling algorithm.
Table 9.2 Transactions and data items they need
Scheduling decision based on data item level causes a consistency problem and
also increases data access time. This is illustrated by the following example. The
example uses the MRF (Most Request First) scheme because FCFS and R x W [3]
schemes make broadcast decision at the data item level. Under MRF, data items d l ,
dz, dy, dq, d g , ds, and d7 will be scheduled starting from d l in one broadcast tick, dz
will be in the next broadcast tick, and so on.
Consider t l , which needs d l , da, and d7. Transaction t l gets d l and (12 in the first
two broadcast ticks and has to wait for d7 which arrives in the 7th broadcast tick.
This is because the scheduling algorithm makes a decision at the data item level. It
has two important consequences: (a) For a single data item the transaction tl had to
wait until the 7th broadcast tick, and (b) In between the 2nd and 7th broadcast ticks,
if there are updates to either d l or dz, then transaction t l gets stale copies of d l and
dz and the transaction has to be aborted. Another important issues is that the clients
have to continuously monitor the broadcast to download their requested data items.
There is no provision for broadcasting data index because (a) the scheduling decision
is made at every broadcast tick, consequently, it cannot predict the data items to be
broadcasted in the next broadcast ticks and (b) the notion of periodicity and broadcast
cycle do not exist.
On-Demand Scheduling with Index
The broadcast scheduling scheme, similar to the push scheme discussed earlier, uses
index to tuning time. A number of parameters are defined before the scheme is
Transaction Wait Time
Transaction S e e k T q
T,'s request arrives
Transaction Span
First data item of T, is broadcasted
First data item of T, is broadcasted
fig- 9.25 Transaction response time.
Response Time: Response time includes (a) transaction wait time, (b) transaction
seek time and (c) transaction span. Figure 9.25 illustrates the relationship among
these parameters.
Transaction Seek Time: It is the time that elapses between sending a request to
the server and broadcasting the first data item of the transaction, that is, ( b - a).
Transaction Span: It is the time between the first and the last data items of the
transaction are broadcasted (b-c). Consistency issue is related to transaction span, As
transaction span increases, the chances of transaction having an inconsistent view of
the database increases. Hence the scheduling algorithm aims to reduce the transaction
Transaction Wait Timer It is the time between the data request dispatch and the
broadcast of data items. Transaction wait time = Transaction Seek Time + Transaction
Span Tuning Time.
Tuning Time: It is the total time the client listens to the broadcast channel.
The following parameters are used to compute the priority of transactional request
called temperature of a transaction.
R = total number of data items in the database D
Database D = { d l , d Z l . . . , d n }
R d ? . = number of requests for data item d,
Data items accesses by transaction t , = TD,, where T D , C D
num, = number of data items accessed by transaction, riurn, = 1 T D i
To,lg= average transaction size.
Temperatureof a Transaction- Ternp,: It gives the measure of the number of hot
data items (frequently accessed data items) a transaction accesses. T e m p i is defined
as an average number of requests per data item of the transaction. Thus, Tem,pi =
C Rdilnumi f o r all di E TDi. For example, the temperatureoftransaction 21 with
TD1 = { d l , d2, d 7 } , Rdl = 3, Rd2 = 3, R d 3 = 1, and numi = 3 is = (3+3+1)/3 = 2.33
(Table 9.2).
In this algorithm, scheduling decisions are made at periodic intervals, which is
referred to as broadcast cycle. In push-based system the content and organization
of a broadcast cycle, referred to as schedule, is the same in every cycle and the
same schedule is repeatedly broadcasted. However, unlike a push-based system,
in this scheme the content and organization of each broadcast cycle may vary, depending on the current workload at the server. Thus, the notion of broadcast cycle
is used to achieve two objectives: (a) To introduce periodicity into the broadcast
for indexing its contents and (b) To identify a suitable interval after which updates
at the server can be applied to the database. Each transaction requires a varying
number of data items; as a result, it cannot define the exact number of data items
in a broadcast cycle as in the case of single-item requests. Broadcast cycle is an
interval of broadcast ticks whose length varies between K and ( K Taus)broadcast ticks. In the beginning of the broadcast cycle the schedule for the current cycle
is formed based on the current request volume at the server. The server calculates
temperature for all transactions that were requested by the client population. The
transactions are sorted based on their (Tempi x Wi) values. First N transactions
are selected from the sorted list such that their total data item requirement does not
exceed ( K Tovg).
The arrangement of data items within the broadcast affects the transaction span
and tuning time. The data items are arranged in a broadcast cycle such that transactions whose data sets T D overlap
are broadcasted together. This helps in reducing
the transaction span and tuning time. The data are broadcasted in the order determined along with the index. The index contains the content and order of the data
in the broadcast cycle. Update transactions that are received during a broadcast
cycle are queued. They are executed at the end of the broadcast cycle and serialized in the order of their arrival. As a result, the state of database changes only
at the end of the broadcast cycle. Data broadcasted within a broadcast cycle will
always belong to the same database state and hence is consistent. If a client downloads data from two different broadcast cycles then it may get inconsistent view
of the database. The client side portion of this algorithm ensures that a client can
download an entire data set TD,of the transaction from a single broadcast cycle
by using the index in the broadcast. The algorithm at the client ensures a consistent view for the client transactions and avoids aborts. The client, after sending
the request to the server, monitors the broadcast for the next index and downloads
it. If the client does not have its required data in the current broadcast cycle, then
it can sleep until the end of the current cycle and tunes for the index in the next
Server Side Protocol
The term Request identifies the set of transactions requested by clients. Bset identifies
the set of data items selected for broadcasting in the current cycle, and Tlist identifies
the set of transactions that are used to fill the current Bset.
Calculating Temperature of transactions: In the beginning of the broadcast
the schedule for the cycle is formed based on the current request volume at
the server. The server calculates the temperature of all the transactions in the
Request set.
Sorting the Request list: Transactions in the Request set are sorted in descending order at the beginning of every broadcast cycle using ( T e m p Lx
values where W, is the wait time of transaction t, since its arrival at the server.
Selection for transactions for current broadcast cycle: Transactions are selected sequentially from the top of Request set until the total data requirement
of these transactions exceeds the length K of the broadcast cycle. The contents
of set Tlist and Bset are identified here, and the selected transactions are added
to the Tlist set and the data items of these transactions are added to the Bset.
a. Let Bset = 8,
Tlist = 8
b. While (I Bset I< K )
i. Select next transaction t , from the sorted Request set
Tlist = Tlist U t ,
Request = Request - t ,
ii. Bset = Bset U ( T D , - (Bset nTD,)
\ Bset 1 will be in the range: K 51 Bsel ( K TaqIY)
)< +
4. Arrangement of data items with in the broadcast cycle: The arrangement of
dataitems within the broadcast cycle affects the transaction span and transaction
waiting time. Initially the transaction with the highest value of (Ternpi x W,)
is selected. Its data items are added to the Broadcast set, then the transaction
ti E Tlist is selected such that ti has maximum overlap with the Broadcast set
compared to other transaction t j E Tlist. OverlapilRerni is used to measuring
the overlap of the transaction, where Overlapi is the overlap of the transaction
with the broadcast set and Rerni is the number of transactions not selected
in the Broadcast set so far. The transaction t, with the maximum value of
Overlupi/Remi is selected. If there is a tie among the transactions, then
transaction ti with higher value of (Tesrnpi x Wi)is selected. The data items
are broadcasted in the same order as they appear in Broadcast set.
a. Broadcast = 8
b. Select transaction t, with the highest T e m p i x Wi value
c. Add the data items of the selected transaction that are not yet added to the
Broadcast set and remove the transaction from Tlist
i. Broadcast = Broadcast U (TDi - (Broadcast n T D i )
ii. Tlist = Tlist - t ,
iii. If (Tlist = 8)
then exit
d. Calculate for every transaction ti E Tlist
i. The overlap of the transaction ti with the Broadcast set as: o w r l a p i =
Broadcust n T D i
ii. Number of Data items remaining to be broadcasted denoted remi
rern,i = T D i - overhpi
e. Select transaction ti with the highest value of (overlupi/rem,).If there
is a tie in the values (overlapi/rerni) among transactions, then from these
transactions select the transaction that has highest the Tempi x Wi value
f. If I Broadcast
K , then go to step c
5. Indexing: Index is a directory of the list of data items, which are to be broadcasted in the broadcast cycle. ( 1 , m ) indexing scheme [ 171 is used to create
an index for this algorithm. In this method an entire index is broadcasted at
the beginning of every broadcast cycle and then after every ( K / m )broadcast
slots, where K is the length of the current broadcast cycle. A major index is at
the beginning of every broadcast cycle and a minor index is broadcasted inside
the broadcast cycle after every (K/nx)broadcast slots. All indexes contain a
pointer to the location of the next major index. The minor index contains the
list of data items that are not yet broadcasted in the current broadcast cycle. In
the push-based system there is no concept of minor index. All indexes in the
push-based system are of the same size and contain a list of next K element to
be broadcasted. In this algorithm the ith minor index within the cycle contains
the list of ( K - i x (Klrn))data items yet to be broadcasted. The major index
and all minor indexes that are broadcasted are stored at the server until the end
of the current broadcast cycle. The Minor indexes are also used for filtering
out transactions that were not selected in Tlist but were satisfied in the current
broadcast cycle.
6. Broadcast data: Data are broadcasted in the order determined in the broadcast
set in the indexing step above. A major index is broadcasted followed by the
data. Thereafter, a minor index is broadcasted after every ( K - i x ( K / m ) )
broadcast tick.
Filtering Transactions: At the end of the current broadcast cycle, transactions
are removed from the Reyuest set which were not selected in Tlist during formation of contents of current broadcast cycle but still are satisfied completely
in the current cycle. Transactions that are filtered out belong to (a) transactions
that arrive before the broadcast of the current cycle and (b) transactions that
arrive after the broadcast of the current cycle has began. A check is made to see
if all the data required by the transaction are present in the Bset of the cycle to
filter the transactions of the first type. If for transaction t i , T D ? C Bset, then
ti is removed from Request set. To filter out transactions that arrived during
the current broadcast cycle, the first Minor Index that was broadcasted after the
transaction had arrived is used. If the minor index contains all the data required
by the transaction ti, then ti is removed from the Request set. If no minor
index was broadcasted after the transaction arrived, then the t i is retained in
the Request set.
=broadcast cycle start time and Ti = transaction ti arrival time.
For all the transactions which arrived by the end of the current broadcast cycle
If (T, < Tbegin),then
If (TDi n Bset = T D i ) , then Request = Request - ti
Else CommentTransaction arrived after the broadcast cycle began, i.e., Ti > Tbfgin.
i. Select the next minor index (MI) that was broadcasted after time T,.
ii. If (TDi n M I = T D i ) then Requmt = Request - ti.
Client Side Protocol
The client sends a request for transaction f , with data set T D , to the server; after
sending the request, it tunes the broadcast channel for downloading the index. There
are two possible cases: (a) The index could be a major index or (b) it could be a minor
index. The client checks if data required by the transaction are present in the current
index; if it is, then it tunes in the current cycle to download them. If it was the major
index, then the client sleeps for the entire current broadcast cycle and tunes in for the
next major index in the next broadcast cycle. If the index was a minor index, then it
sleeps for the remaining part of the current cycle and tunes in to download the major
index from the next broadcast cycle.
Case 1: Transaction arrived in the current broadcast cycle.
a. Tune to download the next Minor index.
b. If ( T D ,n MinorIndex = T D i ) ,then tune and download required data.
Else tune in for the Next Major Index and sleep.
Case 2: Transaction arrived in the previous broadcast cycle and no minor index
was broadcasted.
If ( T D , n Major Index = TDi), then tune and download required data.
Else tune in for the Next Major Index and sleep.
At present there is no data dissemination system which supports pull, push, and
hybrid schemes. In this section a hybrid reference data dissemination system called
DAYS (DAta in Your Space) is introduced. DAYS (a) supports legacy systems (both
centralized and distributed), (b) facilitates the use of mobile transactions, (c) allows
the execution of location-dependent applications (retrieval and update), and (d) allows
users to retrieve and update data from broadcast.
Figure 9.26 shows the architecture of DAYS. It consists of a Broadcast Scheduler,
Data server, and a Local broadcast space. The broadcast scheduler schedules push
and on-demand data. The data server contains series of data to be broadcasted which
are stored in pages along with some control information. The control information in
each page are of three types: (a) Broadcast type - B T , (b) Page type - P T , and
(c) Time - T . BT is a one-bit field with values 0 or 1. BT = 0 for popular and is
intended to be pushed into the broadcast channel, and it is equal to I for the remaining
pages which are to be pulled. The scheduler decides which page to push, depending
on the popularity pattern generated by the DAYS coordinator. PT can be described
as PT(x,y),where x bits denote the page type and y bits denote the sequence number
of the page type. As the size of the information generated can always increase or
decrease, the value of y for a particular x varies continuously. T bits are used to
timestamp the pages to identify their old and new versions.
The local broadcast space consists of a broadcast tower for broadcasting data,
mobile units, and the data staging machines called the Surrogates. Surrogates communicate with mobile units with the help of 802.1 1 wireless LANS. They are also
connected to the File Server present in the broadcast tower with high-speed wired
Fig. 9.26 DAYS - DAta in Your Space.
network. The file server periodically caches the broadcast pages. The advantages of
surrogate are manifold. Recent pushed data are cached in the surrogates so that the
user may retrieve it if he misses them in a broadcast. This arrangement provides the
DAYS coordinator useful information about the access patterns of the user which are
used by the coordinator to prepare a popular push broadcast schedule. Some types
of requests, such as a specific restaurant or hotel or initiating a financial transaction
for buying a coffee from a shop, are user-specific. Some of them require update
transactions which are not feasible in the push based broadcast systems due to several reasons. First, the transactions may involve highly personal information such as
crediddebit card number, which cannot be included into the broadcast. It requires
a direct exchange of data between the mobile user and the server. Second, it is not
realistic to put the response of user-specific requests in the push-based channel as
it may involve significant time lag before the result may reach the user. Also, the
user may have to tune the channel continuously for his required data. This is not
acceptable for energy-constrained mobile units. One solution to this problem is the
use of a direct uplink and downlink channel between the mobile user and the data
server. Present data rates in the wireless channels do not allow these types of services. It is generally accepted that 4G networks will provide more than just wireless
voice telecommunications. In fact, the main thrust of 4G technologies is to provide
high-speed, high-bandwidth, and packetized data communications. It is expected
that in 4G even voice traffic will be delivered to the handset in packets (as opposed
to delivery via dedicated circuit switching).
DAYS has a provision to manage global requests with the use of a separate global
downlink channel which delivers to the distant destination through a combination of
wireless channels and LEO satellites 11 11. In today’s world, user demands these types
of value added services. With the introduction of 4G technologies in the near future,
the next-generation wireless technologies will not only provide voice communication
but will also possess Internet-like capabilities for doing update transactions.
Data Staging with Surrogates
Staging data in a surrogate allows users to extend their limited caching capacity. This
is done by borrowing storage space from the surrogate and by joint operation of the
client proxy of the mobile user, the file server in the base station (broadcast tower),
and the surrogate where data is to be staged. The surrogate is connected to the file
server with a high-speed wired network. It is only a single wireless hop away from the
mobile unit and connected by wireless technologies such as 802.1 1. The client proxy
continuously monitors the data access operation of the mobile user. It maintains a log
file into which it stores the three types of control information of each page: B T , P T ,
and T . The control information it stores is for the broadcast and pages which are
pulled by the user. Thus, it is able to store the information of the user access pattern
without using much cache area. Since it is working internally and does not need to log
on to the wirelesq channel continuously, the power consumption of the mobile unit
does not increase. Based on the information stored in the log file, the proxy generates
a periodic routine which contains the information about what the mobile user is most
likely to access at any time. The routine contains the control information about the
pushed data which is requested and the information about a particular pulled data
which has been frequently accessed by the user. The proxy continuously maintains
and upgrades this routine.
w-File server
Period routine
Fig. 9.27 Data staging in DAYS.
Figure 9.27 shows the data staging architecture. It consists of a surrogate, which
is connected to the mobile user by wireless technologies such as 802.11 and to the
file server with a high speed wired network. The client proxy present in the mobile
user has a periodic routine which contain information about the data the user is most
likely to access at any point of time. Based on the amount of storage available, the
surrogate allows the user to use a certain amount of space for staging data. The
user sends the periodic routine to the surrogate. The time of dispatch of the periodic
routine is arbitrary. It may send it periodically or at the time the user requests a data.
Since the public data is staged in the machine, we believe that proper handling of data
storage in a surrogate can significantly increase the efficiency of data access, and thus
the overall latency time can be reduced. Figure 9.28 shows accesses of data from the
surrogates by a mobile user. The overall aim of data staging is to allow the user to
access data at a minimum latency. For this, we calculate a time bound, T b o u n d , for
the user to access a data.
Let time required for a broadcast = n minutes. Thus, total number of broadcasts
in a day is 24 x 601n. Let size of the data pages = M kbytes. The channel bandwidth
for broadcast is B kbps. So, the number of pages broadcast per second = B / M pages.
Let approximate number of pages in a broadcast be N ( N may vary, but it is fixed for
this calculation). Total time taken for a broadcast is N/(B/M) = ( ( N x M ) / B ) . Thus,
the average wait for any page in the broadcast is ( ( N x M)l(2 x B ) ) . Let the size
of an index page be I kbytes where I << M . There is a time bound for accessing
the index which is interleaved in the broadcast so that the user does not have to wait
for the entire broadcast to access the index. Let the time bound for getting the index
be Ttndcz= 5 , where n: << ( N x M ) I B is total time for each broadcast. Thus, on
an average, the user has to wait for Tindez/2 units of time to receive the index. So,
the index should be broadcasted after every (B/M) x:l; number of pages by the base
station. The time required for accessing data from the surrogate is as follows:
Round Trip Time (RTT) from the user to the surrogate
Search Time (ST) required by the surrogate to check if data is present
File Server Access Time (FSAT) time needed by the surrogate to access data
from the file server if data is not present in the surrogate
The response time is T, e s p = RTT + ST + FSAT time units if data are not present
in the surrogate; otherwise it i\ Tres?,
= R7T + ST time units. Let p be the probability
that data are found in the surrogate. The mobile unit contacts the file server with
probability (1- p ) when data are not found. The time bound for a user when contacting
surrogate is Tbound = p x RTT ST (1 - p)RTT ST FSAT or TbolLnd
RTT ST (1- p ) x FSAT. The time RTT from the surrogate is about 60-80
ms. Also, the time ST required by the surrogate to search for the data in the surrogate
is in the order of milliseconds. Thus, it is FSAT which effectively determines the
T b o u l b d . The client proxy at any time updates the periodic routine from the log file
Fig-9.28 Data staging in DAYS.
of the mobile unit. If the user is requesting the data, it first accesses the index from
the broadcast and checks the index to see if the required data are there. If the data
are not present in the broadcast, it contacts the surrogate. If the data is present in
the broadcast, then the proxy checks the T control bit of the data. It matches the T
control bit of the data from the index with the T bit present in its periodic routine. If
it is the same as in the periodic routine, it means that the data being broadcasted is the
last modified data which has been accessed earlier by the user. So it must be present
either in its cache or in the surrogate and the user accesses the data. If T doesn’t
match, which means that the data present in the broadcast is the most recent one, then
the client proxy calculates the time for which it will have to wait for accessing the
data. This can be done with the help of the t. bit of the index. If the time required
is less than the ??bound, then the proxy waits for the broadcast data. If the time is
greater than T b O T l l L dthen
the client proxy doesn’t wait for the broadcast and moves
on to access data from the surrogate. It sends the periodic routine or the control
information of the data requested to the surrogate. The periodic routine contains
three control information, B T , P T , and T for any requested page. There is a Stuging
Coordinator (Figure 9.27),which handles the staging of data for the registered clients.
The Stuging coordinator first searches the storage area of the surrogate and if it gets
the data, then it delivers it to the user if there is a request for it. Otherwise, it gets the
periodic routine and sends it to the file server through high bandwidth network. The
file server releases the corresponding data to the staging coordinator. The file server
maintains a hit count for each type of page. Hit count is the total number of times a
data is accessed or staged in a surrogate. When a page is pulled from the server, or
staged to a surrogate, the hit count of that page is incremented. Thus, the hit count
of any page gives the file server the information about the number of accesses of that
page. When the data for any particular client is accessed from the file server, the
Stuging coordinator creates a directory of that type of data using the PT(x) bits of the
pages. The P T ( y ) bit is then used to sequence the data in that directory. When the
data are staged, the coordinator informs the client proxy about the arrival of the data.
Now if the user wants to access the data, the client proxy picks up the data from the
staging machine and makes it available to the user.
This chapter discussed wireless and mobile data dissemination discipline. It started
from a brief history of data broadcast and analyzed in detail a number of schemes to
make necessary data available to people. The discussion began from different modes
of data dissemination and two basic approaches, i.e., Push and Pull. A number of
schemes were developed to satisfy the ever-growing data requirements of users. Realizing the potential of data broadcast in reaching people across the world, researchers
began to use the wireless channel space as a persistence storage media. This motivated
the development of Broadcast disk followed by a number of air indexing schemes.
This chapters discussed in detail these developments and a data dissemination sys-
tem called DAYS - DAta in Your Space. DAYS system offers location-dependent
transactional activity as well as query facilities.
1. Investigate how data flows through a wireless channel. If a data stream is continuously dispatched on the same channel, then the channel can be thought of
as a slorage media for the data stream. Thus the broadcast server could continuously send all its data on a set of channels and eliminate the disk altogether.
Is this storage model acceptable to you’?If not, then what problems do you see
in this model?
2. Investigate additional properties of push and pull approaches. Develop a set of
criteria, which will help us to select when to use push and when to use pull for
efficiently manage data on wireless and mobile systems.
3. Investigate limitation of the broadcast disk approach of storing data.
4. Why indexing is required for accessing broadcast. Suppose the server dispatches weather information of a dedicated channel. A user just tunes this
channel and downloads the weather information. This seems to be easy, then
why do we need index for data download from a broadcast?
5. How the use of major and minor index improves the data access from a broadcast? Do you think that creating more levels of indexing would further improve
data access? Explain your answer and give an example to support your answer.
1. D. Acharya and V. Kumar, “Indexing Location Dependent Data in Broadcast
Environment,“JDIM, Special Issue on Distributed Data Management, 2005.
2. D. Acharya and V. Kumar, “Location based Indexing Scheme for DAYS,“ MobiDEO5, SigmodOS Workshop, Baltimore, MD, 2005.
3. D. Aksoy and M. Franklin, “Scheduling for Large-ScaleOn-Demand Data Broadcasting,” in Proceedings of IEEE Infocorn, CA, 1998.
4. S. Acharya, R. Alonso, M. Franklin, and S. Zdonik, “Broadcast Disks: Data
Management for Asymmetric Communication Environments,”in Proceedings of
ACM SIGMOD Conference, CA, 1995.
5. S. Acharya and S . Muthukrishnan, “Schedulingon-demand data broadcasts: New
metrics and algorithms,“in Proceedings of4th Annual ACMLEEE International
Conjerence on Mobile Computing and Networking, 1998.
6. T. Bowen, G. Gopal, G. Herman, T. Hickey, K. Lee, W. Mansfield, J. Reitz, and
A. Weinrib, “The Datacycle Architecture,“ Communications of the ACM, Vol. 35,
No. 12, December 1992.
7. M. S. Chen, K. L. Wu, and P. S. Yu. “Optimizing index allocation for sequential
data broadcasting in wireless mobile computing,“ IEEE Transaction on Knowledge and Data Engineering (TKDE),Vol. 15, No. 1 , Jan./Feb. 2003.
8. A. Datta, A. Celik, D. E. VanderMeer, and V. Kumar, “Adaptive Broadcast Protocols to Support Efficient and Energy Conserving Retrieval from databases
in Mobile Computing Environments,“ ACM Transactions on Database Systems
(TODS),Vol. 24, No. 1, March 1999.
9. H. D. Dykeman, M. H. Ammar, and J. W. Wong, “Scheduling Algorithms for
Videotex Systems under Broadcast Delivery,” Proceedings ICC, 1986.
10. M. Franklin, S. Zdonik, “Dissemination-Based Information Systems,” IEEE Data
Engineering Bulletin, Vol. 19, No. 3, Sep., 1996.
11. S . Freyth and S. Hartmeier, “Introduction to Low Earth Orbit Sattellite,” Communication Network. 1998.
12. N. Garg, V. Kumar, and M. Dunham. “Information Mapping and Indexing in
DAYS,“ in 6th International Workshop on Mobility in Databases and Distributed
Systems, in conjunction with the 14th International Conference on Database and
Expert Systems Applications, Sep. 1-5, Prague, Czech Republic, 2003.
13. D. Gifford et al., “The Application of Digital Broadcast Communication to Large
Scale Information Systems,“ IEEE Journal of SelectedAreas in Communications,
Vol. 3 , No. 3, May 1985.
14, T. Kiipylii, I. Niemi, and A. Lehtola, “Towards an Accessible Web by Applying
PUSH Technology,“ ERCIM Workshop on User Interface for All, Stockholm,
19-21, October 1998.
15. M. Karakaya, “Evaluation of a Broadcast Scheduling Algorithm,” Lecture Notes
in Computer Science, No. 2 151,2001.
16. V. Liberatore, “Multicast Scheduling for List Requests,“ in Proceedings of IEEE
Infocom, CA, 2002.
17. T. Imielinski, S . Vishwanath, and B. Badrinath, “Energy Efficient Indexing on
Air,“ in Proceedings ACM-SIGMOD, International Conference on Management
ojData, Minnesota, May 1994.
18. T. Imielinski, S. Vishwanath, and B. Badrinath, “Power Efficient Filtering of
Data on Air,“ in Proceedings 4th International Conference Extending Database
Technology (EDBT),Cambridge, UK, March 1994.
19. Imielinski, T., S. Vishwanath, and B. Badrinath, “Data on Air: Organization and
Access“, IEEE Transactions on Knowledge and Data Engineering, Vol. 9. No.
3, MayIJune 1997.
20. C. Partridge, Gigabit Networking, Addison-Wesley Professional Computing Series. Dec. 1993.
21. Partridge, C. “Gigabit Networking”. Addison-Wesley Professional Computing
Series, Reading, MA, Dec. 1993.
22. S. Sheng, A. Chandrasekaran, and R.W. Broderson, “A Portable Multimedia
Terminal for Personal Communication,” IEEE Communications, Dec. 1992.
23. N. Shivakumar and S. Venkatasubramanian, “Energy-efficient indexing for information dissemination in wireless systems,“ ACM/Baltzr Jouvnul of Mobile
Network and Applications (MONET),Vol. I , No. 4, Dec. 1996.
24. K. Stathatos, N. Roussopoulos, and J. S. Barac, “Adaptive Data Broadcast in
Hybrid Networks,“ in Proceedings of the 23rd VLDR Conference,Athem, Greece,
25. S. Su and L. Tassiulas, “Broadcast Scheduling for Information Distribution,”
INFOCOM, 1997.
26. L. William, “Mobile Cellular Telecommunication Systems,” McGraw-Hill, New
York. 1989.
27. N. Vaidya and S. Hameed. “Data broadcast in asymmetric wireless environments,” in First International Workshop on Satellite-based Information Services
(WOSBIS), 1996.
28. S. Viswanathan, “Publishing in Wireless and Wireline Environments,” Ph.D. diusertation at Rutgers State University, New Jersey, 1994.
29. J.W. Wong, “Broadcast Delivery,” in Proceedings of the IEEE, Vol. 76, No. 12,
Dec. 1988.
30. J. Xu, W. C. Lee, and X. Tang, “Exponential Index: A ParameteriLed Distributed
Indexing Scheme for Data on Air,“ in Proceedings 2nd ACM/USENIX Internntional Conj: on Mobile Systems, Applications, und Services (MobiSys),Boston,
MA, June 2004.
3 I . S. Xuan, G. Fernandez, and K. Ramamritham, “Broadcast on-demand: Efficiently and Timely Disseminating ofData in Mobile Environment,” IEEERTAS’97.
A Carrier
Most areas of the United States have two cellular carriers,
each of which operates on a different frequency band. One
is designated the “A” carrier and the other is designated the
“B” carrier. In some markets there may be only one carrier
which may be “A” or “B.“
Ah3 Switching
Most cellular phones have the ability to switch to the “A“
or the “B“ frequency bands. This feature is useful when
roaming outside your home coverage area.
Access Fee
A monthly charge for the ability to connect to a wireless
network. This fee is assessed monthly whether the phone is
actually used or not.
Configuration of a wireless phone so that it is ready to be
used to transmit and receive calls on the wireless network.
Total time that a wireless phone is in connected and in use
for talking. This includes use for calls both received and
Advanced Mobile Phone Service An analog cellular phone
service standard used in the United States and other countries.
Adaptive Power Control A feature of some wireless handsets
that helps reduce power consumption to increase battery
charge life.
B Carrier
Most areas of the US have two cellular carriers, each of
which operates on a different frequency band. One is designated the "A" carrier and the other is designated the "B"
carrier. In some markets there may be only one carrier which
may be "A" or "B."
Describes the transmission capacity of a medium in terms
of a range of frequencies. A greater bandwidth indicate?
the ability to transmit a greater amount of data over a given
period of time.
A short range wireless protocol meant to allow mobile devices to share information and applications without the worry
of cables or interface incompatibilities. The name refers to
a Viking King who unified Denmark. Operates at 2.4 GHz;
Describes a communicationv medium capable of transmitting a relatively large amount of data over a given period of
time. A communications channel of high bandwidth.
Basic Trading Area. A geographic region defined by a group
of counties that surround a city, which is the area's basic
trading center. The boundaries of each BTA were formulated by Rand McNally & Co. and are used by the FCC
to determine service areas for PCS wireless licenses. The
entire United States and some of its territories is divided
into 493 nonoverlapping BTAs.
The area surrounding a cell site. The area in which calls are
handled by a particular cell site.
Cell Site
The transmission and reception equipment, including the
base station antenna, that connects a cellular phone to the
The type of wireless communication that is most familiar to
mobile phones users. Called "cellular" because the system
uses many base stations to divide a service areainto multiple
"cells." Cellular calls are transferred from base station to
base station as a user travels from cell to cell.
(Cloning) A wireless phone that has been programmed to
mimic another wireless phone. Often used to defraud a
wireless carrier by placing illegal calls without any intention
of payment.
Coverage Area
The geographic area served by a wireless system. Same as
Service Area.
(Central Office) A connection point between the wireless
phone system at the MTSO and the landline phone system
at the PSTN.
A signal leak from one channel to another-often the cause
of noise and distortion.
Decibel. A unit of measure used to express relative difference in power or intensity of sound.
Enhanced Specialized Mobile Radio. Using frequency bands
originally allocated for two-way dispatch services, companies such as Nextel and Southern LINC have built digital
mobile phone services similar to cellular and PCS systems.
Electronic Serial Number.
Federal Communications Commission. A United States
government agency responsible for regulating communications industries.
Roaming. The ability of a wireless system to forward incoming calls to a handset that is roaming outside its home
service area without any pre-notification to the wireless carrier.
General Packet Radio Service) An emerging technology
standard for high speed data transmission over GSM networks.
Global System for Mobile. A digital communication technology used by some carriers to provide PCS service. Other
technologies used are CDMA and TDMA.
The transfer of a wireless call in progress from one transmission site to another site without disconnection.
Signals between a wireless phone and a wireless system to
accomplish call setup.
Home Coverage Area A designated area within which cellular calls are local and
do not incur roaming or long-distance charges.
A digital wireless communications protocol designed for
the transport of voice and multimedia content between con-
sumer electronic devices(inc1udingPCs) in a residential setting. Operates at 2.4 GHz; see
Local Multipoint Distribution System. A fixed, broadband
wireless system used for voice and interactive data. Generally used as a lower-cost alternative to landline connections
for businesses and others requiring high-bandwidth connections to public networks.
Multipoint Multichannel Distribution Service. Often referred to as “wireless cable” because it is a wireless system
used to distribute cable television and other broadband signals to multiple users by way of a single transmitter.
Metropolitan Service Area. An area defined by the United
States government for use in grouping census data and other
statistics. MSAs include a city of at least 50,000 people or
an urbanized area of at least 100,000people and the counties
that include these areas. Not all areas of the United States are
in an MSA. The FCC used these area definitions to license
cellular telephone service carriers. There are 306 regions of
the United States designated as MSAs.
Major Trading Area. An area consisting of two or more
Basic Trading Areas as defined by Rand McNally & Co.
These large areas are used by the FCC determine service
areas for some PCS wireless licenses. The United States is
divided into 5 1 MTAs.
Mobile Telephone Switching Office. An office housing
switches and computers to which all cell sites in an area
are connected for the purpose of eventual connection to the
PSTN. The MTSO handles the connection, tracking, status,
and billing of all wireless call activity in an assigned area.
Number Assignment Module. A component of a wireless
phone that holds in electronic memory the telephone number
and ESN of the phone.
A feature of a wireless device that allows reception of a
signal or alphanumeric message.
Personal Communication Services. Used to describe a newer
class of wireless communications services recently authorized by the FCC. PCS systems use a different radio frequency (the 1.9-GHz band) than cellular phones and generally use all digital technology for transmission and reception.
Public Switched Telephone Network. A formal name for
the world-wide telephone network.
RF fingerprinting
An electronic process that identifies each individual wireless handset by examining its unique radio transmission
characteristics. Fingerprinting is used to reduce fraud since
the illegal phone cannot duplicate the legal phone’s radiofrequency fingerprint.
Radio frequency. A radio signal.
Radio-frequency interference. An undesired radio signal
that interferes with a radio communications signal, causing
extraneous noise and/or signal dropouts.
RF Noise
Undesired radio signals that alter a radio communications
signal causing extraneous sounds during transmission andlor
Using your wireless phone in an area outside its home coverage area. There is usually an additional charge for roaming.
Roaming Agreement
A agreement among wireless carriers allowing users to use
their phone on systems other their own home systems. Roaming fee charged for roaming.
Rural Service Area. Areas not included in MSAs are divided
into RSAs. Generally these are the rural areas of the US.
The FCC used RSAs to license cellular carriers in areas not
included in MSAs. There are 428 RSAs in the US.
Service Area
The geographic area served by a wireless system. Same as
Coverage Area.
Service plan
A contract between a wireless carrier and a wireless subscriber that details the terms of the wireless service including rates for activation, access, and per minute usage.
Signal-to-noise ratio
A measure of the power of a signal versus noise. A lower
ratio means there is more noise relative to signal.
Short Messaging System. A feature of PCS phones (primarily GSM) that allows users to receive and sometimes
transmit short text messages using their wireless phone.
The the entire range of electromagnetic frequencies.
Spread Spectrum
A communications technology where a signal is transmitted
over a broad range of frequencies and then re-assembled
when received.
Standby Time
The time a phone is on but not actively transmitting or receiving a call.
Wireless Application Protocol. A global protocol used in
many newer wireless devices that allows the user to view
and interact with data services. Generally used as a means
to view Internet web pages using the limited transmission
capacity and small display screens of portable wireless devices.
A wireless data networking protocol generally used to connect PCs and laptops to a network. Also know as 802.1 1 b
and WLAN (Wireless LAN), it is the most common means
of wireless networking and operates at 2.4 GHz.
Wireless Carrier
A company that provides wireless telecommunications services.
Wireless Local Loop. A wireless system meant to bypass
a local landline telephone system. A home or businesses
phone system is connected to the public network by a wireless carrier instead of by the traditional local phone company.
Absorption, 19
AC, 34
ACID, 130
ACIDL, 150
Active mode, 44
Actively mode, 124
Adaptive exponential Scaling Factor (ASF), 237
Adjacent channel, 28
Adjacent channel interference, 27
AMPS (Advanced Mobile Phone Service), 18
Analogue, 4
Analogue, 28
Anytime Anywhere Computing, 111
Application recovery, 203
Atoiiuc Coniniitinent Protocol (ACP), 180
Band, 12
Bandwidth, 12
Base station (BS), 16
Base stations (BS), 122
Broadband, 29
Broadband PCS, 29
Broadcast channel, 239
Broadcast disk, 230
Broadcast scheduling scheme, 269
BS, 32
BSC (Base Station Controller), 40
BTS (Base Transceiver Station), 32
Cascadeless, 78
Cautious Waiting, 100
CCM, 94
Cell, 15
Cell clustering, 23
Cellular, 3
Cellular conununication, 15
Centralized two-phase locking, 106
Channel, 17
Checkpoint, 209
Cluster, 26, 138
Co-channel, 22.28
Compact agent, 140
Coinpact manager, 140
Compact registry, 140
Compensating transaction, 84
Concurrency Control Mechanisms (CCMs),93
Connected execution, 140
Continuous connectivity, 17
Continuously connected, 118
ConTract, 86
Control index, 243
Coordinator, 126
Cross talk, 22
D-consistent, 157
Data access time, 238
Data broadcast, 221
Data cluster, 138
Data dissemination, 221, 234
Data popularity, 231
Database Management System (DBMS), 61
Database Servers (DBSs), 123
DAYS - DAta in Your Space, 274
DAYS (DAta in your Space), 221
DCS 1800.41
Decentralized 2PC, 183
Degree 0.80
Degree 1.80
Degree 2.80
Degree 3.80
Degrees of isolation, 8 1
Dependency graph, 76
Disconnected, 118
Disconnected execution, 140
Distributed HP-2PL (DHP-2PL), 173
Distributed two-phase locking, 106
Downlink, 41
Downstreani communication, 223
Doze mode, 44, 124
Footprint, 15
Forced disconnection, 130
Forward channel (downlink channel), 17
Fragment Location Mapping FLM, 150
Free-space loss, 19
Free-space loss, 20
Frequency reuse, 28
Frequency reuse distance, 23
Frequency spectrum, 29
Full replication, 113
Global commit, 156
Global Property Set (GPS), 259
Global System for Mobile communications
(GSM), 4
GSM - Global System for Mobile
Communication, 28
GSM, 28,31,34,40
Handoff, 21
Handoffs, 2 1
Hard handoff, 21
Hard Handoff, 55
Hexagon, 24
HiCoMo, 145
History, 74, 76,79
HLR, 33,43
Electronic Serial Nuniber (ESN), 32, 34
Epsilon serializability (ESR), 174
Exponential Index, 255
Extensible Markup Language (XML), 229
Fading, 21
FDMA (Frequency Division Multiple Access), 41
Federated database system, 62
Fixed Hosts (FH), 122
Flash-0-Matic, 2
Flat broadcast, 232
Flat transaction, 66
Flex transaction, 87
Flexible transaction, 147
Idempotent, 66
Idle mode, 124
Improved Mobile Telephone Service (IMTS), 4
Inconsistency, 68
Indexing, 238
Infonnation Content (IC) set, 259
Integrity constraint, 71
Inter-cluster consistency, 138
Intercell or Inter-BS handoff:, 55
Interference, 22,68
Intermittent connected, 118
Intra-cluster schedule, 158
Iridium, 11
Isolation, 151
IVCD (Initial Voice Channel Designation), 37-38
Kangaroo, 148
Latency time, 230
Lazy Bones, 2
Lazy scheme, 206
Linear or nested 2PC,183
Location-dependent information, 258
Location-Aware Query, 114
Location-Based Services (LBS), 258
Location binding, 132
Location-Dependent commit, 118
Location-Dependent Data (LDD), 113
Location-Dependent Query (LDQ), 132
Location Dependent Query, 114
Location Hierarchy (LH), 259
Location Inconsistency, 134
Location index, 259
Location Pointers, 263
Log unification, 214
Logical clusters, 156
Major index, 263
MCHO, 55
Microcell, 41
Mobilaction, 150
Mobile agents, 209
Mobile Computing, 11 1
Mobile Database System (MDS), 16,121,202
Mobile Host (MH), 31
Mobile Identification Number (MIN), 32
Mobile Station (MS), 31
Mobile Support Stations (MSS), 122
Mobile switch (MS), 33
Mobile Switching Center (MSC), 16, 18,33
Moflex, 147
MTSO (Mobile Telephone Switching Office), 33,
Multidatabase system, 62
Multidatabase Transaction Processing Manager
(MDSTPM), 149
Multipath fading (Rayleigh fading), 19
Multiversion, 105
Narrowband, 29
Narrowband PCS, 29
Nested transaction model, 82
NETZ, 39
NMT (Nordic Mobile Telephone), 39
No Undo - No Redo, 202
No Undo - Redo, 202
Noiiiad Computing, 111
On-demand multi-item requests, 266
One-copy schedule, 159
Open nested transaction, 136
Optimistic approach, 106
P-clusters, 154
Paging, 3
Partial replication, 113
Partitioned, 113
PCS - Personal Coiiuiiunication System, 28
PCS, 28-31
Personal, 11 1
Personal mobility, 7
Pervasive Computing, 111
Pessimistic scheme, 206
Physical clusters, 154
Picocell, 44
Point-to-multipoint, 16
Point-to-point, 16
Popularity factor, 235
Power down mode, 44
Powered off mode, 124
Pre-conmiits, 143
Pre-read, 143
Pre-write, 143
Priiiiary copy locking, 106
Pro-Motion, 141
Pro-Motion model, 140
Projection, 75
Protected or Constrained action, 6.5
Proxy, 216
PSTN (Public Switched Telephone Network), 16
Pull process, 224
Push process, 225
Radio frequencies (RF), 11
Radiocoin 2000,4
Radiotelephone, 3
Real action, 65
Recovery, 201
Recovery scheme, 207
Redo, 201
RF, 15
Roaming, 57
Saga model, 84
SAT (Supervisor Audio Tone), 38
SAT (Supervisory Audio Tone), 37
Schedule, 230
Selective tuning, 239
Semaphores, 93
Serial execution, 68
Serializability, 72, 76
Serialization, 93
Serialization graph, 76
Signal fading, 19
SIM (Subscriber Identity Module), 34.40
Skewed and multi-disk broadcast, 232
Smart-pull, 226
Snapshot, 208
Soft handoff, 21
Soft Handoff, 55
Space Conniiand, 2
Spatial, 2
Spatial consistency, 117, 134
Spatial distribution, 116
Spatial Isolation, 151
Spatial replication, 116
Spectrum, 4, 12
Split-restart, 147
SQL (Structured Query Language), 61
Station Class Mark (SCM), 32
Strict transaction, 155
Subtransactions, 126
Systeiii Message Service (SMS), 35
TACS, 39
TDMA (Time Division Multiple Access), 41
Temporal, 2
Temporal consistency, 117, 134
Temporal distribution, 116
Temporal replication, 116
Terminal, 1 11
Terminal mobility, 7
Three-phase checkpointing, 207
Three-Phase Commit, 180
Timestamp, 49, 103
Total Access Coinniunication System (TACS), 4
Transaction Connnit on Tiineout (TCOT), 187
Transaction log, 202
Transceiver, 3 1
Tuning time, 230
Two-Phase Commit, 180
Two-Phase locking, 80
Two-phase locking mechanisms, 106
Ubiquitous Computing, 11 1
Undc-No Redo, 202
Undo-Redo, 202
Undo, 201
Unification factor, 21.5
Unlicensed, 29
Unprotected or free action, 65
Uplink, 41
Uplink channel (reverse channel), 17
Upstreani communication. 223
View serializability, 72
VLR. 33.43
Wait-Die, 104
Weak-read, 143
Weak transaction, 155
Workflow, 82
Wound-Wait, 104
Write Ahead Logging - WAL, 202,204
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF