A Review of Data Synchronization and Consistency Frameworks for Mobile Cloud Applications

Mobile devices are rapidly becoming the predominant means of accessing the Internet due to advances in wireless communication techniques. The development of Mobile applications (“apps”) for various platforms is on the rise due to growth in the number of connected devices. Numerous apps rely on cloud infrastructure for data storage and sharing. Apart from advances in wireless communication and device technology, there is a lot of research on special data management techniques that addressed the limitations of mobile wireless computing to make the data appear seamless for accessing and retrieval. This paper is an effort to survey the frameworks that support data consistency and synchronization for mobile devices. These frameworks offer a solution for the unreliable connection problem with customized synchronization and replication processes and hence helps in synchronizing with multiple clients. The frameworks are compared for the parameters of consistency and data models (table, objects or both) support along with techniques of synchronization protocol and conflict resolution. The review paper has produced interesting results from the selected studies in areas such as data consistency, handling offline data, data replication, synchronization strategy. The paper is focused on client-centric data consistency and the offline data synchronization feature of various frameworks. Keywords—Mobile cloud computing; data consistency; mobile back-end as a service; distributed systems; mobile apps


I. INTRODUCTION
The model of mobile cloud computing utilizes the services of cloud computing.The mobile cloud environment consists of portable computing devices, mobile Web and location-based services, supported by wireless communication infrastructure, to provide mobile devices online access to large storage space and unlimited computing power [1].A wireless network with mobile clients is fundamentally a distributed system but suffer from the primary challenges such as limited computational capacity and storage of mobile devices, intermittent loss of connectivity and battery power restrictions.The transmission bandwidth of the mobile device is likely to be lesser than the transmission bandwidth of the mobile support stations (MSSs) and this leads to the phenomenon of communication asymmetry.The effective management of data in systems with the mobile client is affected by these limitations.The environment of frequent disconnections and limited bandwidth, impact the data and transaction management as well as the data consistency guarantees.
To provide the illusion of uninterrupted data access, the data management must hide the constraints of mobile wireless computing.The technique of replicating data locally on the mobile device enables the user to carry offline data without the need to always be connected to the data server.The ability to disconnect with the network, do local changes, and then reintegrating (synchronize) these changes back into the system makes the mobile gadget an essential extension to modern distributed databases and collaborative tools [1].
Data synchronization is an empowering process that eliminates the critical requirement of having steady connectivity and permits users to run data-centric mobile applications while being offline.Hence data synchronization allows users to carry out operations of additions, deletions, and updates on the offline data, while disconnected from the network.
Generally, the mobile applications (which we generally refer to as 'Apps') are developed according to the different application programming interfaces (API) abstractions supported by the underlying mobile middleware.The middleware may provide a simple file-based API (possibly extended with replication-specific methods).It may also support complex abstraction such as objects, tuples, relational entities or an object which may contain pointers to other interdependent objects.Middleware with database replication primarily provides query oriented CRUD APIs(Create, Read, Update and Delete) to application developers for typical operations on data with declaratively defined by SQL queries for the update, creation/insertion, and deletion of records.This section covers the introduction to replication, datacentric and client-centric consistency models.Section II and III classify and describe various consistency and synchronization frameworks in mobile cloud computing.In Section IV we discuss research findings and recommendations followed by related work (Section V) and conclusion with future work (Section VI).Table I shows the list of acronyms used in the paper.

A. Mobile Computing Environment and Limitations
Generally, a mobile cloud computing environment has two unique sets of entities namely Fixed Hosts (FH) and Mobile Hosts (MH) [1].FHs are machines (Works stations and Servers) with efficient computation power and reliable storage of data and run large databases.FHs that are connected through the fixed network.MHs with limited processing and storage power(cellular phone, palmtops, laptops, notebooks) are not continually communicating with the fixed network.They may be disconnected for various reasons such as due to the battery power saving measures and also due to disconnections during frequent relocation between different cells.Additional dedicated fixed hosts called mobile support stations (MSSs) acts as the channel between the FH and MH through wireless LAN (local area network) connections, cells or connections to the network with standard modems.
When the network connectivity becomes unavailable or unacceptable, the MH enters the disconnected state.Disconnected operation (see Fig. 1) is a three-stage changeover between the following states [3]: 1) Data hoarding: This is the process of preloading or prefetching the data in anticipation of a foreseeable disconnection.Before going to offline mode (disconnection), the data structures necessary for operation during disconnection are either replicated (catched) or moved (partitioned) at the MH. 2) Disconnected operation: When the MH is offline (disconnected from the network), data might be changed, added or even removed at either the MH or the FH. 3) Synchronization or Reintegration: When the connection is reestablished, each operation executed at the MH should be synchronized (reintegrated) with appropriate updates executed at other sites in order to attain seamless consistency.
For a given distributed system, the complexity of operations in each of the above three states is determined by the interdependence of data operated on.The issues pertaining to three states is summarized in Table II.

