Publication Date: 2018-02-22

Approval Date: 2018-02-21

Posted Date: 2018-01-15

Reference number of this document: OGC 17-026r1

Reference URL for this document:

Category: Public Engineering Report

Editor: Rob Cass

Title: OGC Testbed-13: Disconnected Networks Engineering Report

OGC Engineering Report


Copyright © 2018 Open Geospatial Consortium. To obtain additional rights of use, visit


This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.


Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.


This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.

This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

1. Summary

The design of core OGC Web Services (OWS) does not entertain the possibility of network unavailability, internet unavailability, or disconnected clients and datastores. Deployments of these services, and the clients that consume them, often happen in networking environments that have limited bandwidth, sporadic connectivity and no connection to the internet. This Engineering Report (ER) focuses on situations of Denied, Degraded, Intermittent, or Limited Bandwidth (DDIL). Due to these DDIL networking limitations, OWS services and clients may not be capable of effective data exchange and interpretation due to a reliance on external resources and "always-on" networks.

This ER concerns the behavior of common OWS services when used in DDIL environments. The ER documents proposed practices/considerations for implementation of these services to support these environments. The ER also describes software modules or extensions that might mitigate the effects of these environments on both clients and services.

This ER intends to guide client and service implementation, as well as deployment strategies for these challenging environments.

1.1. Requirements

This ER is required to discuss the implications of operating core OWS services such as Web Coverage Service (WCS), Catalog Service for the Web (CSW), Web Feature Service (WFS), Web Mapping Service (WMS) and Web Map Tile Service (WMTS) on DDIL networks.

1.2. Key Findings and Prior-After Comparison

1.2.1. Prior Work

While not specifically designed with DDIL networks in mind, OGC efforts, in the form of standards and testbed experiments have developed "extensions" for the OGC core services that are arguably useful in a DDIL environment. These are:

  1. Web Processing Service (WPS) Facades

    • These are WPS services that are contacted directly to retrieve and/or perform transactions against OWS services.

  2. Asynchronous processing extensions

    • These extensions extend the functional capabilities of the OWS service to be performed asynchronously.

  3. PubSub Interface

    • Publication/Subscribe interfaces are extended interfaces added to an OWS service. These interfaces conform to the Publish/Subscribe interface standard (OGC 13-131r1). The Publish/Subscribe interface provides a mechanism for nodes to register focused subscriptions for data. These subscriptions can be satisfied immediately or when the nodes resume connectivity.

  4. Compression

    • Compression is useful for data exchange in limited bandwidth environments. Testbed-12 and Testbed-13 produced experiments and engineering reports which assessed compression strategies [3].

  5. GeoSynchronization

    • "A Geosynchronization service, deployed by a data provider, sits between the features a provider offers via a WFS and data collectors. It allows data collectors to submit new data or make modifications to existing features without directly affecting the features in the provider’s data store(s) until validation has been applied thus ensuring that the data published by the provider is of high quality."

    • GeoSync provides a mechanism for nodes in a data-exchange network such as a WFS with clients to "catch-up" with data acquired at any node. GeoSync was implemented for OWS-7 and OWS-8 testbeds. Further work was done in Testbed-13 to update the specification for GeoSync.

1.3. What does this ER mean for the Working Group and OGC in general

The targeted working group for this document is the Architecture Domain Working Group (DWG). This ER can help inform the Architecture DWG as they define improvements for the current OWS framework including how to integrate support for DDIL networks.

1.4. Document contributor contact points

All questions should be directed to the editor or the contributors:

Table 1. Contacts
Contact Organization

Rob Cass

Compusult Ltd.

Charles Heazel


1.5. Future Work

Future work should test:

  • asynchronous communication patterns,

  • message compression,

  • multiple endpoints,

  • quality of service,

  • extending Distributed Computing Platform (DCP) bindings to include non-http endpoints,

  • referenced endpoints, and

  • delta synchronization

  • Operating in simulated DDIL environments to test the application of these concepts in any new versions of OWS Common, with an eye to making these optional extensions to the base implementation.

Future work should not address transport layer issues directly. OWS services should provide adaptations in these extensions to meet the needs of quickly changing networks.

1.6. Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

2. References

3. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.

