A Survivable Social Network

The impact that widespread disasters have on communications systems has evolved over time - fueled by advancements in technology and cemented by societal adoption. As the use of IP-based communications systems, both wired and wireless, has become ubiquitous, we as a society have become dangerously dependent. We vest our banking and healthcare records in cloud-based services, and we have systematically shifted our preferred ways of staying in touch with friends and family away from voice communications toward online social networks. Outages of these systems that occur as a consequence of man-made or natural disasters leave us in communications darkness and without the local means to reconstruct our communications tools. In this paper, we propose a Survivable Social Network (SSN) that seeks to put the means of rebuilding familiar-feeling, modern communications tools into the hands of members of neighborhoods, schools, organizations and communities and demonstrate how such a system can be architected and replicated.


I. INTRODUCTION
As a direct consequence of the Loma Prieta earthquake in 1989, 154 of 160 telephone central offices in Northern California lost primary power, and some of these also lost backup power [1].Even so, the robustness of the phone system in those days (not long after the breakup of AT&T) was in evidence.With loss of primary power, the system still functioned, at least within communities.So-called "plain old telephone service" (POTS) was engineered for robustness, and local phone service survived in no small measure due to the fact that dependence on power was limited.Even with the advent of cordless phones, most people still had a "basic" phone, powered by the central office.Each central office was designed and built as a bunker and equipped with battery and/or generator-based autonomous power.
Long-distance traffic into and out of the area was impacted, but relief agencies, amateur radio operators, and others were able to quickly establish alternative communications systems using narrowband voice radios to get messages in and out.It is fair to say that the communications expectations of the impacted area were largely met with the engineered robustness of the communications infrastructure -if not by the primary network, then by suitable, widespread alternatives.
If we were to have a repeat of the Loma Prieta earthquake today, the situation might play out differently.Since 1989, the rise of the internet, online banking, e-commerce, social media, a variety of cloud services and, notably, the shift to mobile telephony have changed society's expectations of their communications infrastructure significantly.But has robustness kept pace?We argue that the complexity and nature of this new infrastructure render it inherently less robust than centraloffice-based POTS.Cell sites are constructed with limited backup power, and in the event of a widespread disaster, the possibility of reaching these sites to fuel backup generators is limited 1 .Wireless technologies themselves have unique vulnerabilities.Cellular signaling is particularly prone to overloading.Consumer-grade internet services are not engineered to pre-divestiture AT&T standards.
Consequently, we have a problem in the form of rising expectations and falling robustness.While first responders, relief agencies and other professionals might maintain their own autonomous communications systems, the broader community's expectations for communications won't be met by emergency narrowband voice equipment as they were in 1989.
While full restoration of internet access will be important, it stands to reason that restoring communication infrastructure within an impacted community 2 using familiar-feeling communications tools will be among its top priorities in a disaster.Consistent with the local primacy core principle of FEMA's National Disaster Recovery Framework [3], we believe that a critical element of resilience is the ability for a community to quickly, simply and cheaply re-establish its own local communications.Ensuring reliable communications within a community allows better self-organization and management of local resources.When communities increase their ability to provide self-service, they reduce the load on oversubscribed relief agencies.
In this paper, we present the principles for and the design of a Survivable Social Network (SSN).The SSN is a systems architecture that builds on existing technologies, integrating them so as to deliver resilient communications means that meet societal expectations for communities.In Section II, we examine the problem domain more fully.Section III, we look at relevant prior work.Section IV explores the technical and practical requirements for possible solutions and presents our proposal for an SSN systems architecture.Section V presents the details of our initial implementation and early evaluation.Section VI summarizes the lessons learned and outlines future work.

II. PROBLEM DOMAIN
In this paper, we use the term disaster to refer to a natural or man-made event that results in significant negative impact to life, property, and/or the environment on a large scale.Specifically, we concern ourselves with such events that directly or indirectly impact communications infrastructure and, as a consequence, the ability of the impacted community to respond and recover.Disasters often create unique communications challenges.The event itself can cause damage to the communications infrastructure, and even if not, the usage of the infrastructure changes as a result of the event.An important dynamic in understanding the degree to which communications infrastructure will be resilient in the face of a disaster is strongly related to societal norms tied to these communications systems.Growing capabilities leads to rising expectations.We now consider the evolution of these factors over the last 40 years in the United States, with the understanding that this history is an exemplar of similar transformations elsewhere.