B. Replication
Replication is a basic strategy to support fault resilience, high data availability and quick response for universally available services.Replication process creates many instances of the identical object in different machines, over a distributed or local network ( [3], [4], [5], [6], [7], [8]).The copies of

System dependent Disconnection
How to synchronize?
Re-execute an operational log Reintegration or Synchronization How to resolve conflicts?

Automatic resolution
Use application-semantics Provide utility to aid the user these multiple objects (replicas) are persistently maintained over time in order to allow the workload to be divided over the possible number of replicas.The replication strategy involved in a different distributed system depends on the requirements of data freshness tolerance.The use cases in some applications need only read operations, while others high ratio of writes(updates) compared to read.Banking systems require that data is always consistent over time and some social networks may tolerate stale data.

C. Consistency Models
The literature [9] [10] describes data-centric and clientcentric consistency as the two principle viewpoints on consistency.The data-centric consistency manages the internal state details by guaranteeing that all the replicas are same and ensures system maintains consistency for updates.Data-centric consistency is important to system developers.Client-centric consistency deals with only observing data updates as a black box and hence application developers focus on client-centric guarantees.Ordering and Staleness are the two criteria for measuring guarantees of both data-centric and client-centric consistency.Staleness is measured in the unit of time (tperceivability) or versions (k-staleness), calculated based on how much a given copy is falling behind [11] [12].

D. Data-Centric Models (Server-Side Consistency Models)
1) Strong consistency -A system adopting a strong consistency model is in a consistent state all times.The strong consistency is a single-copy consistency model that is not suitable for mobile applications dealing with cloud data due to the availability and performance issues as mandated by CAP theorem [13].2) Sequential consistency -This is a slightly weaker form of strong consistency with the condition that, same order of execution is maintained for all the sequentially related requests.Subsequently, the clients observe the same order and sequence of updates.
3) Causal consistency -In a system adopting the Causal Consistency (CC), the same sequence of execution is maintained on all replicas, for all the causally related requests.The non-related requests are followed in random order.4) Grouping operations -This model deals with handling the cases of, series of reading and write operations.The Grouping Operation model allows raising the level of granularity to span multiple reads and writes, into an atomically executed unit.
E. Client-Centric Models (Client-Side Consistency Models) 1) Weak consistency -A weak consistency model does not guarantee that subsequent accesses will return the updated value.The term 'inconsistency window' [10] attribute to the time between the update and the instant when it is guaranteed that any observer will always see the refreshed value.The studies [15] [16] conclude that it is mandatory to guarantee all four client-centric models (MRC, RYWC, MWC, and WFRC) for the system to achieve client-centric consistency.

II. CLASSIFICATION OF CONSISTENCY, SYNCHRONIZATION AND REPLICATION SYSTEMS IN MOBILE COMPUTING
This section classifies the current efforts into different types such as systems for weakly connected clients, sync services and systems supporting geo-replication.The studies are also classified based on three PRACTI properties [2].

A. Systems for Weakly-Connected Clients
Many previous attempts have dealt with data replication and management in systems where mobile clients intermittently connected either to servers or to peers ([3], [4], [17], [2], [18], [19]).Systems like Coda [3] and Ficus [19] address the issues in handling disconnected operations and replicate files providing high availability at the cost of consistency.Bayou [4] is a distributed relational database system that provides eventual data consistency, under offline mode.These systems differ on their procedures to handle conflicts.For instance, Bayou performs application-level conflict resolution, while Coda and Ficus allow system level resolution of conflicts.Some Systems (like Simba [20]) are aimed to provide more control for mobile applications to select suitable consistency abstractions for data synchronization services.
There are several studies which explicitly focus on the efficiency of data management systems for weakly connected clients ( [21], [22], [23], [24]).In compliance to different requirements of apps, Odyssey [23] system give OS support for applications to modify the fidelity of their data to accommodate resource changes, such as wireless network bandwidth fluctuations and battery conditions.Cedar [24] increase the query processing capability by identifying the commonality between client and server query results and hence provides productive mobile database access.In LBFS [21] (low-bandwidth network file system), the content-based chunking technique prevents redundant transfer of files and also detect inter-file similarities.