3.1. Denied, Degraded, Intermittent, or Limited Bandwidth (DDIL) networks

A term describing networking environments that have limited bandwidth, sporadic connectivity and no connection to the internet.

3.2. Asynchronous

Client-server communication in which the desired response is not expected to be received initially from the server, rather a token is provided to request processing status of the main request. A client uses the status to ultimately retrieve the response directly or indirectly from the server.

3.3. Compression

Method to reduce the amount of data required to represent some collection of binary data in a way that the initial representation can be reproduced from the compressed version.

3.4. Endpoint

A source of data or operations that can be accessed via the network or file system using a known protocol.

3.5. PubSub

Pattern of communication where one party publishes a set of continually changing information and another party subscribes to that set or a subset of that information, to be notified of relevant changes.

3.6. Delta

The difference between one set of data and another version of that data.

3.7. Quality Of Service

Measure of the reliability and usability of a networked service.

4. Abbreviated terms

NOTE: The abbreviated terms clause gives a list of the abbreviated terms and the symbols necessary for understanding this document. All symbols should be listed in alphabetical order. Some more frequently used abbreviated terms are provided below as examples.
  • AMQP Advanced Message Queuing Protocol

  • API Application Program Interface

  • COM Component Object Model

  • CORBA Common Object Request Broker Architecture

  • COTS Commercial Off The Shelf

  • CSW Catalog Service for the Web

  • DCE Distributed Computing Environment

  • DCOM Distributed Component Object Model

  • DCP Distributed Computing Platform

  • DDIL Denied, Degraded, Intermittent, Limited

  • DDS Data Distribution Service

  • GSS Geo-Synchronization Service

  • IDL Interface Definition Language

  • OWS Open Web Service

  • WCS Web Coverage Service

  • WFS Web Feature Service

  • WMS Web Map Service

  • WMTS Web Map Tile Service

  • WPS Web Processing Service

  • XMPP The Extensible Messaging and Presence Protocol

5. Overview

This ER consists of the following sections:

  • Requirements: This section details the requirements and objectives of the study and experiment.

  • Use Cases: This section outlines generalized use cases for different DDIL networks concerning network type, types of network variance and service applications within these networks.

  • Considerations: This section describes considerations regarding using OWS services in varying DDIL networks derived from the use cases in the prior section.

  • Solutions: This section describes limitations and strengths of services based on the considerations and service type as well as currently possible and recommended adaptations for OWS services.

6. Requirements

This ER captures the results of the Disconnected Networks study and resulting Change Requests. The ER is required to discuss the implications of operating core OWS services such as WCS, CSW, WFS, WMS and WMTS on DDIL networks.

7. Use Cases

This section describes the implications of operating OWS services in a DDIL environment. While not specific use cases, the following sections provide a discussion of the characteristics of DDIL networks that affect these services.

7.1. Disconnected / Limited Bandwidth

An underlying assumption to Web technologies is the availability of a global, high-bandwidth communications infrastructure such as the Internet. That assumption is not always valid. The tasks described in this section examined ways OGC web services could be adapted for DDIL communications environments.

7.2. Background

The Internet provides a reliable, high-speed, global information exchange service. Most of us take it for granted. Yet the Internet is a complex system. It can and does fail often. Furthermore, it is not truly global. There are communities within 70 miles of Washington D.C. which have little or no access to the Internet. Therefore, the OGC Web Services standards should be extended to address communications environments with the following properties:

  • Secure: The parties can engage in trusted, private information exchanges

  • Disconnected: Network connectivity may be lost.

  • Low Bandwidth: Network throughput may be very low.

  • Segmented: Only a portion of the network may be available. It is no longer global.

  • Unreliable: A large number of the messages may be lost or corrupted.

  • Mobile: At least one party is moving. Network properties will change as the network adapts to the changing locations.

7.2.1. Secure

First and foremost, web services must be secure. They need to be able to identify the requesting party, authenticate that identity, maintain the confidentiality of the exchange, enforce access control for the hosted resources, and provide non-repudiation for the actions taken by a user. The technologies to provide these capabilities are mostly defined in non-OGC standards and technologies. Yet they must be part of a deployed OGC service and must be accommodated by OGC standards.

7.2.2. Disconnected