A. When Voice was the Killer App
The establishment and widespread public use of POTS, at least in the United States, was essentially complete by the 1970's.Switchboards were gone.Party lines had all but disappeared in most areas of the country.Costs were such that most every person could use, if not own, a phone.Pay phones were available widely.The so-called North American Numbering Plan and direct distance dialing made it possible for anyone to talk to anyone, anytime.Toll-free numbers invited customers to shop-by-phone and bank-by-phone.The infrastructure upon which this was built was solid.The Bell System was so meticulously designed and maintained that there was a procedure for everything -right down to the correct way to sweep the floors in a central office [4].Generally speaking, expectations for good voice services were met.The infrastructure demonstrated its robustness in numerous situations, and the ability of the Bell System to rapidly respond to large-scale telecommunications disasters [5] was notable.
During this same time, society witnessed the growth of an alternative communications network-based on amateur radiothat could (and still does) offer infrastructure-less, instantaneously provisioned, grass-roots re-establishment of vital voice communications, as is said, when all else fails [6].The widespread availability of economically-priced narrowband FM radios, alone or coupled with battery-backed hilltop repeaters and longer-distance HF radios, provided the technical underpinnings.The dedication of hundreds of thousands (in the USA) to millions (worldwide) of amateur radio operators and their own personal investments in equipment and training provided the perfect back-stop to the commercial voice network in times of disaster.Arguably, the ability to meet a community's communications expectations during a disaster was at an all-time high.

B. Expectations Shift
But then two significant things happened: the divestiture of AT&T and the re-architecting of public telecommunications systems away from circuit-switching to packet-switching.Divestiture brought much-needed competition to telecommunications in the United States, but the role of Bell Labs and others to maintain the highest engineering standards for the network had been effectively abolished.Competition naturally brought about different grades of service and, not surprisingly, different levels of network robustness.The changes from circuit-switched copper to packet-switched communications, particularly wireless communications, were also profound.In today's world of stuttery, voice-over-IP, dropped-call frustrations, it may be hard to recall that there was a time when voice calling was a pleasant experience.But the fact that we tolerate poor voice call quality today hints that voice is no longer the killer app.Our attention has shifted to a different form of communication: web services, increasingly delivered wirelessly to us via smartphones, where the statistical nature of mostly reliable connections are masked by the nature of the application.We don't, for instance, even notice when we receive a social network update on our smartphone that the network might have engaged in multiple re-transmissions to get it to us.We have agreed with our service providers that the underlying network only really needs to be best efforts.Instead of voice being the killer app, we've shifted to email and social networking.The same organizations that encouraged us to engage with them via toll-free numbers are now trying to reduce call center costs and would prefer that we do our banking and manage our healthcare records via web portals.Our expectations have changed qualitatively.
These transformations have an even darker side.They tacitly permit network design flexibility up to and beyond the point where networks can and will fail in ways that can leave significant areas without the expected communications services for days or weeks in a disaster [14].Network robustness has dropped.
And what about the back-stop?Wireless spectrum allocations being what they are, amateur radio today has to make do with limited high-frequency (HF) and very-high-frequency (VHF) primary allocations and ultra-high-frequency (UHF) secondary allocations [7].Available amateur radio spectrum in the lower bands does not support ubiquitous broadband data exchange.There are a number of amateur radio initiatives to provide broadband services in WiFi spectrum, and these will prove to be profoundly important as we discuss below.But the instances of such networks are not nearly as widespread as the narrowband FM radios of the past era.
With the uptick in expectations and the fall-off in robustness, our ability to meet a community's communications expectations during a disaster is markedly lower than it was 40 years ago.

