![Industry Context - Tactical Edge Operation
Tactical Edge Operation (e.g., Emergency response missions) take place in a
tactical edge environment [1]
• Limited Attention
• High-stress Situation
• Dynamic and Uncertain
• “DDIL networking environment”: limited bandwidth, sporadic connectivity and no
connection to the internet [2]
• Limited computing resources due to size, weight, and power (SWAP) limitations
Example: Coastal Search and Rescue Operations
[1] N. Suri, “Dynamic service-oriented architectures for tactical edge networks,” in Proceedings of the 4th Workshop on Emerging Web Services Technology, Nov. 2009. doi: 10.1145/1645406.1645408.
[2] OGC Testbed-13: Disconnected Networks Engineering Report: https://docs.ogc.org/per/17-026r1.html#_denied_degraded_intermittent_or_limited_bandwidth_ddil_networks](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
Similar to An Experience Report on the Design and Implementation of an Ad-hoc Blockchain Platform for Tactical Edge Applications
Similar to An Experience Report on the Design and Implementation of an Ad-hoc Blockchain Platform for Tactical Edge Applications (20)
More from CREST @ University of Adelaide
More from CREST @ University of Adelaide (20)
Recently uploaded
Recently uploaded (20)
An Experience Report on the Design and Implementation of an Ad-hoc Blockchain Platform for Tactical Edge Applications
- 1. An Experience Report on the Design and Implementation of an Ad-hoc Blockchain Platform for Tactical Edge Applications Nguyen Khoi Tran, M. Ali Babar The University of Adelaide, Adelaide SA 5005, Australia Julian Thorpe, Seth Leslie, and Andrew Walters ECSA 2023 Yeditepe University, Istanbul, Turkey
- 2. Industry Context - Tactical Edge Operation Tactical Edge Operation (e.g., Emergency response missions) take place in a tactical edge environment [1] • Limited Attention • High-stress Situation • Dynamic and Uncertain • “DDIL networking environment”: limited bandwidth, sporadic connectivity and no connection to the internet [2] • Limited computing resources due to size, weight, and power (SWAP) limitations Example: Coastal Search and Rescue Operations [1] N. Suri, “Dynamic service-oriented architectures for tactical edge networks,” in Proceedings of the 4th Workshop on Emerging Web Services Technology, Nov. 2009. doi: 10.1145/1645406.1645408. [2] OGC Testbed-13: Disconnected Networks Engineering Report: https://docs.ogc.org/per/17-026r1.html#_denied_degraded_intermittent_or_limited_bandwidth_ddil_networks
- 3. Industry Context - Tactical Edge Information The mission’s success relies on the access, process, and exchange tactical information in a timely and secure manner [3,4,5] Tactical edge infrastructure is increasingly utilized for information access, processing, and exchange [1] Dismounted System Dismounted System Dismounted System Mobile Center • Data Aggregation & Caching • Data Processing and Edge AI • Command and Control • Situational Awareness (GIS) • VPN Server Fixed Center • Big Data data storage • Batch processing • Stream processing • Command and Control • Situational Awareness (GIS) • VPN T A C T I C A L E D G E Wireless Ad-Hoc Network (e.g., WiFi over batman-adv) Task Group 1 TCP/IP (Over cable, cellular, etc.) Exemplary tactical edge infrastructure of one task group [3] Dandashi, F., Higginson, J., Hughes, J., Narvaez, W., Sabbouh, M., Semy, S., Yost, B.: Tactical edge characterization framework, volume 1: Common vocabulary for tactical environments. Tech. rep. (2007) [4] Walters, A., Anderson, R., Boan, J., Consoli, A., Coombs, M., Iannos, A., Knight, D., Pink, M., Priest, J., Priest, T., Smith, A., Tobin, B., Williamson, S., Lauren- son, B.: Conducting information superiority research in an unclassified surrogate defence environment. Tech. rep. (Sep 2018) [5] Walters, A., Bou, S., Consoli, A., Priest, T., Davidson, R., Priest, J., Williamson, S.: Building trusted reference information at the tactical edge. Tech. rep. (20
- 4. Challenges – Multi-Task-Group Collaboration The tactical edge environment of a military or emergency response mission contains various task groups from different organisations. Dismounted System Dismounted System Dismounted System Dismounted System Dismounted System Dismounted System Mobile Center • Data Aggregation & Caching • Data Processing and Edge AI • Command and Control • Situational Awareness (GIS) • VPN Server Fixed Center • Big Data data storage • Batch processing • Stream processing • Command and Control • Situational Awareness (GIS) • VPN T A C T I C A L E D G E Wireless Ad-Hoc Network (e.g., WiFi over batman-adv) Wireless LAN (e.g., WiFi hot spot) Task Group 1 Task Group 2 TCP/IP (Over cable, cellular, etc.) Cellular Mobile Center • Data Aggregation & Caching • Data Processing and Edge AI • Command and Control • Situational Awareness (GIS) • VPN Server Fixed Center • Big Data data storage • Batch processing • Stream processing • Command and Control • Situational Awareness (GIS) • VPN TCP/IP (Over cable, cellular, etc.) C E N T R A L I S E D I N F O R M A T I O N P L A N E ( P U B L I C , H Y B R I D , O R F E D E R A T E D C L O U D S ) Dependency on Network Uplink Single point of failure Ownership, Control, and Accountability
- 5. Challenges – Extensibility and Adaptability Task groups exchange and process information in a mission Example: maintaining a dynamic library of reference information (DRI) about the environment and objects of interest [6] A tactical edge information application encapsulates and implements such processes The suite of tactical edge information applications varies between missions and participants ⇒ We need a platform, not a one-off application [6] Consoli, A., Walters, A.: Dynamic reference information: Formalising contextual actionable information for contested environments. In: 2020 14th International Conference on Innovations in Information Technology (IIT). pp. 154–159. IEEE (2020)
- 6. This project presents the findings and experiences of a long-standing academia-government partnership focused on architecting and developing a decentralised software platform for information processing and exchange at the tactical edge
- 8. Requirements and Constraints Requirement Description Rationale Decentralisation The platform should be operable directly by the tactical edge task groups to Multi-task-group collaboration challenge: ownership, control, accountability, and single point of failure. Proximity to the tactical edge The platform should operate at or close to the tactical edge to Remove dependency on network uplink Reduce latency Information trustworthiness Guarantee the authenticity, integrity, and non- repudiation of the exchanged information Trust in the information enables decision making and action Provenance of processing results. Maintain records about how and by whom updates to shared information artefacts were made Provenance is necessary for both in-situ trust assessment and postmortem analysis. Potentially large data volume The platform must accommodate data payloads captured and exchanged at the tactical edge, such as video and audio recordings. Characteristic of tactical edge operation [1] Interoperability Interoperability with various software systems and data sources of task groups. Task groups leverage software systems and platforms as their tactical edge infrastructure
- 9. Architectural Design Decisions Requirement Solution Decentralisation • Peer-to-Peer Architectural Style • Distributing peer nodes across task groups • Leveraging an ad-hoc blockchain as a connector between peers Proximity to the tactical edge Deploying peer nodes within tactical edge Information trustworthiness Leveraging an ad-hoc blockchain as a connector between peers Provenance of processing results. Implementing (a portion of) tactical edge information applications as smart contracts Potentially large data volume Applying Off-chain Data Storage pattern [7] Interoperability • Service-oriented Architectural Style • Microkernel Architecture [7] Xu, X., Pautasso, C., Zhu, L., Lu, Q., Weber, I.: A pattern collection for blockchain-based applications. In: Proceedings of the 23rd European Conference on Pattern Languages of Programs. pp. 1–20. ACM (jul 2018). https://doi.org/10.1145/3282308.3282312
- 10. Architectural Vision: Decentralised Information Plane Dismounted System Mobile Center Dismounted System Dismounted System Fixed Center Dismounted System Mobile Center Dismounted System Dismounted System Fixed Center Task Group 1 Task Group 2 D E C E N T R A L I S E D S E C U R E I N F O R M A T I O N P L A N E ( A D - H O C B L O C K C H A I N P L AT F O R M ) Ad-hoc Blockchain Network Lightweight Client Mining Client Lightweight Client Lightweight Client Mining Client Lightweight Client Mining Client Lightweight Client Lightweight Client Mining Client Software Clients Services Trust Management Decentralised information processes Provenance Management … Joint data storage & update Decentralised Coordination Protocols Enable Platform Node Platform Node Platform Node Platform Node Platform Node Platform Node Platform Node Platform Node Platform Node Platform Node Serve An ad-hoc information platform established across computing nodes of task groups prior to or during a mission. • ad-hoc blockchain networks • peer-to-peer (P2P) content distribution networks Enabling task groups to deploy an extensible application suite TAC TIC AL ED GE IN FOR MATION APPLIC ATION S
- 11. Physical View The platform is made up of multiple identical software clients called Platform Nodes • deployed across the computing devices of task group participants. • representing a participant within the platform • Interacting with the platform on their behalf. Nodes communicate via pre-established data links A blockchain protocol operates on top of the data links Team 1 Platform Node Team 4 Platform Node Team 3 Platform Node Team 4 Platform Node Team 2 Platform Node Information Updates
- 12. Module View Participants interacts with existing tactical edge software applications (C2 Dashboard, mobile applications, AR, etc.) These applications push and pull tactical information via local, trusted platform nodes Team 1 Platform Node Team 4 Platform Node Team 3 Platform Node Team 4 Platform Node Team 2 Platform Node Information Updates P l a t f o r m N o d e Blockchain Provenance Records Joint Information Processes Content Distribution Network Payloads Kernel Kernel Services Clients App App Services IPFS Client Blockchain Client Blockchain Wallet Storage Service Cache Service Wallet Service Client C2 Dashboard Mobile Client Application Service Other Systems
- 13. Kernel vs Application Space Kernel space contains vital software clients and services • Software clients implement P2P protocols (blockchain, IPFS) • Kernel services layer provides a uniform interface to the clients Application space contains application-specific services of tactical edge information applications. • Adaptable to the mission, information needs and authorisation levels of a participant. P l a t f o r m N o d e Blockchain Provenance Records Joint Information Processes Content Distribution Network Payloads Kernel Kernel Services Clients App App Services IPFS Client Blockchain Client Blockchain Wallet Storage Service Cache Service Wallet Service Client C2 Dashboard Mobile Client Application Service Other Systems
- 14. Tactical Edge Information Application Implementing a collaborative process on tactical edge information performed by various task groups Developed separately from the platform • Smart contract • Software client • Application service linking client and contract Deployed upon the platform during the boot- strapping process. P l a t f o r m N o d e Blockchain Provenance Records Joint Information Processes Content Distribution Network Payloads App App Services Client C2 Dashboard Mobile Client Application Service Other Systems
- 15. Application Development Process 1.Determine the suitability of the application. • Identify information needs of the application. • Only shared information artefacts and their updates will benefit from being hosted on the platform. 1.Identify the data payload and provenance records. • The provenance records benefit from being managed by a blockchain • Payloads represent candidates for offloading to off-chain data stores. 1.Model the collaborative information processes (E.g., state machine approach [8]) Develop an application service Develop user-facing software clients (optional). [8] N. K. Tran, B. Sabir, M. A. Babar, N. Cui, M. Abolhasan, and J. Lipman, “ProML: A Decentralised Platform for Provenance Management of Machine Learning Software Systems,” in Software Architecture, Cham, 2022, pp. 49–65.
- 16. Platform Bootstrapping Process Determine architecture of blockchain network • Blockchain Platform • Platform configurations • Network topology and deployment [9] Deploy blockchain network according to architecture • Automation tool (NVAL [10]) Deploy and configure the kernel service layer Deploy tactical edge applications. • Smart contracts • Application services • Necessary clients [9] Tran, N.K., Babar, M.A.: Taxonomy of edge blockchain network designs. In: European Conference on Software Architecture. pp. 172–180. Springer (2021) [10] Tran,N.K.,Babar,M.A.,Walters,A.:Aframeworkforautomatingdeploymentand evaluation of blockchain networks. Journal of Network and Computer Applications 206, 103460 (oct 2022). https://doi.org/10.1016/j.jnca.2022.103460 Field-deployed by IT operators from participating task groups. Deployers bootstrap the platform on behalf of their task groups and exert no control over the platform after deployment.
- 18. Case Study Context Part of the Real-time Information Superiority Experimentation (RISE) initiative [4] Took place at Port Elliot with Surf Life Saving South Australia Involved three emergency service scenarios. • Search and rescue mission for a drifting inflatable, • Search and rescue mission for an emergency beacon attached to a boat in distress • Repeated version of the first scenario with limited communication capabilities.
- 19. Case Study Implementation – Use Case Use Case: Decentralised Dynamic Reference Information (DDRI) 1. Storing a reference information library about the environment and objects of interest 2. Updating the library based on Reference Information (RI) Updates reported by mission participants during mission [6] 3. Both storage and update of RI library are decentralized ⇒ DDRI is a tactical edge information application running on top of the platform
- 20. Case Study Implementation – Smart Contract
- 21. Case Study Implementation – Client a. List of RI Updates of a mission b. Objects of interest reported in RI updates
- 22. Case Study Deployment 3 on-site nodes at vantage points 1 remote located 85 kilometres from the experiment site All four nodes were deployed on separate cloud-based virtual machines connected via a VPN. The designated computers could control their corresponding platform nodes through a 4G uplink
- 23. Preliminary Results Experiment lasted for 5 hours and 45 minutes. 361 RI updates were recorded and exchanged (Average time interval of 44 seconds between updates.) The ad-hoc blockchain maintained a steady rate of 15 seconds between blocks ⇒ Blockchain kept up with the information load The distributed ledger grew by 10MB ⇒ Promising scalability
- 24. Lessons Learned and Conclusion
- 25. Blockchain network architecture is a means to achieve requirements The quality attributes of blockchain-based software applications depend on the characteristics of their underlying blockchains. Tweaking the architecture of a blockchain network is an alternative to developing new blockchain • reduce the amount of resource consumption on mobile nodes by disabling the mining feature or tweaking the protocol configurations. • Embed an organisation’s structure into a blockchain network’s architecture by controlling the assignment of blockchain nodes and roles (full nodes, archive nodes, miners) to participants. New research opportunities (a design space [13] and patterns (e.g., [16]) for architecting blockchain networks)
- 26. Autonomy versus Control Decentralisation implies the autonomy of participants. • Benefit of autonomy: resilience • Challenges of autonomy: coordination, bootstrapping, and responsibility to operate platform node Our solution: introducing a bootstrapping phase to coordinate the platform launch before the mission. • Centralised and coordinated deployment • Decentralised operation
- 27. CRICOS 00123M
Editor's Notes
- Presentation outline: Industry context and challenges Industry-Academia joint developed solution: Ad-hoc Blockchain Platform Industry case study and preliminary results Lessons learned
- The industry context of the project is trustworthy processing and exchange of tactical information within a tactical edge environment, where tactical edge operations take place. Tactical edge environments are characterized by dynamic and uncertainty, where participants have high-stress level and limited attention. Tactical edge environment also presents networking challenge (so called "DDIL": Denied, Degraded, Intermittent, and Limited (bandwidth)) An example of tactical edge operation that we targeted in our project was coastal search and rescue operations.
- Mission success of tactical edge operations mentioned above depends on the ability to access, process, and exchange tactical information of mission participants (e.g., deployed rescuers, forward-deployed command and control center). Nowadays, software systems and computer networks are utilised more and more for information related purposes. In our context, this combination of computer systems and networks is called "tactical edge infrastructure" The figure shows an exemplary tactical edge infrastructure. The hardware nodes are organised into three types according to MITRE's tactical edge characterisation framework. These nodes (from the least to most resourceful) are "dismounted systems", "mobile center", and "fixed center" Dismounted systems, such as drones and mobile phones, are generally assigned to mission participants (e.g., rescuers) to provide them access to the necessary information and services to carry out there mission. For instance, the TEXAS system deployed on an Android phone forms a "dismounted system". Dismounted systems can form a cluster around a mobile center. A task group might have multiple clusters, each of which covers a group of mission participants (e.g., a platoon). Here, we can draw parallel between tactical edge and usual edge computing paradigm: "dismounted systems" align with edge computing devices like Raspberri Pi, "mobile center" aligns with fog computing nodes, and "fixed center" aligns with cloud.
- Tactical edge operation might by jointly conducted by multiple task groups from different chains of command (e.g., surf life saving, police, ambulance). These task groups brings their own tactical edge infrastructure. The challenge here is how to enable the exchange and joint processing of information across these infrastructure. An example use case is Dynamic Reference Information (also known as Dynamic Mission Data), which is about the maintenance and real-time update of a library of reference information about entities and environment of a mission. For example, the characteristics and features of a missing boat are reference information that could be updated throughout a mission, based on the input from participant. Such inputs can come from different task groups (e.g., surf life saving supplies the initial information, police might gather more information during the mission, these should be integrated and propagated across participants to improve the effectiveness of their search and rescue operation). The current solution is relying on a centralised information plane to connect the task groups and run the logic for use cases such as dynamic reference information. It is not a good solution because of three issues that I’ll mention a little later.
- Another challenge is the extensibilty and adaptability of the software utilised for the exchange and processing of tactical edge information (i.e., the one that lives within the centralised information plane described in the previous slide). In our context, we call this type of software application as "tactical edge information application". Because missions differ from each other, and information needs and authorization level varies between mission participants, it's clear that we need the ability to adapt the suite of tactical edge information application to mission contexts. We also need the ability to extend that suite of application to support emerging, unplanned contexts in the future. In other words, we need a platform rather than a one-off application.Â
- The goal of this project is to address the challenges above. The main idea is to build a decentralised (to address the first challenge) software platform (to address the second challenge). The next section describes the requirements and architecture of this platform.
- Requirements are self explanatory. They are extracted from the characteristics of the tactical edge and the challenges mentioned above.
- Our architectural design solution for each and every of the identified requirements. In particular, we use P2P architectural style along with the blockchain technology as the software connector to realise decentralisation. We place this P2P platform directly within tactical edge. The blockchain provides a layer of guarantee on the security and fault tolerance of the information exchange. Via blockchain's smart contract, we can also have provenance (i.e., record) about the processing and decisions (e.g., when a smart contract is used to control the update of a reference information library, we have record of how the smart contract reached the decision. Such record is embedded inside the distributed ledger itself) One of the challenge of blockchain is dealing with large data. We leverage the off-chain data storage pattern for this purpose. In particular, our platform can automatically offload heavy data payload to an off-chain storage, such as a local database or even peer-to-peer storage solutions like IPFS, and store the cryptographic hash of the data on the blockchain. This way, we can verify that the off-chain data has not been modified, whilst storing only very small hash on the blockchain. Finally, to achieve interoperability, we leverage a combination of service oriented architecture and microkernel architecture.
- Conceptual view of the platform. As you can see, every task group members host a blockchain node (either full or lightweight, depending on their resource and authorisation level). They also run a software client called "platform node". These nodes connect to each other via the blockchain. It means that if they want to broadcast relevant tactical information, they will do so via the underlying blockchain and they access the said blockchain via a local blockchain node that they trust. The platform nodes are also responsible for abstracting the blockchain layer. Upon this abstraction layer, services such as data storage, information processing, coordination (i.e., voting) can be established. Finally, tactical edge information appications such as dynamic reference information can be implemented. One thing to notice is that despite the logical centralisation of the service (meaning the application just interact with, say, "joint data storage" service, rather than "service on node 1"), the physical deployment of both the service and the applcation is decentralised. It means that on every platform node, there are a full (or partial) suite of services and replica of the application. It means that at any point, a user would interact with their local instance or application, service, and platform. Thanks to the blockchain, the whole stack appears to user as a logically centralised entity, whilst it is actually spread across everyone in the network.
- This is the physical view of the platform. It provides a simpler and more clearer view. The key point here is that we do not care about the underlying computer network layer, whether it is 5G, tactical data link, mesh, optical, etc. The only thing we see is the network performance characteristics (e.g., bandwidth, speed, jitter). On top of such computer network, an ad-hoc blockchain network is deployed. It means that the transactions and other house-keeping information exchange of the blockchain, and thus its performance, depends on the performance characteristics of the underlying computer network. The platform is deployed on top of the blockchain. It means that the performance of the platform depends on the performance of the underlying blockchain network.Â
- This view shows the software modules within each platform node. It also shows where the tactical edge applcation such as DRI exists. It means that we are not replacing C2 dashboard or Edge AI tactical edge applications that tactical edge actors use, but any step that involves retrieving or updating the shared tactical edge information would be outsourced to the ad-hoc blockchain platform node instead.Â
- The kernel is same across every platform node. The application space changes, depending on the type of application that is available on a platform node. The wallet service encapsulates a blockchain client and a wallet, providing the ability to query a blockchain and submit transactions. The storage service encapsulates data payload stores (e.g., IPFS client or local storage) and implements the secure offloading process for large data payloads (Section 3.2). The Cache service provides the ability to cache on-blockchain records and data payloads. We introduced the cache service to the platform because we found that the read latency from a blockchain, specifically from an Ethereum-based blockchain via the Go-Ethereum, was high and impeded the user experience from the graphical user interface at the application layer. Both layers comprise software services for interoperability.
- A detailed look at the tactical edge information application. Noted that it has smart contracts (e.g., to implement the update of a reference information library), an application service (e.g., to expose REST API for invoking the smart contracts to update the reference information libirary), and an extensible suite of application client (e.g., mobile app that allows users to report new reference information update).
- After analyzing the project logs, we developed the following process to assist developers in designing and developing applications for the platform. Key thing to consider is that not every application benefits from running on the tactical edge platform. Only the part of the system that requires exchanging and updating JOINT / SHARED information should be on the platform (because blockchain is a scarce resource). After knowing which part of the data is JOINT / SHARED information, we can model the life cycle of such information as a state machine, whose state changes depending on the action of participants. Those states can be readily mapped onto smart contract variables, and state transitions (actions) can be mapped onto smart contract functions. We introduced this idea in the ProML paper. After having the smart contract, we develop application services to wrap the smart contracts, and provide new software clients if necessary.
- Now that we have covered the architecture of the platform, and the architecture and development process of applications living on the platform, the last question is "how are we going to deploy the platform and application in a mission" Our approach involves a bootstrapping phase before the mission commencement, done by IT operators, ideally from all participating task groups. This process involves determining the architecture of the blockchain network (i.e., what platform / technology, who has full node, who has light weight node, who does the mining, etc.) After having the network architecture, the next step is deploy it. NVAL can help. Next, we deploy the kernel service layers Finally, we deploy the application suite. The content of this suite varies depending on the mission and even concrete participants. For example, only users having authority to update the reference information library has access to the DRI application.Â
- (RISE) initiative [4]: test and explore information management, exploitation, and exchange technologies in a field experiment setting. Self-explanatory.
- (RISE) initiative [4]: test and explore information management, exploitation, and exchange technologies in a field experiment setting. The implementation of the use case that we have been discussing in the whole presentation.
- Class diagram showing smart contract back end. Sequence diagram showing the exchange of messages between these contracts. Agent in this case is a mission participant who submits the information update.
- We use this web interface to input the RI update on behalf of the mission participant during the experiment. This interface also serves as admin interface to review all the RI updates and track the status of individual object of interest
- Initially, we had planned to deploy the nodes directly on designated computers and connect them via cellular network links using a virtual private network. However, we had to switch to a fall-back configuration due to weather conditions and technical challenges. As a result, all four nodes were deployed on separate cloud-based virtual machines connected via a VPN. The designated computers could control their corresponding platform nodes through a 4G uplink. Example of updates: an event such as ’Jet Ski 1 pulling the lost inflatable back to the beach to treat the patient’ would involve describing the inflatable, patient details, rescue craft and crew status, and the time associated with each action in the situation. Before each experiment, participants were assigned roles as observers and processors, which were also documented in the RI updates.
- We highlight the potential of leveraging blockchain network architecture as a mean to achieve quality attribute requirements on the application layer.Â
- Essentially, if the system is fully decentralised, it would be difficult to govern and even set up. If we make it easy to govern and setup, we might sacrifice decentralisation. Our solution is introducing a centralised bootstrapping phase to setup the platform, but then allow the platform to operate and evolve in a decentralised manner. A future research is how to decentralise this bootstrapping phase as well.Â