Devices are not always connected to the network. Yet they are still expected to perform their function. Technical strategies can be developed to deal with disconnected operation. The nature of the strategy depends on the reason the device is disconnected and expected reconnection scenarios. These include:

  • Network connectivity is not available but will be available at a later date

  • Device disconnects to preserve power but will reconnect when “woken up”

  • Mobile device which is temporally out of range of a Point of Presence (POP)

  • Passive device which only connects when interrogated

  • Burst device which only connects at certain times of day for a fixed period

  • Intermittent device which due to poor line quality fades in and out

7.2.3. Low Bandwidth

Internet speeds in excess of 100 Mbps are common. Many Web services are designed for this bandwidth and higher. Yet not all devices have this bandwidth at their disposal. ZigBee, a common IoT protocol, runs at 250 Kbps. Some tactical military networks run at 9,600 bps. Low bandwidth is often the result of limitations in Size Weight and Power (SWAP). These limitations also restrict the options for maximizing bandwidth utilization. Any solution which increases the computational load draws power, which goes against the limited available SWAP. Optimal solutions would maximize bandwidth utilization with little or no increase in SWAP.

7.2.4. Segmented

Web services assume the Internet is globally connected. That is not the case. Many organizations use guards and firewalls to control the information that flows in and out of their Intranet. Resources within the Intranet may not be accessible to users outside of it. Likewise, access to Internet resources may not be allowed from the Intranet. This form of segmentation can be anticipated and planned for. Another form of segmentation is the result of unanticipated events. These can be equipment failure, a denial of service attack, or natural disaster. The result is a communications environment which works fine within a limited geographic or cyber community. But has no access to resources outside of that scope.

7.2.5. Unreliable

Information is exchanged over the Internet using fixed size packets. Great efforts are taken to make sure that all packets are delivered, without error, in the order they are expected. However, at its heart the Internet is just a signal flowing over a cable. Noise, interference, even active jamming can corrupt that signal. Internet protocols correct most of these errors, but messages still get lost. The situation is even worse on DDIL networks. Lower bandwidth, a noisier and more hostile environment, and SWAP limitations preclude many of the error detection and recovery techniques used by the Internet. Communications errors are common. Participants on a DDIL network must be able to perform their own error detection and recovery.

7.2.6. Mobile

Internet protocols are very good at adapting to changes in network topology. That is what allows smart phones to stay connected even when traveling down the highway at 70 mph. However, this adaptability is only made possible through a very complex infrastructure. An infrastructure which doesn’t exist in many parts of the world. Strictly speaking mobility is not a property of DDIL networks. However, the property of mobility has implications for the other properties. For example, Mobile Ad-Hoc Networks (MANETs) are continuously self-configuring, infrastructure-less networks of mobile devices connected using wireless radios. Since they use a peer-to-peer message exchange over a mesh network, there is no requirement for a complex infrastructure. All that is necessary is that one of the nodes on the mesh have access to an outside network. However, they can suffer from high incidents of disconnection, limited bandwidth, and high error rates. They are also by nature segmented networks, self-contained unless one node has a link to the outside world.

7.2.7. Network Topologies

The following set of network topologies provide some insight into the complexity involved in network communications. The Internet uses all of these in one place or another. A DDIL network is most likely going to be a star, point-to-point, or mesh network. When DDIL networks connect to the Internet, they usually use a star configuration. A single node which has connectivity to both the DDIL and Internet serves as a bridge between the two environments.

  • Bus: A network topology which consists of a shared backbone to which all nodes are connected. Communications between nodes are performed over the shared backbone. Since it is a shared resource, this topology requires a low-level protocol to manage access to the backbone.

  • Daisy Chain: A series of point-to-point connections.

  • Hierarchical: This network topology can be visualized as a tree of star networks. The nodes at each level manage the nodes at the next level down.

  • Mesh: Mesh topologies are commonly used for ad-hoc networks. There is no centralized delivery system. When a node wants to send a message, it sends that message to all of its nearest neighbors. The neighbors forward it to their neighbors, and so on until it gets (or doesn’t get) to the intended recipient. This structure makes it easy for nodes to enter and leave the network without disrupting the other nodes.

  • Point-to-Point: A point-to-point network consists of two nodes connected by a channel. All communications between the two nodes take place over that channel. Communication with any other node is not supported.

  • Ring: A ring network is a form of Bus network where the ends of the bus come together to form a ring. This form of network often uses a rotating token to manage access to the backbone.

  • Star: A network topology which consists of one central node supporting multiple satellite nodes. The satellite nodes have a point-to-point relationship with the central node. The central node is responsible for routing messages from the originator to the destination.