C. Validation of the Shift
As an illustration of the present-day situation, we take as an example the 2011 Great East Japan Earthquake.During and after the event, social network transactions jumped dramatically [8].Twitter traffic analysis showed a rapid increase in both heavily-and lightly-damaged areas.We view this as evidence that modern communications tools, and, in particular, social networking tools accessed via smartphones, are accepted, and even valued, as a communications medium in disaster situations [9].Brief text message exchanges combined, selectively, with images over a broadcast (or at least multicast) delivery mechanism are well matched to the situation.In addition to one-to-many communication, it was also observed that individuals in the impacted areas relied on directed message-response modalities more so than those outside of the immediate area [10].
Regarding robustness, NTT DoCoMo reported that, on the day following the earthquake, direct damage from the disaster forced 4900 base stations out of service due to disruption of transmission lines or drained batteries [11].
Similarly, in 2012, smartphone-based social media communications played a key role in New York City's response to Hurricane Sandy, providing real-time information about events as they occurred.Over 4 million messages carried the #Sandy hashtag [12].Twitter relayed safety information and advice from a range of official accounts, including @nycgov, @nycmayorsoffice and @fdny [13].Instagram reported upload rates of 10 images per second, and thousands of videos were shared on YouTube.At the same time, Google established a crisis map to track the impact of the storm and provide practical information on shelters and other resources.
As in Japan, network vulnerabilities were in evidence [14], depriving some community members in the impacted area of access to the information and services that they had come to trust and expect.

D. Problem Summary
In order to meet the communications needs of society today, we seek a solution with the following properties: • Built on its own IP infrastructure: Given observed vulnerabilities of IP infrastructure, a suitable back-stop would offer its own IP infrastructure without dependencies on existing networks.• Operates on alternative power: Given the impact of extended power outages on communications infrastructure, particular attention needs to be paid to every aspect of the solution to assure that its power requirements are minimal and its ability to be powered by batteries, solar, or other local means is met.

III. PRIOR WORK
Since 9/11, significant attention has been focused on the problem of making communications tools (beginning with voice) between emergency response agencies interoperable [15].Because such systems are based on non-public frequency allocations and are delivered as custom-built, ruggedized (and expensive) equipment designed for the rigors of daily field use, they are not readily adapted to meeting the needs of the general population.
Hastily-formed networks (a term attributed to the U.S. Naval Postgraduate School) have been developed, deployed, evaluated and surveyed [19].This body of work encompasses a wide range of topics from physical-layer network re-establishment up to support for a variety of emergency-relevant services such as email, voice, mapping and command/control.The initial focus has been on the support of agency communications.
Amateur radio operators are exploring high-power WiFi networks situated in view of large areas with the intent of providing survivable broadband communications (e.g., the Santa Clara Emergency Wireless Network-SCEWN [16]), but such installations are not widespread.
Dueker has outlined the principles of an IP-based Community Disaster Network that provides the motivation and framework for a resilient, IP-based infrastructure suitable for community and agency communications [17], and an ongoing effort known as the Silicon Valley Resilient Network seeks to establish a testbed.
Mesh networking technologies including IEEE 802.11s [18] are well suited for building emergency IP infrastructures.We will revisit this topic below.
Smartphones and their relevance in emergency preparedness and response have been studied.Citizen 911 [20] provides the means to collect field data using smartphones and to aggregate it via live networks or "sneaker net" so as to provide emergency responders with accurate situational awareness information.Recognizing the impact of loss-of-infrastructure, Citizen 911 uses pre-cached maps on smartphones as well as smartphone-to-smartphone communication at handoff points for data collection.Lee et.al. [21] explore smartphones as a lights-on disaster information dissemination mechanism.
Social media and their emergence as a communications modality for safety, security, and emergency response are in evidence in apps such as Nextdoor [22].The combination of smartphones and social networking is especially powerful for building community-level, neighbor-helping-neighbor tools.Disaster management organizations have come to understand the value of social media and are actively exploring their use [23].Below, we extend this concept to lights-out operation.
The social dynamics of group formation, trust, and political economies [24] are also relevant.In the scope of our work, we believe the dynamics of the pre-existing served communities will strongly shape behavior in the short term during disaster response.As our work and that of others provide new communication capabilities, it remains to be seen how these will be adopted and utilized in actual disaster situations.