B. Geo-Replication
There are several studies which focus on the tradeoff between consistency, availability, and performance for geodistributed services.These system handle data replications within and across and data centers.Some systems primarily aimed at providing low-latency causal consistency at scale (e.g. , COPS [25] and Eiger [26]) and others (e.g., Red Blue consistency [27], Walter [8], Transaction Chains [28], and ) focus to reduce the latency involved in supporting other forms of stronger-than-eventual consistency, including serializability under limited conditions.Arbitrary consistency selection systems (e.g., Pileus [29] and SPANStore [30] ) attempt to provide more control for applications to choose suitable consistency across data centers, to meet SLAs or to minimize operating costs.

C. PRACTI Paradigm
In a distributed system, an optimal replication system should support all the three PRACTI [2] properties. 1) PRsystem (Partial Replication) allow any node to store a subset of data and metadata.2) AC-system (Arbitrary Consistency) provide flexibility of selection of consistency semantics (different types of configurable consistency guarantees like both strong and weak consistency) for applications.3) The TI-systems (Topology Independence) permit all nodes to send updates to all other nodes (TI).
Applying PRACTI taxonomy to the current studies, the existing replication systems fall into the following four protocol groups.Each system compliant to most two of the PRACTI paradigm properties. 1) Server replication: Some systems use the log-based peer-to-peer update exchange protocol for serverside replication.This protocol follows full replication mechanism and allow all nodes to store complete data from any volume and also all nodes collect all updates.This protocol helps to achieve topology independence (TI) in some systems (e.g., Bayou [4] and Replicated Dictionary [31]), where any node to send updates to any other node.Some Systems like in TACT [32] and Lazy Replication [33]) use this protocol to provide more control to select suitable consistency guarantees for data synchronization (AC).Since the protocol does not support efficient network usage due to full replication, these systems may be not suitable for devices with limited resources.2) Some systems with client-server architecture (e.g., Coda [3] and Sprite [34]) and hierarchical caching systems (e.g., hierarchical AFS [35]) implement a protocol to selectively replicate/cache arbitrary subsets of content (PR).Apart from supporting a group of consistency policy by the system, a supplementary extension of consistency guarantees are provided by changing the basic architecture (AC).In order to support consistency, the partial replication protocols need intercommunication between a child and its parent and also serialize control messages at the central server node [36].Due to these communication complexities, the performance, availability and data sharing features may be paralyzed in such systems.3) In the Distributed hash table (DHT)-based storage systems (e.g., PAST [37], CFS [38] and BH [39]), the scalability is achieved by load balancing the server across various nodes, on a per-object or per-block basis.For high availability, the data is also replicated to multiple nodes and such architecture becomes challenging for providing the consistency guarantees.4) Object replication systems (e.g., WinFS [40], Ficus [41] and Pangaea [42]) permit nodes for selective replication/caching of arbitrary subsets of data (PR) and communication with every other peer (TI).These protocols lack consistency guarantees since they do not mandate ordering constraints on updates across multiple objects.