7.2.8. DDIL Protocols

The following list provides some of the protocols applicable to the DDIL environment. This is not an exhaustive list, and some of these protocols can be used together. A basic understanding of their operation is useful to gain insight into the behaviors and constraints of the DDIL environment.

  • BlueTooth

  • Advanced Message Queueing Protocol (AMQP)

  • Data Distribution Service (DDS)

  • Message Queue Telemetry Transport (MQTT)

  • The Extensible Messaging and Presence Protocol (XMPP) (AKA Jabber)

  • ZigBee

  • Wi-Fi

  • Win-T

8. Considerations

There are many OWS services and clients operating in DDIL networks. All must be adaptable to a range of considerations. This section discusses some of these considerations and challenges.

8.1. Transport application layers

While not directly affecting the content transmitted, transport application layers may interfere with effective transmission in DDIL environments. Some application layer protocols are more suited to these environments and would be favored in a non OWS client-server relationship. One example of an HTTP alternative is MQTT. Nodes on a properly configured MQTT network can cooperate to deliver information and retain messages. Because the basis for transmission in MQTT application networks is a publish-subscribe model, these networks are also suited for intermittent networks where transmission links are not reliable and asynchronous communication is preferred.

Clients operating in this environment cannot access a typically designed OWS service because the supported application protocol in the OWS specifications is HTTP, or higher level protocols, such as SOAP [OWS]. Clients and servers wishing to use an alternative application protocol would need a method of defining a new DCP format to support MQTT and similar protocols.

8.2. Security requirements

Switching services or data nodes requires consistent security mechanisms to be in place. In many cases new services can step in for a client if another is unavailable. Authenticating against this new service and verifying the validity of this new service requires consistent distribution of authentication and access control directories amongst potential OWS services as well as distributed trust information to verify new services. Additionally, any security mechanism implemented by an OWS service that is part of its advertised capabilities must be consistent across all implementing services.

8.3. Linked data

A best practice is not to use linked data for critical information. Links to information such as XML schemas etc. are less likely to be important than relevant / current information. Critical information should be retrievable from the operating network of the client.

8.4. Structure of Response Data

When networks are unreliable and connectivity is intermittent, it is possible that messages between two nodes can be partially transmitted. In this case, it is ideal to have message formats that while incomplete, can be parsed to recover as much information as possible. Typical document-based OWS request/response formats for operations in CSW and WFS are record-based and streamlike. For raster based services such as WMS and WCS, advertised formats may vary, but these formats are not dictated by the service type.

Additionally, CSW and WFS responses can be paged. This gives the client some measure of control over how much information can be downloaded in a single request/response cycle. Paging is useful when dealing with intermittent networks as it can support retries during synchronous communications with a server. A client can retry pages at a time and slowly build up the full response instead of retrying the full response only to have it always fail due to size and transmission time.

8.5. Compression

Server side compression has been proposed as useful capability to reduce bandwidth demands in low bandwidth networks. Testbed-13 and Testbed-12 both examined the application of various compression techniques such as Apache Avro and Google Protobuf to determine their applicability and the performance impact of compression on data exchange. The results of these experiments are presented in Solutions.

8.6. Traffic Characteristics

Traffic on a network can be bursty, intermittent, consistently low-bandwidth and predictably or un-predictably available. The nature of the network traffic flow can be characterized using Quality of Service (QoS) metrics. If clients are capable of adapting, there should be "hints" about traffic type to help the client make decisions. For example, if a client understood that a WCS provided multiple image formats, some formats would better support an intermittent network connection than others. Streaming image formats such as JPEG 2000 Interactive Protocol (JPIP) might be a better response type than one large GeoTIFF with a multi-resolution pyramid, or vice versa. A server could advertise its current traffic characteristics. Clients could use this information to determine what formats to request and how to request them. As another example, a WFS client might understand that it is reasonable to request a large amount of information from the WFS for purposes of caching, because the bandwidth is available for a quick download, but may not be consistently available.