IV. APPROACH
To meet the requirements set out in Section II-D , we propose the creation of a "Survivable Social Network" (SSN)a system aimed primarily at providing resilient (lights-out) in-group communication to communities-consistent with a modern, lights-on standard of community communication.
To achieve survivability and familiar feel, the SSN is designed as a stand-alone social networking engine that runs on a commercial, off-the-shelf (COTS) laptop computer.Subscribers connect to this service over WiFi or other networks (discussed below) and, via HTML5 browsers on their smartphones, experience an interface that looks and acts like a cloud-based social network.The SSN system is designed to be easily installed, self-maintaining, and usable with little to no training.It can serve in stand-alone mode (e.g., a neighborhood), in peer-to-peer mode (meshed with other neighborhoods) or in regional mode (interconnected with local authorities to integrate data collection and broad information dissemination).
In addition to social networking functionality, this same platform can be used to enable a wide variety of IP-based services including voice-over-IP (VoIP) communication.With the addition of one or more consumer-grade satellite links, limited IP connectivity from a disaster-impacted community to the internet can be enabled in any of the three modes, offering vital access to medical, financial and other records to community members.
We consider the SSN from three points of view-deployment, usage, and implementation.

A. Deployment
SSN is designed to serve existing communities (neighborhoods, schools, companies) where social connections are already in place and where there is a common felt need for enhancing emergency preparedness.We focus here on enabling and enhancing the communications where this felt need is already in place.
To enable a community to participate in the SSN, it needs an SSN node and a sponsor.The sponsor serves as the organizer for SSN usage in his or her community and is responsible for establishing the node.This is done by downloading the core SSN software onto a suitable computer (e.g., a laptop), registering the computer as an SSN node, and setting up a suitable wireless network (discussed below).As part of the registration process, a web page (landing page) is created on one or several of the popular social networks.The page represents the community served by the node.The sponsor invites members of his or her community (subscribers) to register on the landing page.When they do, basic opt-in information such as their names, phone numbers, in-community friends, and other data are cached on the SSN node.
During lights-on operation, SSN software updates are automatically pushed to the nodes, and changes to the subscribers' basic information are automatically revised in the nodes' caches.Note that this design is robust.A hardware failure is remedied during lights-on by enabling a substitute computer to serve as the node-software updates and cache data are automatically retrieved from the cloud, avoiding painstaking backup and recovery procedures on the part of the sponsor.Lights-out resilience can be enhanced by having a duplicate node in a hot-standby configuration.

B. Usage
SSN functionality gives subscribers the ability to update their status information (Figure 1), post and exchange messages, post annotated photos, access static content (e.g., maps of the community, lists of local resources, Community Emergency Response Team (CERT) refresher videos), and match in-community needs with in-community resources 3 .With the SSN's VoIP capability 4 , subscribers will be able to talk to one another using their existing contact directory information and numbers-functionality that is enabled by the subscriber registration process.
Subscribers can use the node during lights-on or lights-out with continuity.Information they enter will be uploaded to the social networking platform when connectivity is available.Because the cache is kept updated, when a disaster strikes, subscribers can simply continue use of the SSN without disruption and with all of the links and data that was cached.
Using a social networking metaphor has specific advantages for lights-out operation.First, it permits asynchronous operation.Unlike narrowband FM handheld radios that must be powered and monitored at all times, the SSN can be accessed whenever a subscriber has time (and battery power).Messages are persistent, and message history is readily available.Second, it permits both a timeline-view of messages as well as the possibility of text-based searches, making transactions efficient and energy-conserving.Third, it provides a natural metaphor for agency message broadcasts and also offers some basic means for message authentication.Additionally, and as illustrated above, by using geolocation services that are available in many HTML5 browsers, subscribers can opt-in to location tracking.Combined with two-tap status reporting (e.g., "I'm OK" or "Emergency"), the node has the potential to offer first responders a powerful tool that will assist in community situational awareness.
The SSN is designed to provide an intuitive interface for a broad class of subscribers.While it is essentially impossible to create a user interface that is readily used by anyone and everyone without training, we have selected presentations of information and input modalities that are familiar-feeling to those who are comfortable using social networking sites.While this won't cover the entire population, it does cover a large and growing segment.