D. Synchronization Service Frameworks
The existing services mainly offer sync services into three categories: (1) File-only, (2) Table-only and combination of (3) Table and Object.Izzy [43] and Mobius [44] sync services provide a platform for structured data like tables only, to expedite the development and deployment of data-centric mobile apps.Mobius guarantee that all clients observe write operations in the same order, maintaining the flexibility of local client views to diverge (fork-sequential consistency [45]).Dropbox sync service provides dedicated API for tables and do not store files and tables together.Many Mobile apps are developed using the file sync services of Google Drive [46], iCloud [47], Dropbox [48] [49] and Box Sync [50].StackSync [51] is an open-source Personal Cloud framework that provides scalable file synchronization and sharing.QuickSync [52] is a system that focuses on improving the synchronization performance of cloud storage, in wireless networks depending on network conditions.Sapphire [53] is a cloud-enabled distributed programming platform for mobile and cloud applications.Sapphire makes a smooth application execution using the techniques of codeoffloading, caching, and fault-tolerance.Sapphire lacks in data management services but provides smooth application execution.The work on Pebbles [54] revealed that apps massively depend on structured data (table) to manage unstructured objects (files).Simba [20] extended the table interface of Izzy [43] to provide a unified abstraction for both table and object, the benefits of which are explored the context of local systems in these studies [ [55], [56] ].
CouchDB [57] is a schema-free "document store" supporting eventual consistency and provide "document" sync with coordination from its client TouchDB [58].
SwiftCloud [59] and Cloud types [60] provide cloudenabled programming interface to facilitate the mobile apps for storing local replicas of data on the devices and subsequently sync with the cloud servers.The programmer needs to handle synchronization in SwiftCloud and Cloud types, while Simba permits automatic synchronization.
Mobile operating systems provide some kinds of data storage abstractions to developers.Apple expanded its iCloud [47] service with CloudKit [61], a new means for applications to store and access data stored in iCloud [47].There are some open source mobile back-end-as-a-service offering, such as Parse Server platform [62] and StackSync [51].
Many commercial services provide back-end cloud storage services to link mobile and web applications to the cloud, such as IBM Bluemix Mobile Cloud Service [63] [64].Services of Firebase [65] and Kinvey [66], also aid app developers to connect their apps to cloud backend.

III. DISCUSSION ON LITERATURE OF CONSISTENCY AND SYNCHRONIZATION FRAMEWORKS
The existing literature from the database community and distributed systems community focus on consistency models, their implementations and their measurement.This paper focuses on the reference implementations helping the mobile clients for end-to-end data consistency and data synchronization service utilizing the cloud resources.The literature has case studies investigating the difficulties related to consistent replication across mobile devices with intermittent network connectivity and bandwidth constraints.Some studies in the literature address the frameworks designed to handle the current constraints in Mobile app development.
Coda [3], was one of the initial client-server architecture systems, to emphasize the difficulties in addressing the offline operations.BlueFS [67] is another system that focuses on energy efficiency in resource-constrained mobile devices.Bayou [4] is based on client-server architecture and supports a disconnected system and provides a programming interface to application-specific conflict detection and resolution to handle optimistic updates (eventual consistency).Odyssey [23] support application-aware adaptation based on type-specific operations.The Rover [68] toolkit is a client-server, mobile applications development platform that relocatable dynamic object (RDO) and queued remote procedure call (QRPC) for data communication.
Simba [20] provides end-to-end data consistency framework with a data abstraction for a combination of tabular and object data models.Additionally, the applications written to this abstraction are allowed to select from a set of distributed consistency schemes and sync data with the cloud.Simba Server implementation of data Storage use OpenStack Swift [69] for object data and Cassandra [6] to store tabular data.Simba configure OpenStack Swift and Cassandra to utilize three-way replication, in order to achieve high availability.Also, the framework mentioned in [70] support using Cassandra as a backend datastore.Our work [71] proposes to extend Simba with support for large data objects.
Mobius [44] is designed as a cloud-enabled data replication and messaging platform for the mobile applications.It provides table consistency and uses PNUTS [7] as the back-end store.
A middleware framework for a mobile network that performs reliable and real-time data synchronization is proposed by Xue [72].Izzy [43] and Mobius [44] frameworks provide a platform for structured data like tables only, to expedite the development and deployment of data-centric mobile apps.Simba [20] is built upon the sync framework of Izzy and supports cloud-based data synchronization service, which reduces development complexity of mobile apps.
Cimbiosys [17] is a peer-to-peer system platform (clients share updates directly with each other) that enables various apps to manage cloud-based data on personal computers and mobile devices.Perspective [73] is another platform like Cimbiosys that use filters for selective replication of data on mobile devices.PRACTI [2] is a unique replication system that supports all the three ideal PRACTI properties of partial replication, arbitrary consistency and topology-independence.
Currently, researchers are proposing new principles to deal with weak consistency.Strong correctness guarantees can be achieved without the use of costly global synchronization when all operations in a program are purely monotonic.Built on this monotonic principle, some data structures like sets and sequences can be correctly replicated without the need of synchronization.
The Conflict-Free Replicated Data Types (CRDTs) ( [74] [75] [76]) are asynchronous data types that do not need synchronization for updates.They comply Strong Eventual Consistency Model [75] and can be utilized to build other data models, required by applications.Asynchronous quality of CRDTs makes it more qualified for replication in eventual consistency environments.
More recently researchers utilize these special data types (CRDTs) to build the frameworks using Key-Value stores.Riak [77] distributed database is used as a back-end store by systems like SwiftCloud [59] to implement a Key-CRDT.In order to support strong eventual consistency, the SwiftCloud middleware, convert a Key-Value store in a Key-CRDT store, into a data-model that utilize properties of CRDT.The system allows clients to execute updates concurrently without synchronization.By executing automatic conflict resolution specified in CRDTs, the systems guarantees the clients with zero conflict for simultaneous updates.Walter [8] and Gemini [27] are other systems that use CRDT for providing eventual consistency.Indigo [78] enhance SwiftCloud, wherein an application specifies the invariants, or consistency rules, that the system must maintain.