8.7. Caching

When connectivity and bandwidth are available, clients may need to cache information they are interested in or anticipated being interested in. Clients that require access to constantly changing information will require "shelf-life" attributes for information retrieved from services, observation timestamps and depreciating confidence levels in the information become important. Caching also requires careful strategies for prioritizing information to make best use of available network resources. A client may begin by requesting "summary" data first, as this data is better than none at all, and then more detailed data as best it can. To support this strategy, OWS services would need to provide information at both levels of detail.

8.8. Replication/Synchronization

Similar to caching, replication of data implies that there is a complete copy of server data within an area/time range or topic of interest maintained on the client in similar service. When contact with the upstream/authoritative server is available, the client copy can be updated. When network changes prevent contact, the client can query the local service instead. Replication and caching both require extra storage capacity and this may limit their applicability in some DDIL clients. Just like caching, replication assumes some contact between servers to ensure data is updated to its latest version. Replication was discussed in Testbed-13 using the GSS bulk data transfer protocol. This work is discussed in Solutions.

Synchronization implies 2-way communication of transactional information between client and server. In completely disconnected networks, there must be a physical exchange of information between participating nodes. Clients often perform transactions against the central server data store. If a link is unavailable at the time of the transaction, the client must queue the transactions, and be cognizant of conflicting changes on the server when the link becomes available and the queued transactions are applied to the server.

9. Solutions

Testbed-13, addressed some common DDIL adaptations. In the Cross-Community Interoperability (CCI) thread, work was performed to develop asynchronous services, replication and compression. Additionally, work has begun this year to explore the application of QoS metrics to OWS service capabilities.

9.1. Compression and Serialization

In Testbed-13, Testbed-12 work was extended to explore compression and serialization using Apache Avro and Google Protobuf. The findings from the experiment indicated that compression using known techniques can mitigate the size impact of document-based responses from WFS implementations. In the table below, we can see that the application of zip to compress responses is one of the most efficient and ubiquitous compression techniques available. OWS services that provide text-based document responses would gain from providing compressed output in DDIL environments where bandwidth is poor.

Figure 1. Swap Results Table

9.2. Asynchronous Methods

In Testbed-12 and Testbed-13, work was done to support the use of Asynchronous methods using the "WPS Facade" approach for WFS services. These approaches are significant for the adaptation of OWS services to DDIL environments. They provide a method for a client to register a request for information and be able to retrieve the response for that request out of band. Applicability in DDIL environments is apparent, considering the interrupted network case. A client can register a request for information such as a GetFeature request, register a response handler for the request, get back an acknowledgement from the server, go offline, come back online and use the server acknowledgement to check the status of and retrieve the response. The response could be made available to the client by a response handler via email, download from the server or file system retrieval, or any applicable method that suits the client. Using the WPS approach, a "mode" variable is set to "asynchronous" to trigger the response to provide the information regarding the now registered job. In the experiment, the response handler sent an email to an email address specified by the client.

Currently, there is no universally-defined method for defining asynchronous request handling for all OWS services. WPS and CSW implement asynchronous request processing. The outcome of this experiment was to recommend investigation into extending OWS to support a general method for defining asynchronous processing.

9.3. Publish Subscribe Methods

Asynchronous processing is typically defined as a one-off process to define a single request-response cycle. There are other cases where requests may be long-lived and exist as standing orders. Typically, this would be accomplished with an OWS service by constantly polling a server to detect changes in features that match some attributes of interest for the client. In DDIL environments, this is impossible or challenging. To handle this concept, the OGC has defined a [PubSub] standard, built upon the Web Services Notification model of the Organization for the Advancement of Structured Information Standards (OASIS). Using this model, interested clients register an interest in a topic with the server or a broker that negotiates the protocol with the server. The broker can also intercept changes in the server data that matches this topic and notifies the registered client of the changes. The changes can be in the notification, or the notification can provide information on how to retrieve the data. In Testbed-13, a PubSub experiment was performed using a GeoSynchronization Server (OGC 17-031). In addition to synchronizing feature data, the server would notify interested clients of data changes as they occurred. In Testbed-12, the CSW specification was extended to support the PubSub protocol.