C. Implementation 1) Services:
The SSN node is built on a Linux system running a virtualization package5 (refer to Figure 2).The base Linux system provides core IP services to the wireless clients (subscribers on smartphones).On this platform, two virtual machines run: the social networking engine (SNE) that implements the core SSN functionality and a VoIP exchange to facilitate SIP-based telephony 6 .
The SNE was built using the Elgg framework, a free, opensource package that enables rapid design and deployment of custom social networking web applications [27].Starting with an initial concept based on interviews with emergency first responders, we created a functional prototype that supported user authentication / login, text messaging, image sharing, and status reporting.These functions were delivered as a set of HTML5 web pages, giving the appearance of a native app but without the need for app installation and updating.As a prototyping environment, Elgg allowed us to get a working version running in a matter of weeks, but as we discuss below, customizing the app in ways that strayed from core assumptions of the Elgg framework and database schema was challenging.
As said, the intended client is any WiFi-enabled smartphone with an HTML5-based web browser.We selected smartphones because of their ubiquity.For any lights-out client, power is an issue.Current smartphones have reasonably long battery life, and we assume that subscribers will be able to recharge their smartphones using car adapters, via small solar panels (assuming sunshine), or at facilities that may be set up in a disaster situation for device recharging [28].As mentioned, an important power-conserving property of the SSN system is that subscribers can turn their phones off when not communicating without risk of losing messages.
We are further exploring power issues related to the node itself.A laptop running several virtual machines provides a convenient development environment and a reasonably lowcost deployment platform.But further power savings are possible by running the core SSN services on small singleboard computers.This is a matter of ongoing study for us.
To make wide deployment of the SSN software practical, we have begun the design of self-updating strategies.For the sake of our initial testing, we have implemented updates via a scripted "virtual machine image push" technique, but more bandwidth-conserving techniques will be explored in the future.
2) User Enrollment: To facilitate ease of user enrollment, we designed and built an interface to Facebook whereby potential subscribers can create accounts on a node.By taking advantage of the published Facebook API, we were able to make the barrier for enrollment low.Facebook integration also allows maintenance of up-to-date subscriber information on the node via periodic synchronization.
3) IP Infrastructure: Logically, because SSN functionality builds on a presumed IP network, a variety of network designs are possible.In this section, we consider some of the available approaches and identify design challenges.
In stand-alone, lights-out mode, IP connectivity is needed only between the node and the smartphones in a community.WiFi technology is suitable for hot-spot type service where complete coverage of a large area is not expectedavailability at some designated locations is sufficient.Under this assumption, an SSN node could be set up at a school, shelter, or even at a neighbor's house, needing nothing more than a single, COTS WiFi access point to provide connectivity.Since the network is stand-alone, the setup is simple.The node itself can provide address assignment (via dynamic host configuration protocol-DHCP) and name resolution (via domain name service-DNS) With the node and smartphones in range of the access point, the only physical connection needed to the access point is for power.Some commercial access points operate at 12V DC and, as such, can be powered from a car or a car battery in a lights-out situation.Recharging from solar panels may be feasible depending on local conditions.Additional coverage for a single node is possible using various COTS WiFi range-extending devices such as WiFi repeaters.
In peer-to-peer mode, communities can be linked with pointto-point wireless devices (including low-cost WiFi access points).Wireless mesh networking (e.g., 802.11s [18]) enables this at the link layer.Routing-layer approaches are also possible.So-called Wireless Internet Service Providers (WISPs) have spurred the development of suitable hardware that allows larger wireless networks to be built quickly and inexpensively.Such networks can also provide connection to city emergency operations centers.In principle, such interconnections can extend the reach of SSN to the regional level.
WiFi networks benefit from line-of-sight operation.In many realistic settings, this would require location of the access point on a high building, a tower, or a mountaintop.In the spirit of rapid deployment in a disaster situation, we have contemplated the use of tethered unmanned aerial vehicles (e.g., GPS-stabilized quadrotor helicopters) carrying an access point as a payload.Tethering offers a measure of physical control as well as a ground-based source of power.
It should be noted that the interconnection of IP networks initially designed to operate stand-alone is not straightforward.As has been observed in interoperability exercises between Mobile EOCs at Carnegie Mellon University's Disaster Management Initiative workshops, interconnection without preplanning for it results in conflicting DHCP servers, lack of common DNS services, and IP routing issues.While it is beyond the scope of this paper, an important consideration in designing SSN nodes to permit peer-to-peer and regional operation is the matter of re-creating the attributes of the internet (including non-conflicting addressing, global routing, and name resolution mechanisms) when there is no internet.
Apart from WiFi, another possibility is the use of substitute cellular connectivity.As has been demonstrated at Burning Man [29], open source software (Range Networks' OpenBTS [30]) and hardware supporting software-defined radio (National Instruments' USRP) can be used to create GSM base stations.Coupled with SIP servers such as FreeSWITCH, cellular telephone networks for voice and SMS traffic can be created locally when commercial cellular infrastructure is not available.This has the advantages of (a) using some functionality of phones (e.g., built-in voice calling) that is not available with WiFi as the wireless bearer and (b) the possibility of operating at lower frequencies with better propagation characteristics.The enthusiastic reader is cautioned that this direction involves a complex set of issues related to regulatory compliance and, possibly, intellectual property licensing.
Orthogonal to all of the above, integration of consumergrade or better IP satellite connectivity into an SSN network is feasible and has been demonstrated.The challenge in exposing this capability in an IP network during a disaster is managing allocation of limited bandwidth across a potentially large population.