Consistency As Logical Monotonicity (CALM) is another
technique used in built consistency frameworks.According to the CALM theorem, logically monotonic programs are guaranteed to be eventually consistent without the requirement of any coordination protocols (distributed locks, two-phase commit, paxos, etc.).Hence CALM approach ensures eventual consistency by necessitating a monotonic logic [79].In logic languages (e.g.Bloom [80]) CALM analysis helps to analyze whether the code flow is sufficient towards consistency without the integrating co-ordination protocols [79].
The study claimed [81] that the use of revision diagrams along with special abstract Cloud Types is a useful technique for eventually consistent distributed programs.Revisions diagrams are semi lattices designed for the context of multiple versions and eventual consistency and work same as the version control systems.In this approach, the distributed state is stored using special cloud abstract data types.These Cloud types expose interface with well defines update and query operations [60].Cloud types provide eventually consistent storage and hide the complex backend implementation details of network and coordination protocols.They offer the functionality to perform the optimized fork and join implementations and storing of updates in the form of logs [60].The prototype implementation of this technique is available in TouchDevelop language and as a library in C# [82].While the CRDTs help to carry out only commutative operations, the cloud types support non-commutative operations still accomplishing eventual consistency.
Open Data Kit (ODK) 2.0 [83] support to build Androidbased application-specific information modules for offline operations.StoArranger [84] is another system framework that aid the programmers to manage cloud data storage on mobile devices by addressing issues of rearranging, and coordinating cloud storage communications.BlueMountain [85] is a modern mobile data management platform supporting solutions for file and database management, which allow to achieve wider deployability and help app developers to spend more efforts on app logic.Unidrive [86] is a client-side middleware system which can integrate multi-cloud capabilities to mobile apps.CacheKeeper [87] allows caching of browser data on mobile devices using system-wide, kernel level caching support for mobile applications.
Parse [62] is a back-end as a service platform that uses MongoDB as the back-end datastore.Parse platform allow the developer to create loosely or strongly typed objects and easily save, update, query, and delete these in a backend data store.
Mobile apps are developed using the file sync services of Google Drive [46], iCloud [47], Dropbox [48] [49] and Box Sync [50].StackSync [51] is an open-source Personal Cloud framework that provides scalable file synchronization and sharing.QuickSync [52] is a system that optimizes cloud storage synchronization performance in wireless networks based on network conditions.IBM Bluemix Mobile Cloud Service [63] [64] provides back-end cloud storage services to link mobile and web applications to the cloud.Other commercial platforms such as Kinvey [66] and Firebase [65], help app developers to connect the apps to cloud backend.This section discusses the selected case studies, based on the criteria to understand the different technologies used for building the frameworks.SwiftCloud uses the CRDT with the Riak key store.Mobius uses PNUTS distributed database and supports P2P communication model.Simba supports configuring different consistency levels using Cassandra and OpenStack Swift object storage.TouchDevelop library utilizes the Cloudtypes using the Revision diagrams.BloomL library covers the BloomL language supported framework.Due to space constraints, we are only covering the three frameworks Swiftcloud, Simba and Mobius.These reference solutions are aimed at providing data replication, synchronization, and offline services to ease the development complexity of mobile apps.The solutions use the client side caching technique to offer offline services.The solutions are backed by the cloud storage to store the data.Table III summarizes the strength and weaknesses of the studied three reference implementations.Table IV (See Appendix) summarizes the consistency and data models (table, object or both) support in the various reference implementations.Table IV also lists PRACTI property supported by each framework along with mechanism of synchronization protocol and conflict resolution.