pubsub seq
Figure 2. Abstract Publish Subscribe Sequence

9.4. Synchronization

For Testbed-13, the application of the GeoSynchronization Server was to implement a change review process which included notifications of the changed geographic features. In the diagram below the Subscriber node subscribes to the Replication Feed. The Replication Feed provides the latest changes to the features stored in a remote WFS of interest to the Subscriber, once the changes have been pushed to the WFS by the reviewer. The subscriber registers an interest in replication events so that it receives only the latest changes as they occur.

A replication event signals that, as a result of a proposed change, a change has been made to a data provider’s data store and describes what that change is. Interested parties can then retrieve the description of the change and apply that change to their local copy of the data thus synchronizing their data store with the data provider’s data store.(OGC 17-031)

Subscribers use the publication mechanism to register for publication events like the replication event. Filter criteria, such as geographic area, constrain the publication of events to those features that conform to the specified filter.

In DDIL networks, this form of replication registration is useful when clients will be predominantly offline, offering a method to "catch-up" on feature changes when online, without replicating the entire contents of the WFS.

Figure 3. GSS Experiment

9.5. Quality of Service Extensions

Since 2016, effort to develop an extension to OWS Capabilities responses that include QoS metrics has begun. Members of the OGC Quality of Service and Experience DWG have begun defining XML Schema Documents (XSD) to describe concepts such as Operational Status, Operation Anomaly, Quality of Service metrics etc. Using these new concepts, servers can advertise specific constraints on their service quality. Clients extending OWS to include these concepts will be able to react to advertised availability constraints that describe when a network is available, how much bandwidth is available and how reliable the network is. A client can develop strategies for dealing with advertised issues such as using small page sizes for results if a network is unreliable, or requesting smaller image formats from servers on low-bandwidth networks.

9.6. Caching and Local Data Stores

Many data stores that back services such as WFS, WCS, WMS and WMTS can be broken-down into subsets and stored in a portable stand-alone database format known as GeoPackage (OGC 12-128r14). GeoPackage is an OGC standard with extensions that supports the commonly used data formats provided by these services.

GeoPackage can store vector feature information in a manner similar to simple-features. Additionally, GeoPackage can store raster map data and imagery in a tile matrix pyramid similar to WMTS, this data can be used to compose map images at arbitrary scale to support WMS GetMap requests.

GeoPackage has a proven extension system that can be used to store additional information to help disconnected systems symbolize the stored vector data. Additionally, a new tiled gridded coverage extension has also been developed that can be used to provide coverage information such as elevation that would typically be served by a WCS (OGC 17-066r1).

Appendix A: Change Requests

Add a clause to the OWS common specification describing a light weight asynchronous processing protocol

Appendix B: Revision History

Table 2. Revision History
Date Release Editor Primary clauses modified Descriptions

May 31, 2017

R. Cass



initial version

September 7, 2017

R. Cass


summary, references, terms, use cases

Integrated C. Heazel’s content

January 15, 2018

G. Hobona



Cleanup for pending review

Appendix C: Bibliography

[1] Vretanos, P. : OGC® Testbed-12 Web Feature Service Synchronization Engineering Report OGC 16-044, (2017)

[2] Pross,B. : Testbed-12 Low Bandwidth & Generalization Engineering Report, (2017)

[3] Harrison, J. : Testbed-12 Compression Techniques Engineering Report, (2017)

[4] Lindquister, J. : Improving the performance of Web Services in Disconnected, Intermittent and Limited Environments, (2016)

[5] Lapic. S. : Maritime Operations in Disconnected, Intermittent, and Low-Bandwidth Environments, (2013)

[8] Data Distribution Service (DDS), (2017)

[9] Message Queue Telemetry Transport (MQTT), (2017)

[10] The Extensible Messaging and Presence Protocol (XMPP) (AKA Jabber), (2017)

[11] ZIGBEE, (2017)

[12] Wi-Fi, (2017)

[13] Win-T, (2017)

[14] Pross,B.,Stasch, C. : OGC 17-028r1, OGC® Testbed-13: Asynchronous Services Engineering Report, (2018)