V. EVALUATION
To evaluate these ideas, we developed a functional prototype of the SSN and demonstrated it under simulated lights-out conditions on a variety of network configurations.The test scenarios included fully stand-alone operation as well as full regional-scale operation involving a CERT situational awareness display and the Palo Alto Mobile Emergency Operations Center.To enable this, we designed an extension to the SNE that integrated an external event-logging database as an SSN network peer, and we created tools to present selective events from this database on a CERT situation map.Inspired by Semantic Geotagging [31], we provided the means for CERT team members to engage SSN subscribers in multiturn text-and-image discussions of scripted disaster events.CERT team members had the further capability to escalate issues they considered important enough to the city level with corresponding real-time presentation of the conversation in the mobile EOC.This exercise, and the imposed need to keep communications concise (and, for the purposes of limiting escalations, well vetted), drove the evolution of SSN functionality and user interface.
Showcasing of SSN at the City of Palo Alto's Quakeville exercise (September, 2012) and CMU Silicon Valley's Disaster Management Initiative Workshop (November, 2012) yielded positive feedback on the principles of installation-less subscriber registration and minimalist functionality.Feedback on the concept of sharing photos was, interestingly, mixed.While there was no debate that photo-sharing fits the social networking metaphor, concern was expressed about cost (in terms of bandwidth and power) vs. value in a lights-out setting.As it related to our integration exercise with the City of Palo Alto, comments we received indicated that summary text information was, in most cases, preferred over photos.
Initial testing indicated that creating a consistent user experience across a range of devices using HTML5 is more challenging than we had initially thought.On balance, avoiding the complexities of writing, maintaining and installing native apps by using HTML5 still appears to have been the right choice.But we found that many of our attempts to make the user interface more powerful or visually appealing ran up against browser-to-browser inconsistencies.We evolved toward a simpler, less bug-prone UI design.

VI. CONCLUSION
We have outlined the concept of a Survivable Social Network that seeks to provide a robust communications tool for communities and that is consistent with current-day expectations.We've built prototypes to test and verify some of our design assumptions.Experiments with the first prototype demonstrated the need for flexibility beyond the Elgg framework.A complete overhaul of the SNE was recently completed.At present, the SNE is robust, voice networking is functional, and integration with Facebook, while basic, is stable.The user interface supports both lights-on and lights-out sign-in, two-tap status updates, message posting, status display of community members, profile displays, affiliations (e.g., for identifying representatives of the city who are authorized to send updates on behalf of the city), and basic search tools.Further functionality and user interface improvements to the SNE will be based on additional field testing.
Improving the networking component of the SSN is essential in simplifying deployment and extending the reach of stand-alone nodes within a community.We are actively exploring the use of cellular communication as discussed above as well as more sophisticated approaches to WiFi deployment and antenna configurations.
As a result of creating the event-logging capability, it was recognized that machine learning techniques could be applied to discover patterns in the chat traffic on an SSN node or across multiple nodes.Such analysis might be useful for both early identification of common problems or geo-tracking of issues that, by their nature, tend to spread over space and time.This is an area for future exploration.
Our work in understanding and minimizing node power is ongoing with the ultimate goal of creating an SSN node with substantially lower power requirements.

Fig. 1 .
Fig. 1.A subset of the SSN user interface used for quick status reporting.Left: tap-to-report.Such reports are geo-tagged and are available for situational awareness mapping.Right: status summary on the mobile client.

Fig. 2 .
Fig.2.An SSN instance in stand-alone mode.The SSN node provides core IP services and runs two virtual machines: the SNE and the telephone voice switch (PBX).The node and subscribers connect via WiFi.The node maintains a lights-on connection to cloud services for software updates and for synchronization of subscriber data.