A. Synchronization Services
Some of the solutions provide the sync services for structured data like table only (Mobius and SwiftCloud).Simba supports both tabular and objects data models.Synchronization operation execution required to be handled by the programmers in case of Mobius and Swiftcloud.In contrast, Simba supports automatic synchronization process in the background.

B. Consistency Support
In order to satisfy the diverse consistency needs the frameworks should support different types of data and independently define their consistency.Mobius provides per-record sequential [88] and fork-sequential [45] consistency through the exclusive type of read operations.Simba provides three consistency semantics, resembling strong, causal and eventual consistency.The extent of consistency specification permit may be per-row or per-request, per-table.Caching Policy and Offline support: The strategies of caching (replication) data at the client side enable higher availability and improve latency.Caching policies need to take care of the consistency semantic (ordering, updates and fetching of fresh updates).Solutions provide options to access data from client-side storage or remotely.Cache policies can be determined by the server-side back-end.The server-generated policies can be context-aware, globally configurable and dynamic.These policies are created based on run-time usage or access patterns of all users collected from each application.Efficient write caching capabilities group possible numbers of write operations in a one network message to reduce bandwidth.A Prototype of Mobius clients uses the trained decision tree model (policy selector) to determine whether to fetch locally or remotely.Mobius uses cost-sensitive decision tree classifiers to write batch updates.In SwiftCloud the clients can access the causally-consistent view of the stable version of data (cached at multiple servers).In Mobius, MUD tables are partitioned across mobile nodes and one or more server backends.Data access during offline is from the local tables.The write updates are stored locally and forwarded to the backend on reconciliation of client.During offline, reads are delivered from the local scout in SwiftCloud.Scout cache handles the write updates.On network availability, finally, they will be committed at its DC.

C. Limitations of Reference Frameworks
Even though incredible researches have been done in providing end-to-end data consistency solutions, many challenges still remain.This section points out some of the challenges that are needed to be addressed in various reference frameworks.For app developers, currently, Mobius [44] provide higher level APIs (blocking or asynchronous) abstracted around the basic MUD APIs.The researchers propose the opportunity to support richer interfaces with the declarative query language.Mobius can be improved in the area of cross-app synchronization, optimization strategies and caching.Mobius can be improved in cache operations such as dynamic caching strategies, clearance policies and push-based cache maintenance.For bandwidth consumption and improving access, the outstanding updates stored locally should be compressed.There should be a smooth deterioration of response quality during disconnected operation.For the scalability improvements, the authors of Mobius [44] propose to improve partitioning schemes by adapting their earlier efforts on automatic and fine-grained partitioning ( [89], [90]).Simba's [20] sync protocol does not support streaming APIs to handle big size objects (e.g.Media file like Videos).Simba proposes to handle atomic multi-row transactions as prospective enhancement and currently support only atomic transactions on individual rows.SwiftCloud [59] can be enhanced with a better caching mechanism and support for transaction migration.Also, better data encapsulation across software stack through API level, to address efficient data access.

V. RELATED WORK
The work of [91] conducts an analysis of concepts of mobile client-server computing and mobile data access with a detailed review of early research prototypes (Bayou [4], Odyssey [23] and Rover [68] ) for mobile data management.Our work extends this work by analyzing the consistency support for the latest frameworks.The survey of contributions on data dissemination and support for data consistency techniques for mobiles devices is discussed here [92].The paper [93] compares and analyze the several contributions to models for mobile transaction.A survey of literature work on synchronization between the mobile device and server-side databases can be found here [94].A survey of academic work on mobile/cloud computing can be found here [95].The paper [96] conducts a comprehensive review of the data replication techniques in the cloud environments.Recent review article deals with the comparison of different categories of data synchronization algorithms based on scalability, consistency, accuracy parameters in ubiquitous network [97].

