Proceedings of International Conference on Computing Sciences

WILKES100 ICCS 2013

ISBN: 978-93-5107-172-3
Enhanced non-blocking commit protocol (ENBCP) for lightweight
mobile devices
Taranjot Kaur
1*
, Tejinder Thind
2
and Dr. Rachit Garg
3

1
Student, Department of Computer Science & Egineering, Lovelv Professional Universitv, PB, India
2
Research Scholar, Guru Kashi University, Talwandi Sabo, Bathinda, Punjab, India.
3
Associate Professor, School of Computer Applications, Lovely Professional University, PB, India
Abstract
Commit protocols are used to provide reliable methods to enforce ACID properties in the transactions performed in
distributed environment. Single phase, two phase and three phase commit protocols were developed to cope with the
requirements of distributed systems. Many variants of these traditional protocols are proposed to enhance their capability.
Single phase commit protocol is rarely considered in practice because of its strong assumptions. Two phase commit protocol
is a standard algorithm for safeguarding ACID properties. But this protocol suffers with blocking problem when the
coordinator crashes and the resources are locked by the participating nodes until the coordinator get recovered. Thus reducing
the availability of the system. To overcome this problem, a variant of 2PC was proposed, known as three phase commit
protocol (3PC). 3PC is a non-blocking commit protocol but it involves extra overhead of one more round along with the
additional expense of message transfers. All these traditional protocols are not applicable for mobile distributed systems
because of mobility of nodes, lower bandwidth, frequent disconnection, limited battery lifetime, less storage capacity, etc.
This paper focuses on the traditional protocols that are applicable in distributed systems and also focuses on how these
traditional protocols are enhanced to meet the requirements of mobile distributed systems.
2013 Elsevier Science. All rights reserved.
Keywords: One phase commit protocol, Two phase commit protocol, Three phase commit protocol, Distributed transactions, Mobile
distributed systems, Base station, Mobile host.
1. Introduction
Distributed Systems implements commit protocols for safeguarding ACID properties. From the last few
decades variety of commit protocols has been proposed by the researchers. Traditional one phase, two phase and
three phase commit protocols are applicable for distributed systems. To achieve their functionality these commit
protocols require exchange of multiple messages between coordinator and participating nodes where the
distributed transaction is performed. As the world of computing is shifting towards a trend where transactions are
performed in a distributed manner and most of the communicating devices are mobile. Such an environment is
known as a mobile distributed system. It is difficult to ensure ACID properties in distributed transactions
performed in mobile distributed systems because of mobility of node, handoff, low power devices, low
bandwidth, etc. So the traditional commit protocols are enhanced to meet the requirements of mobile distributed
systems. Variants of 2PC such as Mobile 2PC Protocol (M-2PC), Optimistic Concurrency Control with Update
Time Stamps (OCC-UTS), Timeout- Based Mobile Transaction Commit Protocol (TCOT), Unilateral Commit
for Mobile (UCM) are applicable for mobile distributed systems.
*
Corresponding author Taranjot Kaur
433 Elsevier Publications, 2013
Taranfot Kaur, Tefinder Thind and Dr. Rachit Garg
2. Related Term
2.1 Mobile Distributed System (MDS)
A distributed system is a collection of independent computers that are capable of communicating with each
other by exchanging messages. The integration of distributed systems and the mobile communication
infrastructure has played a vital role in swift growth of computing. This integration of mobile systems and
distributed systems have led to the evolution of Mobile Distributed Systems. When in a distributed system,
some of the tasks are executing on the mobile hosts, it makes a Mobile Distributed System (MDS). Distributed
applications are extensively being used in almost all application areas including business, education, production
and office automation. Also, mobile computing and wireless networks have made advances in remote monitoring,
e-commerce, disaster and emergency operations in remote locations, and personal communication through
wireless Internet.
2.2 Mobile Distributed System Architecture
When in a distributed system, some of the transactions/tasks are executing on the mobile hosts, it makes a
Mobile Distributed System (MDS). MDS architecture consists of two set of entities named Mobile Hosts (MH)
and Fixed Hosts (FH). Moving nodes are often called Mobile Hosts (MH) that are connected to the fixed network
via Mobile Support Station (MSS), which is also known as Base Station (BS). Each BS covers geographical area
known as cell. MH can directly communicate with the BS and other mobile hosts within one cell. If MH cross the
boundary of one cell and enters into another cell while being active then this process is called handoff. It is the
responsibility of BS to handle handoff. BS is also responsible for handling communication between mobile hosts.
MH retain their network connection even during mobility from one geographical area to another using handoff
concept. One base station is connected to other base station through wired links [6].
Figure 1- Mobile Distributed System Architecture
2.3 Acid Properties
For the successful termination of distributed transactions, it is mandatory that all the participants must agree
on a particular decision, so that each participant can commit the transaction and guarantees for the persistent data.
434 Elsevier Publications, 2013
Enhanced non-blocking commit protocol for lightweight mobile devices
The four properties that are associated with a transaction are called ACID properties [10]. ACID stands for
Atomicity, Consistency, Isolation, Durability.
Atomicity: In order to fulfill this property either all of the operations performed by the distributed transaction are
commit or none of the operations are committed in the case of failure.
Consistency: In order to fulfill this property the state of the distributed system must remains same i.e. consistent
before and after the transaction.
Isolation: Isolation allows multiple transactions to be executed concurrently without seeing the intermediate
result of other transactions because each transaction is executed in isolation from others.
Durability: Durability guarantees the persistent data even after the failure.
2.4 Issues Associated With Distributed Transactions
i. Develop an atomic commit protocol :
In a distributed environment, a transaction involves processes that are running on different systems. So the
successful completion of a distributed transaction needs all the participating nodes to be agreed on a particular
decision in order to either commit or abort the transaction.
ii. Handling distributed deadlock :
In a distributed transaction, a large number of processes that are running on different systems are waiting for
some others to release the resources.
Traditional three protocols namely single phase commit (1PC) protocol, two phase commit (2PC) protocol and
three phase commit (3PC) protocol were available for solving the commitment problem. Due to the fastest
evolution of mobile computing, these traditional protocols are not applicable in mobile distributed systems
because of mobile nodes, lower bandwidth, frequent disconnection, higher latency and error rates, low battery
lifetime, limited memory, disconnected computing and more expensive cost. This paper presents the traditional
protocols that are applicable for distributed systems as well as enhanced variants of traditional protocols that are
suitable for mobile distributed systems.
3. Single Phase Commit (1PC) Protocol
The concept of single phase commit protocol was suggested by GRAY in 1987. Although variations of single
phase commit protocol has been proposed but it is rarely considered in practice because of strong assumptions
like enforcement of consistency constraints, local autonomy, reliability of sites, communication medium, it
requires from the mobile distributed transactional system. Several variations of single phase commit protocol are
Implicit Yes-Vote protocol (IYV), Early Prepare (EP) protocol, Coordinator Log (CL) protocol, Optimistic
Commit protocol.
3.1 Early Prepare (EP) protocol
This protocol enforces each participating node to enter in a prepare state after the execution of each
transaction. It forces the nodes to vote implicitly. As the transactions execution progresses, the transaction
membership also increases. Therefore a coordinator need to maintain multiple membership records. The
drawback of this approach is that a log of each transaction need to be stored on the nodes log disk. But this
creates a serious disk blocking problem. This protocol can be used only if each server has a stable storage so that
log forces are free [8].
435 Elsevier Publications, 2013
3.2 Coordinator Log (CL) protocol
This protocol overcomes the disk blocking problem of participating nodes by centralizing the log record on the
coordinator itself. But this approach can be practical only if the entire distributed system is kept in a single room
rather than over a large geographical area.
3.3 Implicit Yes-Vote (IYV) protocol
This protocol allows the participating node to be partially recovered independently of the coordinator in case
of failure and resume the execution of the transaction that are still active in the system instead of aborting them.
3.4 Optimistic Commit protocol
This protocol concentrates on reducing the lock waiting time by lending the locks to be hold by the
committing transaction. It eliminates the chance of cascading abort even if the committing transaction is aborted
because the lock lending is done in a controlled manner.
4. Two Phase Commit Protocol (2PC)
The classical two phase commit protocol is the simplest distributed algorithm for the consistent termination of
the transactions in a distributed environment. It fulfil the ACID properties of the distributed system, hence named
atomic commit protocol. There is only one coordinator in the 2PC and all the participating nodes are known as
cohorts. This protocol consists of two phases namely prepare (voting phase) and commit (decision phase) phase.
It allows all the nodes in the distributed system to agree on a common decision to commit or abort the transaction
even in the case of failure. 2PC is also referred to as a blocking commit protocol, in the situation when the
participating nodes received the vote request and process the result but in the meanwhile the coordinator failed
and the nodes are blocked until the coordinator is recovered [13].
4.1 Assumptions of 2PC
a) No cohort can fail permanently.
b) 2PC is assumed as fail-stop model in which the failed nodes simply stop working without any harm rather
than sending erroneous messages to other nodes.
c) Each cohorts should have stable storage.
d) Each cohorts should maintain a log before performing any transaction in order to fulfil the atomicity and
durability property. This type of logging is known as write-ahead logging.
e) All the cohorts are stationery.
4.2 Phases of 2PC
The 2PC algorithm consists of two phases: voting phase and commit phase. On the basis of the result of
voting phase the coordinator decide either to commit or abort the transaction. If all the cohorts send
VOTE_COMMIT message then the commit message is sent globally by the coordinator. The coordinator
globally send abort message to all the cohorts if any of the cohort send VOTE_ABORT message. All the
decisions are logged on a stable storage so that recovery procedure can be performed in the case of failure.
436 Elsevier Publications, 2013
Taranfot Kaur, Tefinder Thind and Dr. Rachit Garg
Enhanced non-blocking commit protocol for lightweight mobile devices
Voting phase :
1 .The coordinator sends a VOTE_REQUEST message to all the cohorts in the distributed system.
2. Each cohort receives the VOTE_REQUEST message.
a) If a cohort is ready to commit its own part of transaction then it will send VOTE_COMMIT message to the
coordinator.
b) If a cohort is not ready to commit its own part of transaction then it will send VOTE_ABORT message to the
coordinator.
Commit phase or Decision phase :
3.The coordinator waits for the reply of VOTE_REQUEST message.
a) If all the cohorts send VOTE_COMMIT message to the coordinator, it means all the cohorts are agree to
commit the transaction then the coordinator will send GLOBAL_COMMIT message to all the cohorts.
b) If any of the cohort send VOTE_ABORT message to the coordinator, it means that particular cohort/cohorts
are not agree to commit the transaction then the coordinator will send GLOBAL_ABORT message to all the
cohorts.
4.Cohorts wait for the reply of the coordinator.
a) When the cohorts received GLOBAL_COMMIT message from the coordinator then all the cohorts commit
the transaction and sends ACK message (acknowledgement) back to the coordinator.
b) When the cohorts received GLOBAL_ABORT message from the coordinator then all the cohorts abort the
transaction.
Figure 2- Two Phase Commit Protocol (2PC)
4.3 Advantages of 2PC
a) It ensures independent recovery of all participating nodes.
b) It ensures atomicity even in the presence of deferred constraints ( checks that are validated only at the time of
commit).
4.4 Problems with Traditional 2PC
a) Blocking situation occurs in 2PC when the coordinator fails and the cohorts are in waiting state i.e. holding
lock on the resources until the coordinator get recovered.
b) Single point of failure.
c) Multiple forced log writes increase latency [4].
437 Elsevier Publications, 2013
4.5 Variants of 2PC
Presumed Commit (PrC) and Presumed Abort (PrA) are the two variants of traditional 2PC that are used to
reduce the overhead of ACK messages and forced log-writes during the commit phase [14]. But the voting phase
of 2PC remains same.
1. Presumed Commit (PrC) : This variation is preferred when the number of committed transactions are
more than the number of aborted transactions in a distributed system.
2. Presumed Abort (PrA) : This variation is preferred when the number of aborted transactions are more
than the number of committed transactions in a distributed system.
Due to the rapid evolution of mobile distributed computing, the scenario requires protocols for
committing mobile distributed transactions. But the traditional approaches of two phase commit protocol
are not applicable in mobile distributed environment because of several reasons like frequent
disconnection, limited storage capacity, handoff, limited battery lifetime, etc. Therefore for these
reasons, the traditional approaches of 2PC are enhanced in such a way so that they fit according to the
requirement of the mobile distributed environment.
(i) Mobile 2PC Protocol (M-2PC)
In this approach, the effort is made to reduce the number of messages exchanged between mobile host and
base station. In this scenario the base station becomes the coordinator and the initiating nodes become the
participating nodes. It utilizes the concept of batch processing in order to send transactions in the form of batches
from mobile host to the base station i.e. the coordinator [6]. Whenever the mobile host needs to change its
geographical area, it sends message to the base station to inform that a handoff is needs to be performed. Partially
completed transactions of the mobile host are sent along with the state of the transaction to the new coordinator
i.e. base station while handoff. For committing the decision, all the base stations that participated in the
transaction also need to be involved. Limitations of this protocol are :
(a)For n number of hands-off, 4n additional messages are required. For p number of participants (4p + 4n)
additional messages are generated.
(b)Simultaneous disconnection and hands-off cannot be handled by this approach. If the mobile host fails in
one cell then it needs to be recovered in the same cell.
(ii) Optimistic Concurrency Control with Update Time Stamps (OCC-UTS)
This protocol is based on the concept of serializability. This protocol assumes that the transaction should be
locally executed at the client side (in the offline mode) and must save the intermediate results in the local cache,
before the final commitment at the server and hence reduce the number of abortions. Each transaction is
associated with the timestamp. The clients transactions timestamp is compared with the last update stamp at the
server. For this purpose server will periodically broadcast invalidation reports. If the client finds its transactions
time stamp to be already updated in the invalidation report then it will simply roll back that transaction without
exchanging any message over the wireless links. Otherwise a request is sent by the client to the server for
committing that transaction. Verification process is performed by using backward serializable concept. This
protocol is suitable for locally executing the applications (offline) on portable computers and PDAs. This
protocol best suits to hybrid mobile networks which consists of static and mobile nodes. Disadvantage of this
protocol is that no mobile server is taken into account.
(iii) Timeout- Based Mobile Transaction Commitment Protocol (TCOT)
This protocol is based on the concept of mobile connectivity, in which the clients remain connected to the
network through wireless channels irrespective of their state (static or mobile) and geographical location. TCOT
is an optimistic approach in which the fragments are completed and committed within well defined timeouts with
438 Elsevier Publications, 2013
Taranfot Kaur, Tefinder Thind and Dr. Rachit Garg
Enhanced non-blocking commit protocol for lightweight mobile devices
minimum risk of abortions. The author proposed to calculate timeouts by considering function of many system
and communication variables such as I/O rate, workload, cache hit rate, etc. In TCOT each transaction is splitted
into fragments that will be executed on different participating sites with the first fragment to be executed at the
initiating mobile host. The coordinator (BS) sends the fragments to the relevant DBSs (database servers) in order
to update the primary copy. The participant sites locally take decision to commit / abort its own fragments and
inform the coordinator. Mobile hosts send their log and updates to the coordinator (BS) and when the BS take
decision for global commit/abort then it forwards them to their relevant DBS. If the MH receives global abort
message after local commit then a compensating transaction is needed. In the handoff scenario, coordinator is
either chosen statically or dynamically. When the MH change its geographical area then it informs the BS about
its previous BS and participant DBS during registration. The new BS broadcast information about this change to
all the DBSs. In normal execution only two messages are exchanged between BS and MH. But during fast
movement of MH and frequent disconnection, risk of abortion increases as well as the number of wireless
messages exchanged also increases exponentially [13].
(iv) Unilateral Commit for Mobile (UCM)
The focus of Unilateral Commit for Mobile (UCM) protocol is to execute off-line transactions and handling
communication between lightweight mobile clients and servers. The off-line transactions are committed as soon
as their log has been transferred to the BS without waiting for the acknowledgement of fixed servers because all
the verification procedure is performed before commit time. UCM is based on the concept of one phase commit
protocol. Handoff and mobility problems are not explicitly handled by UCM. Five types of software components
interact during the execution and termination of a transaction. These are:
(a)Application: That are initiating the transaction operation.
(b)LogAgent: Responsible for logging each operation before execution.
(c)Participants: Responsible for executing the operations.
(d)Coordinator: Responsible for taking global decisions(commit/abort) i.e. pilots the termination protocol.
(e)PAgents: Responsible for representing the participants during termination protocol and are used during
recovery.
5. Three Phase Commit Protocol (3PC)
Three phase commit protocol was developed by Skeen in 1981 to overcome the blocking problem of two
phase commit protocol. Three phase commit protocol is an enhanced version of 2PC in which an extra buffered
phase is introduced between voting phase and decision phase known as pre-commit phase that avoids the
blocking of transactions in the presence of fail-stop crashes. Therefore 3PC is also referred to as a non blocking
commit protocol.
5.1 Phases of 3PC
Three phase commit protocol consists of three phases namely voting phase, pre-commit phase and decision
phase. The extra phase i.e. pre-commit phase helps to solve the blocking problem of 2PC but it involves extra
overhead of one more round with additional cost of message transfers and in turn takes more time for completing
the transaction [11].
Voting phase
1.The coordinator sends a VOTE_REQUEST message to all the cohorts in the distributed system.
2.Each cohort receives the VOTE_REQUEST message.
439 Elsevier Publications, 2013
a) If a cohort is ready to commit its own part of transaction then it will send VOTE_COMMIT message to the
coordinator.
b) If a cohort is not ready to commit its own part of transaction then it will send VOTE_ABORT message to the
coordinator.
Pre-commit phase
3.The coordinator waits for the reply of VOTE_REQUEST message from all the participants.
a) If all the participants send VOTE_COMMIT message to the coordinator, it means all the cohorts are agree to
commit the transaction then the coordinator will send PREPARE_COMMIT message to all the cohorts.
b) If any of the cohort send VOTE_ABORT message to the coordinator, it means that particular cohort/cohorts
are not agree to commit the transaction then the coordinator will send GLOBAL_ABORT message only to
those node that send VOTE-COMMIT message as the nodes that send VOTE_ABORT message already
know the decision.
4.Cohorts wait for the reply of the coordinator.
a) When the cohorts received PREPARE_COMMIT message from the coordinator then all the cohorts commit
the transaction and sends READY_COMMIT message back to the coordinator.
b) When the cohorts received GLOBAL_ABORT message from the coordinator then all the cohorts abort the
transaction.
Decision phase
5.Coordinator waits for the replies from all the participants.
a) If all the participants send READY_COMMIT message to the coordinator, it means all the participants are
ready to commit the transaction and then GLOBAL_COMMIT message is sent by the coordinator.
b) If the coordinator gets a timeout waiting for the READY_COMMIT message from the participants, but the
coordinator knows that the participants has sent VOTE_COMMIT message and now is unavailable then the
coordinator send GLOBAL_COMMIT message to the remaining participants.
6.When the participants receive GLOBAL_COMMIT message from the coordinator then all the participants
commit the transaction and send an ACK (acknowledgement) message to the coordinator.
Figure 3- Three Phase Commit Protocol (3PC)
6. Comparison
Table 1 summarize the difference between variants of 1PC i.e. EP, CL, IYV, basic 2PC, variants of 2PC i.e.
PrA, PrC and 3PC on the basis of certain parameters. The drawbacks of variants of single phase commit protocol
are eliminated by using 2PC. And further the blocking problem of 2PC is eliminated by the development of 3PC.
440 Elsevier Publications, 2013
Taranfot Kaur, Tefinder Thind and Dr. Rachit Garg
Enhanced non-blocking commit protocol for lightweight mobile devices
Therefore 3PC is considered as non-blocking commit protocol. But 3PC suffers with extra overhead due to more
number of messages exchanged and also increase complexity and cost . EP requires stable storage for logging
each operation after execution of every transaction. Therefore it requires 1+(n+p_op) log writes. Each variant of
1PC require only single step for communication. Whereas basic 2PC and its variants require three steps and 3PC
requires five steps for communication. Degree of blocking of resources is high in EP but in CL it is
comparatively lower than EP. 2PC protocol suffers with blocking problem thats why it is also known as blocking
protocol. This table also summarize the drawbacks of each approach.
Table 1. Comparison Between 1PC, 2PC and 3PC.
Here n denotes no. of participants and p_op denotes no. of operations performed by a transaction
Message
exchange
Log writes
Communication
Steps
Degree of blocking Drawbacks
EP ( n 1) 1+(n+p_op) 1 High
(i)Requires stable storage.
(ii)Serious disk blocking problem.
CL ( n 1) 1 1 High
(i)Not applicable for geographically distributed
location.
IYV 2( n 1) 1 +n 1 High
(i)Require strong assumptions for implementation.
2PC 4( n 1) 1 +2n 3 High
(i)Single point of failure
(ii)Blocking problem
(iii)multiple forced log writes increase latency
PrA 4( n 1) 1 +2n 3
Comparatively
lower than 2PC
(i)Participants do not log or acknowledge abort
decisions.
PrC 3( n 1) 2 +n 3
Comparatively
lower than 2PC
(i)Require more storage for every log write.
3PC 5( n 1) 2n 5 Low
(i)Extra overhead.
(ii)Increased complexity & cost.
7. Conclusion
This paper has demonstrated traditional 1PC, 2PC and 3PC protocols that are used for safeguarding ACID
properties in distributed transactions. In order to eliminate the blocking problem of 2PC, a non-blocking commit
protocol called 3PC was developed. Further 3PC overcomes the blocking problem of 2PC but at the rate of extra
expensive message transfers. It also demonstrated how these protocols are inadequate to support mobile
distributed transactions. To meet the requirements of largely growing applications involving low powered and
lightweight mobile devices, many variants of traditional protocols are modified. The enhanced protocols that
support mobile distributed transactions are UCM, TCOT, M-2PC, OCC-UTS, etc. These protocols do not
safeguard ACID properties but they provide semantic atomicity.
References
[1] J . R. Hraista, K. Ramamritham. The PROMPT Real-Time Commit Protocol. IEEE Transacions on Parallel and Distributed Systems. Vol.
11, NO. 2, February 2000.
[2] G. K. Attaluri, K. salem. An Analytical Approach for Guaranteeing Concurrency in Mobile Environments. IEEE Transactions on
Knowledge and Data Engineering. Vol. 14, No. 5, September/October 2002.
[3] Armand Wilson. SAP White Paper on Distributed Transactions and Two-Phase Commit, 2003.
[4] Anshu Veda, Kaushal Mittal. Project Report on One and Two Phase Commit Protocols, October 2004.
[5] N. Nouali, H. Drias, A. Ducet. A Two-Phase Commit Protocols for Mobile Wireless Environment. Australian Database Conference, 2005.
441 Elsevier Publications, 2013
[6] N. Nouali, H. Drias, A. Ducet. Protocols for Committing Mobile Transactions. International Arab J ournal of Information Technology.
Vol. 3, No. 2, April 2006.
[7] M.Shahza, Dr. C. Bamford, Prof. Taleb-Bendiab, Dr. Diyah Al-J umeily. In Search of Efficient Non Blocking Atomic Commit Protocol.
ISBN: 978-1-902560-19-9, PGNet, 2008.
[8] S. Kumar, S. Barvey. Non-Blocking Commit Protocol. IJ CSNS, VOL.9 No.8, August 2009.
[9] S. Abdul Moiz, L. Rajamani. An Analytical Approach for Guaranteeing Concurrency in Mobile Environments. Proceedings of WCECS,
2010.
[10] K. Asha, G. Ashwini, S. Ashlesha, B. Usha. Transaction Management in Distributed Database. BIOINFO Transactions on Database
Systems. Volume 1, Issue 1, pp-01-06, 2011.
[11] P. Singh, P. Yadav, A. Shukla. An Extended Three Phase Commit Protocol for Concurrency Control in Distributed Systems.
International J ournal of Computer Applications (0975 8887) Volume 21 No.10, May 2011.
[12] T.Thind, R. Garg, U. Kaur, D. Kumar. Paradigms in Fault Tolerant Checkpointing Protocols in Distributed Mobile Systems. ICCS, 2012.
[13] B. Harsoor, Dr.S.Ramachandram. Comparison Study of Commit Protocols for Mobile Environment. IJ ACSA, Vol. 3, No. 9, 2012.
[14] V. Manikandan, R. Ravichandran, R. Suresh, F. Sagayaraj Francis. An Efficient Non Blocking Two Phase Commit Protocol for
Distributed Transactions. International J ournal of Modern Engineering Research (IJ MER). Vol.2, Issue.3, pp-788-791 ISSN: 2249-
6645, May-J une 2012.
442 Elsevier Publications, 2013
Taranfot Kaur, Tefinder Thind and Dr. Rachit Garg
Index

C
Check-pointing, 429
aspects of, 431
message logging based, 430431
quasi-synchronous/communication induced, 430
uncoordinated and coordinated, 430

D
Distributed systems, 426

M
Mobile computing, 425
Mobile distributed systems, 426
issues and challenges, 427429

W
Wireless communication, 426