VI. CONCLUSION AND FUTURE WORK
In this paper, we presented a review of data consistency and synchronization frameworks in Mobile Cloud Computing for Mobile Apps.We considered the latest studies done from 2010 to 2017, and the advantages and disadvantages of three reference implementations in the literature have been presented.Then, the approaches to handle consistency support, sync services, conflict handling and offline operations in reference solutions have been discussed.Furthermore, out of the review, several findings and potential future works have been identified.We believe that this is an important research area, that will attract more contributions from the research community.The Conflict free replicated data type, logically monotonic programs (CALM approach) and Revisions diagrams as semi lattices are some of the techniques used in these frameworks.Frameworks make use of the backend stores implemented using these technologies to support the data consistency features.Out of the three frameworks explored, Simba is a superior framework ensuring three types of consistency guarantees (strong, causal and eventual consistency) for both table and objects data models.Simba reduces programmer's efforts as it supports automatic synchronization process in the background.Simba lacks multi-row transactions and streaming APIs to access to large objects.Swiftcloud uses a client-assisted failover solution with CRDT store to support both mergeable and strongly consistent transactions.Programmers need to manage the synchronization process.It utilizes properties of CRDTs to support automatic conflict resolution.SwiftCloud needs to improve in providing efficient data access through APIs.Mobius provides table consistency and uses PNUTS as the back-end store to support cloud-enabled data replication and messaging platform.Mobius provides per-record sequential and fork-sequential consistency through the exclusive type of read operations.Programmers need to manage the synchronization process.Mobius uses cost-sensitive decision tree classifiers to write the batch update.Mobius needs improvements in the area of caching and optimization strategies with richer client interfaces.It has to be noted that the literature review is limited by sources and keywords, terminologies used in the search, and the search date.Hence it is possible to include more relevant papers while replicating this study in the future.Our final outputs of this research are limited to the current availability of frameworks that address the data consistency, synchronization , and other features.While the current study did not deal with the full details of measurements of numerical deviation, order deviation and staleness (latency) of each framework, we intend to conduct detailed research with simulations on the comparison of these performance parameters for each platform.The libraries and backend implement a default mechanism of "client wins", which implies that the data in the backend reflects the last client that performed a write.Custom conflict management policies can be implemented with Business Logic.
Note: See

Firebase
from the storage system and adds a copy of that datum to its local cache, if the cache does not already contain that datum in that exact version (identified by its vector clock).The application must take care of the data violation-handling task by reloading dataOpen Data Kit 2.0 [83] * E T Single database row is the base unit and use a small granularity of change-tracking to enable smaller data transmission.User must resolve the conflict by either taking the server's change, the local change, or mix of the local change and the server change StoArranger [84] E , PR T Delay and batch cloud backup requests from apps to minimize the impact of transmission promotion/tail energy Conflict detection is based on the folder meta data with folder sync APIs.Unidrive [86] S, E, PR O Metadata of content is stored in cloud and synced to all clients using a quorum based distributed locking protocol and chunking technique It support multiple Consumer cloud storage in which synchronization logic is purely implemented at client devices and all communication is conveyed through file upload and download operations QuickSync [52] * E O Sync efficiency is improved by using three key components, the Network-aware Chunker, the Redundancy Eliminator , and the Batched Syncer Do not address consistency or conflict handling but improves Sync efficiency.Parse Server [62] * S, E, PR T The Parse Server SDKs provides a local datastore which can be used to store and retrieve the PFObjects by 'pinning' process Server side conflicts are handled using generic 'beforeSave' function in the cloud.Applications are responsible to handle conflicts.StackSync[51] S, E, PR O Sync protocol is based on RPCs or method calls by ObjectMQ middleware A copy of the conflicted document is created and user needs to decide about thisin the system is a chunk of data with size of up to 4MB.Files larger than that are split into several chunks.Reduces the amount of exchanged data by using delta encoding when transmitting .File meta data has a unique revision identifier used to detect changes and avoid conflicts iCloud with CloudKit[47] S, E O CloudKit APIs support to fetch for only the changes since the last time it updated.iCloudserver returns the error code with objects that contains the different versions of the conflicting record and user can perform whatever resolution logic is needed to resolve the conflict Amazon Dynamo [5] E, PR O Implements an anti-entropy (replica synchronization) protocol and Merkle trees for faster and to minimal the amount of data transfer.It makes use of object versioning and application-assisted conflict resolution Bluemix Mobile Cloud Service [63] E, PR O Applications use Cloudant Sync (an Apache CouchDB TM replication-protocol-compatible) to store, index and query local JSON data on a device It is the application's responsibility to detect the conflicts and resolve them based on conflict details only sync of new and updated entities only.

TABLE I .
LIST OF ACRONYMS.

TABLE III .
COMPARISON OF THREE REFERENCE IMPLEMENTATIONS.

TABLE IV :
Summary of reference designs Table-I for the list of symbols used.