CoAP over BundleProtocol

CoAP over Bundle Protocol Bachelor’s Degree Thesis Submitted to the Faculty at the Escola Tècnica Superior d'Enginyeria de Telecomunicació de Barcelona de la Universitat Politècnica de Catalunya by Max Lampurlanés Rosell In partial fulfillment of the requirements for the DEGREE IN TELECOMUNICATION TECHNOLOGIES AND SERVICES ENGINEERING Advisor: Anna Calveras Augé Barcelona, January 2025 ETSETB – Degree in Telecomunication Technologies and Services Engineering -2- -3Summary Resum______________________________ Aquest treball tracta sobre l’estudi d’una implementació de la capa d’aplicació CoAP sobre la capa Bundle en una arquitectura de xarxa basada en DTN. Els objectius del projecte són la correcta transmissió de paquets CoAP a través de una xarxa DTN amb memòria persistent. S’ha realitzat un estudi pràctic d’una implementació de la capa de nivell d’aplicació CoAP sobre la capa Bundle creant una capa intermèdia per la seva correcta interacció. El desenvolupament d’aquesta capa intermèdia és la gran part del projecte. Per la realització d’aquest estudi s’han utilitzat les llibreries aiocoap i µd3tn, i el llenguatge de programació Python. ____________________________Resumen Este trabajo trata sobre el estudio de una implementación de la capa de aplicación CoAP sobre la capa Bundle en una arquitectura de red basada en DTN. Los objetivos del proyecto son la correcta transmisión de paquetes CoAP a través de una red DTN con memoria persistente. Se ha realizado un estudio práctico de una implementación de la capa de nivel aplicación CoAP sobre la capa Bundle creando una capa intermedia para su correcta interacción. El desarrollo de esta capa intermedia es la gran parte del proyecto. Para la realización de este estudio se han usado las librerías aiocoap y µd3tn, y el lenguaje de programación Python. -4Summary____________________________ This work focuses on the study and implementation of the CoAP application layer over the Bundle layer in a network architecture based on DTN. The objectives of the project are the correct transmission of CoAP packets through a DTN network with persistent storage. A practical study was conducted on implementing the CoAP application layer over the Bundle layer by creating an intermediate layer to ensure proper interaction. Developing this intermediate layer constitutes a significant part of the project. For this study, the aiocoap and µd3tn libraries, along with the Python programming language, were used. -5Acknowledgements This work was funded in part by the Spanish MCIU/AEI/10.13039/501100011033/FEDER/UE through projectPID2023-146378NB-I00, and by Secretaria d'Universitats i Recerca del departament d'Empresa i Coneixement de la Generalitat de Catalunya with the grant number 2021 SGR 00330. I want to thank Anna Calveras Augé for trusting me with this project and assisting me during the process. -6Revision history and approval record Revision Date Author(s) Description 1.0 20/12/2024 ML Document creation 1.1 07/01/2025 ML, AC Error correction 2.0 17/01/2025 ML Revised after review 3.0 19/01/2025 ML, AC Final version LLISTA DE DISTRIBUCIÓ DEL DOCUMENT Role Surname(s) and Name Student Lampurlanés Rosell, Max (ML) Project Supervisor Calveras Augé, Anna (AC) Written by: Reviewed and approved by: Date 20/12/2024 Date 19/01/2025 Name Max Lampurlanés Rosell Nome Anna Calveras Augé Role Project Author Role Project Supervisor -7Contents Summary .......................................................................................................................................................................... 3 Acknowledgements ..................................................................................................................................................... 5 Revision history and approval record ................................................................................................................. 6 Contents ............................................................................................................................................................................ 7 List of Figures ................................................................................................................................................................. 9 List of Tables ............................................................................................................................................................... 11 Abbreviations .............................................................................................................................................................. 12 1.1. Work goals ................................................................................................................................................ 14 1.2. Requirements and specifications .................................................................................................... 15 1.3. Methods and procedures .................................................................................................................... 15 1.4. Work plan .................................................................................................................................................. 16 2. State of the art of the technology used or applied in this thesis ................................................. 18 2.1. DTN .............................................................................................................................................................. 18 2.1.1. Definition and background ...................................................................................................... 18 2.1.2. Core concepts................................................................................................................................. 19 2.1.3. Applications example ................................................................................................................. 21 2.1.4. Challenges and Limitations...................................................................................................... 21 2.2. CoAP Architecture ................................................................................................................................. 21 2.2.1. Definition and overview............................................................................................................ 21 2.2.2. Core Features ................................................................................................................................. 22 2.2.3. Application examples ................................................................................................................. 24 2.3. Used software and tools...................................................................................................................... 24 2.3.1. Python ............................................................................................................................................... 24 2.3.2. Wireshark ........................................................................................................................................ 24 2.3.3. aiocoap .............................................................................................................................................. 25 2.3.4. µd3tn ................................................................................................................................................. 25 3. Methodology / project development ...................................................................................................... 27 3.1. DTN Network development .............................................................................................................. 27 Contents -83.2. CoAP app development ....................................................................................................................... 30 3.3. AAP2.0 python application ................................................................................................................ 33 4. Results .................................................................................................................................................................. 40 4.1. Experiments and Tests ........................................................................................................................ 40 4.2. Data Analysis ........................................................................................................................................... 41 4.2.1. Scenario 1: Two nodes µd3tn Network .............................................................................. 41 4.2.2. Scenario 2: CoAP aiocoap scenario ...................................................................................... 42 4.2.3. Scenario 3: Developed encapsulation/decapsulation using AAP2.0 and aiocoap 44 4.2.4. Scenario 4: Developed encapsulation/decapsulation using AAP2.0 and aiocoap with persistent storage ................................................................................................................................. 45 5. Sustainability Analysis and Ethical Implications ............................................................................... 47 5.1. Sustainability Matrix ............................................................................................................................ 47 5.1.1. Environmental impact ............................................................................................................... 47 5.1.2. Economic impact .......................................................................................................................... 48 5.1.3. Social impact .................................................................................................................................. 49 5.2. Ethical implications .............................................................................................................................. 49 6.1 Conclusions ...................................................................................................................................................... 50 6.2 Future Directions .......................................................................................................................................... 50 Bibliography ................................................................................................................................................................ 51 Appendix A ................................................................................................................................................................... 53 -9List of Figures Figure 1: Work plan diagram. .............................................................................................................................. 16 Figure 2: Work plan Gantt diagram. .................................................................................................................. 17 Figure 3: DTN network stack in a heterogenous network. Source [8] ............................................... 20 Figure 4: Components of a Bundle Node. Source [10]. ............................................................................. 20 Figure 5: Abstract Layering of CoAP. Source [13]. ...................................................................................... 22 Figure 6: CoAP message format Source [14] ................................................................................................. 22 Figure 7: A GET request with timed response. Source [15].................................................................... 23 Figure 8: A request and response with NON. Source [16]. ...................................................................... 23 Figure 9: Wireshark example ............................................................................................................................... 24 Figure 10: The refined architecture of the µD3TN development tree. Source [19]. .................... 26 Figure 11: Node A and Node B scheme ............................................................................................................ 27 Figure 12: Compilation of the µd3tn library. ................................................................................................ 28 Figure 13: Node A deployment............................................................................................................................ 28 Figure 14: Node B deployment ............................................................................................................................ 28 Figure 15: Deployment of the communication ............................................................................................. 29 Figure 16: Attachment of the receivers in each node ................................................................................ 29 Figure 17: Sending of a message from each node ....................................................................................... 29 Figure 18: Received messages in each node.................................................................................................. 29 Figure 19: CoAP App scheme ............................................................................................................................... 30 Figure 20: CoAP temperature server resource ............................................................................................ 30 Figure 21: CoAP server start code. .................................................................................................................... 31 Figure 22: CoAP temperature client.................................................................................................................. 32 Figure 23: Results of the CoAP application. ................................................................................................... 32 Figure 24: Application developed scheme. .................................................................................................... 33 Figure 25: Architecture stack of developed application. ......................................................................... 33 Figure 26: Bundle with CoAP in the payload example. ............................................................................. 34 Figure 27: Example of CoAP Message creation, encoding and encapsulation. ............................... 34 -161.4. Work plan The project has been divided in fourth work packages as seen in the following diagram. Figure 1: Work plan diagram. The work packages seen in Figure 1 are divided in different tasks, here I will summarize these tasks: • WP1: This work package focuses on the research of the existent documentation, and it has 4 different tasks. Task 1 is CoAP research, Task 2 is Bundle Protocol research, Task 3 is research over the existent documentation of CoAP over Bundle Protocol, and the last one is Task 4 summarizing of the necessary information. • WP2: This work package focuses on the development of the testbed to transmit CoAP messages over Bundle Protocol divided in three tasks. Task 1 is the development of a DTN environment, Task 2 is the development of a CoAP application and implementation in the DTN Network, and Task 3 is to test the developed application. • WP3: This work package focuses on the expansion of number of nodes in the DTN Network and the tests of different scenarios. It has two tasks, Task 1 the expansion of nodes used in the DTN Network, and Task 2 is to analyses the results of the implementation and consider the final results and conclusions. • WP4: This is the work package related with all the documentation to be delivered. It has three tasks, Task 1 is the writing and revision of Project -17Proposal and Work Plan, Task 2 is the writing and revision of Critical Review document, and Task 3 is writing and revision of the TFG Final document. The work packages specified in Figure 1 were distributed as the project author estimated as seen in the following time diagram. Figure 2: Work plan Gantt diagram. There have been no major incidents in the intended planning of the project, as the time for each work package included a margin for delays. -182. State of the art of the technology used or applied in this thesis ____________________________________________________________ CHAPTER 2 State of the art of the technology This section describes the state of the art of the technologies related to the project. 2.1. DTN 2.1.1. Definition and background DTN is a networking architecture designed to address challenges in environments where traditional Internet protocols fail due to large number of disconnections, long propagation delays and high error rates. The basis for this architecture lies with that of the Interplanetary Internet, which focused primarily on the issue of deep space communication in high-delay environments. Originating from research into interplanetary communications by NASA and DARPA in the early 2000s, DTN was formalized through the publication of RFC 4838, which defined its fundamental architecture. It is defined as an end-to-end message-oriented overlay called the "bundle layer" that exists at a layer above the transport (or other) layers of the networks on which it is hosted, and below applications. Devices implementing the bundle layer are called DTN nodes. The bundle layer forms an overlay that employs persistent storage to help combat network interruption. It includes a hop-by-hop transfer of reliable delivery responsibility and optional end-to-end acknowledgement. It also includes a number of diagnostic and management features. For interoperability, it uses a flexible naming scheme (based on Uniform Resource Identifiers (URI) explained in RFC3986 [7]) capable of encapsulating different naming and addressing schemes in the same overall naming syntax. It also has a basic security model, optionally enabled, aimed at protecting infrastructure from unauthorized use. -192.1.2. Core concepts DTN have some core concepts that are important to understand how the architecture works, those are described below: • Bundle Protocol: A DTN-specific protocol that encapsulates the data into bundles that are the packages used for the DTN networks. These bundles are similar to packages used in traditional networks but optimized for delay tolerance. • Bundle Protocol Agent (BPA): The BPA of a node is the node component that offers the BP services and executes the procedures of the BP. • Store-and-forward: Bundles are stored in the intermediate nodes until the next node becomes reachable. This is enabled with the Persistent Storage capability of the nodes, that ensures that the node has a Data Base accessible to store the Bundles. • Custody Transfer: Ensures reliable communication as so the responsibility of transferring the bundle is delivered to intermediate nodes. That was present in BP version 6 [8] but not included in BP version 7. • Endpoint Identifiers (EID): The EID are the specific URI schemes for the nodes of the DTNs networks. Every node must have an EID that identifies it on the network. • Application Data Unit (ADU): The ADUs are the application layer packages needed for the nodes to create a bundle. • AAP2.0: The application agent of the node is the component that utilizes the BP services to effect communications, to be more precise the AAP constructs, accepts deliveries, requests transmissions and process ADUs. • Convergence-Layer Adapter (CLA): A CLA is a node component that sends and receives bundles on behalf of the BPA, utilizing the services of some "integrated" protocol stack that is supported in one of the networks within which the node is functionally located. Figure 3 shows an example of DTN network stack in a heterogenous network. It is important to mention that below the Bundle Protocol layer there exist a Convergence Layer Adapter (CLA). It is a crucial component that acts as an intermediary between the Bundle Layer (which is responsible for the core functionality of BP) and the underlying network layer. The Convergence Layer Adapter provides the necessary interface to transport bundles (data units in BP) over different types of transport networks. These transport networks can vary widely, such as: Traditional IP-based networks (e.g., TCP/IP or UDP), Satellite networks, Wireless links, Disruption-tolerant networks (e.g., interplanetary networks, networks in remote areas). The Convergence Layer Adapter essentially "adapts" the BP to these underlying network technologies -20by mapping the bundle's transmission requirements onto the specific characteristics and capabilities of the transport network. In the Figure 3 the CLA is indicated as CL. Figure 3: DTN network stack in a heterogenous network. Source [9] Figure 4: Components of a Bundle Node. Source [10]. Figure 4 shows the components of a Bundle Node. The ones that are note explained before are the Administrative Element that is the node component that constructs, request transmissions and receive Administrative Records, that are ADUs exchanged between nodes for administrative purposes. The only Administrative Record in the Bundle Protocol is the status reports, that are used for the nodes to ensure that a Bundle has progressed thorough the network. -212.1.3. Applications example DTN networks have been implemented in various use cases. One of them is in NASA’s use of space communication with the Interplanetary Overlay Network (ION) [11] implementation intended to be used in embedded environments including spacecraft flight computers. Another example is for rural connectivity providing access to remote areas with lacking reliable infrastructure with Terra [12] a Java implementation developed for terrestrial DTN use. 2.1.4. Challenges and Limitations Despite having a huge potential as seen in previous points, the DTN network protocol have some challenges. Major security challenges that take the form of nodes behaving as “black holes” are one of the major concerning’s related to the BP. Another limitation is the lack of checksums in the BP where it will be impossible to detect errors in bundles headers. 2.2. CoAP Architecture 2.2.1. Definition and overview The CoAP is a lightweight protocol designed to enable efficient communication between devices in resource-constrained environments, as IoT networks. The main characteristics are defined in the RFC 7252 [1] by the Internet Engineering Task Force (IETF). CoAP is an application protocol that operates asynchronously over UDP to minimize overhead while maintaining similar functionalities as HTTP, as it is architecture adheres to the Representational State Transfer (REST) also known as RESTful implementation. The REST model is based on Servers that make resources available under a Uniform Resource Locator (URL), and clients access these resources using methods such as GET, PUT, POST, and DELETE. The interaction model of CoAP is similar to the client/server model of HTTP. However, machine-to-machine interactions typically result in a CoAP implementation acting in both client and server roles. A CoAP request is equivalent to that of HTTP and is sent by a client to request an action (using a Method Code) on a resource (identified by a URI) on a server. The server then sends a response with a Response Code; this response may include a resource representation. As an abstract explanation of CoAP you could think of it as a two-lawyer protocol, one of them used to interact with UDP -22as an asynchronous communication, and another as the request/response interactions as shown in Figure 5. Figure 5: Abstract Layering of CoAP. Source [13]. 2.2.2. Core Features CoAP has some core concepts that are useful to understand it’s architecture: • RESTful Architecture: As mentioned before, CoAP follows a similar architecture as HTTP, similar as a request-response model using methods such as GET, POST, PUT and DELETE. Contrary at the HTTP architecture the CoAP eliminates unnecessary overhead making it more suitable for constrained devices. • Resource structure: the CoAP protocol integrates and observe pattern, where the clients “observe” a resource on the server, changing it or only getting information of it. • Message format: CoAP is based on a compact message that are transported over UDP, these messages are encoded in a simply binary format like seen in Figure 6. Figure 6: CoAP message format Source [14] -23- • CoAP message types: there are two message types in CoAP, Confirmable (CON) and Non-confirmable (NON). The Confirmable messages are responded by the server with an ACK containing the response if needed, if the server can respond immediately the message is responded with an empty ACK, when the response is ready the server sends it in a CON message. The Non-Confirmable messages are responded by the server with NON messages. Figures 7 and 8 illustrate both cases. Figure 7: A GET request with timed response. Source [15]. Figure 8: A request and response with NON. Source [16]. • CoAP methods: As said before, there are 4 different methods in the CoAP protocol. The GET methods retrieves information of the resource identified by the request. The POST method function is determined by the server, usually there is a new resource created in the server. The PUT method updates the data in the resource indicated in the request. And the last method is the DELETE method that deletes the resource indicated by the request. -242.2.3. Application examples There are various application examples of the CoAP protocol. One of them is for Industrial IoT where it can facilitate the communication between sensors and controllers in the manufacturing environments. Another example could be for smart homes, where it can control thermostats, lights and door locks. One last example could be monitoring health systems in wearable devices that transmit patient data. 2.3. Used software and tools In this subsection is discussed all the software and tools used for this project, and explaining the decision over why these are selected. 2.3.1. Python For the programming language the author of this project decided to use Python [17] due to the high compatibility with the libraries that will be explained below and the experience that the author have over python programming language. 2.3.2. Wireshark Wireshark [18] was the software tool used by the project author to capture and analyse the packages that were exchanged during the testing of the developing phase of the code. The were some problems with the compatibility of the bundle protocol packages but this was solved by updating at the latest Wireshark version and adding the computer ports used with the DTN library to the BP protocol in Wireshark. This port where added to Preferences->Protocols->BP->BP UDP port(s). Figure 9 shows a screen shot of a BPv7 bundle. Figure 9: Wireshark example capture. -252.3.3. aiocoap The aiocoap library was chosen by the author of this project to implement the CoAP functionalities in the developed code. This library was chosen for being the most updated library for the CoAP implementation in python. The aiocoap library has some basic functionalities that make it easy to implement. One of them is the basic resource structure for the server creation, where a resource can be created using a Resource class defining in it the actions that the server must do for every type of message received. From the client side, the aiocoap library enables to create messages by using the “Message” class where it can be specified the code, the destination URI, all the options supported by the CoAP messages and if the message is CON or NON. The aiocoap library has a license BSD 3-Clause License <https://github.com/chrysn/aiocoap/blob/master/LICENSES/BSD-3-Clause.txt >. 2.3.4. µd3tn The µd3tn library was one of the main libraries of the project and it was the one used to deploy the DTN network using the command line. In the same library there is a section for python integration that was used by the author to interact with the aiocoap library and the deployed network. This library was developed by the D3TN group. The licence of this library is free to use and open source. Here there are defined some basic functionalities that the µd3tn library provides: • Deploying nodes with different EIDs and AAP2.0 sockets to interact with these nodes. • Specify the bundle protocol version and the type of connection expected by the nodes (for example, it implements several BP convergence layers 1 , such as MTCP, TCPCLv3, CCSDS Space Packet Protocol, BIBE,). • Establish the communication link between two nodes and the time when this communication will be accessible. (contact) • The python integration enables to create AAP2.0 agents capable to connect to node AAP2.0 sockets, this agent can receive and send messages through the µd3tn deployed Network. 1 https://gitlab.com/d3tn/ud3tn#what-does-%C2%B5d3tn-provide -32case is “coap://localhost/temperature” with the exception of the GET all functionality, that its mandatory to add a “?all” at the end of the URI for the server to recognize this option. The last two options are the “mtype” that indicates if the CoAP Message must be NON or CON, in this case NON, and the payload, that is where the data travels. When the request is created is sent using the “request().response” method from the client context, and a response is waited. Figure 22: CoAP temperature client Is it worth mentioning that all the CoAP messages payloads are encoded in an 8-bit Unicode Transformation Format (UTF) due to the requirement of the CoAP protocol. The result of this application can be seen in the images below where the messages exchanged can be seen in the client and server terminal, the client receives the response of the server with the code 2.04 if the resource has changed (a PUT) or 2.05 if the response has content on its payload. The validation of the results will be explained in the Experiments and Tests part of the document. Figure 23: Results of the CoAP application. -333.3. AAP2.0 python application The final last and most relevant part of the development of this project is the python application that will interact with both the DTN Network and the CoAP Application. The code of this part will be added to the appendixes and here we will discuss all the methods used to implement it. Figure 24 shows the elements of the development utilized to implement this application both in interaction with other protocols and the overall schematics. Figure 24: Application developed scheme. To design this application, we had to design a new network architecture where a new layer was designed in between the application layer (CoAP) and the Bundle Protocol Layer. The purpose of this layer is to encapsulate the messages from the CoAP application in a bundle al the origin side, and decapsulate the payload of the bundles into CoAP messages at the destination side. In the Figure 25 it can be seen where this layer sits in a 4 nodes scheme, where the CoAP application is in Node A and Node B. Figure 25: Architecture stack of developed application. This encapsulation methods works in different steps. The first is the encoding of the CoAP message with the encode method of the aiocoap library making it a binary -34representation, this encoded message is encapsulated in a bundle payload. The bundle then is sent to the destination EID specified where the CoAP message is meant to be send. In the figure 23 it can be seen in orange what kind of message travels in every link. The bundles represented in this figure are as seen in the figure below. Figure 26: Bundle with CoAP in the payload example. Figure 27: Example of CoAP Message creation, encoding and encapsulation. When the bundle arrives to the destination node specified in the destination EID the payload is decoded using the aiocoap library. Then if the CoAP message is a request this is sent to the CoAP server that must be accessible form the destination node. The response of the server is treated the same way as specified before. In the other case of a response arriving, this is decoded using the aiocoap library and the aiocoap application receives the response entirely. With the capabilities of the µd3tn with the pyhton-ud3tn-utils (the python specific integrations) it can be created an APP2 interactive application that will act as an encapsulation/decapsulation layer between the CoAP application and the DTN Network. This interactive application will act as the architecture structure designed above. The first thing to consider is the options that the library offers for implementing the designed code. The python-ud3tn-utils offer a AAP2.0 client different classes, the one chosen was the AAP2AsyncUnixClient that is an asynchronous client for connecting to a µd3tn AAP2.0 Unix socket node, that is perfect for the case implemented. For being -35able to send and receive bundles with each node it's mandatory to create two agents (AAP2AsynUnixClient), one will be a receiver, and the other one will be the sender. At this point it is possible to send and receive bundles with each node. Figure 28: Receiver and sender agent code. As seen in the image above the two agents created run in asynchronous threads so the AAP2.0 application can send and receive ADUs at the same time. The next step from the client side is to create the CoAP message and encode it using the aiocoap library functionalities. Figure 29: CoAP message creation and encapsulation. When created and encoded the CoAP message is put in the Bundle payload, then the message is sent to the destination node EID and the specified receiver agent of the node, and the code waits for the response code form the Bundle Protocol. -36When the response is received its payload is decoded as a Message from the aiocoap library in which the payload of the aiocoap message will bring the aiocoap server response. If the request was a GET it will bring the data of it, and if it is a PUT it will bring the confirmation of the operation. Figure 30: Receiver and decoder of CoAP messages. From the server side, the message received on the AAP2.0 application related to Node B is decoded in a Message from the aiocoap library, and its remote address is created using the data of the options of the CoAP Message. This is due to the new protocol Context created for being able to send CoAP Messages. The message is sent to the server and the response is waited. Figure 31: Decapsulation of the CoAP Message. When the response of the server arrives, it is encoded with the aiocoap library method, and then it is encapsulated in a new Bundle that will be sent to the destination EID of the client and its receiver agent. -37Figure 32: Encapsulation and sending of CoAP Response. Figure 33: Class diagram of developed code. Figure 34: Activity diagram main function. -38Figure 35: Activity diagram sending agent. Figure 36: Activity diagram receiving agent. At this point there is a clear implementation of the intended design, but it is missing the persistent storage feature that the DTN Network offers. To add this feature a new Node C will be added with the persistent storage enabled. The new scheme of the final deployment can be seen below. -39Figure 37: Final developed implementation. To deploy this new Node C, it is not necessary to change anything from Node A or Node B, but we must update the contacts between them and add new contacts with the new node. Figure 38: Node C deployment command. Figure 39: New contact plan between nodes. It is worth mentioning that in the new contact plan when configuring the connection to Node C from Node A and Node B, there must be a reachable list of nodes from where Node C has contact. For example, when configuring the connection from Node A to Node C, it must be specified that Node C could reach Node B, this is important because the bundles traveling from Node A to Node B must know that they must go through Node C. This reachable list of nodes is added when the connections are configured with the option “-r” in the command line, it can be seen in Figure 39. The connection from Node C to Node B will start 60 seconds later than the other connections, making that Node C must save all the bundles that go to Node B until the connection is established. -404. Results ____________________________________________________________ CHAPTER 4 Results 4.1. Experiments and Tests To test the developed code, tests were conducted in different scenarios. Here will be discussed all of these scenarios: • Scenario 1: The first scenario is a µd3tn Network with two nodes, where two bundles where send in a bidirectional communication. In this scenario is meant to be seen the two bundles correctly arrive to the other nodes and travel through the developed communication. This scenario is only to validate the µd3tn implementation, with only bundles traveling through it. • Scenario 2: The second scenario is a basic test of the aiocoap library, where a PUT and a GET are sent from the aiocoap client to the aiocoap server. In this test it is meant to be seen one GET one PUT and two responses. • Scenario 3: The third scenario is the test of the developed code, where different CoAP messages are sent through the µd3tn network with two nodes. In this scenario we will see the CoAP message encoded inside the bundles, and the CoAP messages sent to the server. • Scenario 4: The fourth and last scenario is similar as the third one but with persistent storage, where the time stamps of the messages will differ from the ones with and immediate connection. To make this scenario more real, a third node will be added in between the two existent ones (Node A and Node B), that is Node C. -414.2. Data Analysis The visualization and capturing of it, is made through the Wireshark software. In each case explained above we will discuss all the data captured. 4.2.1. Scenario 1: Two nodes µd3tn Network For the first scenario we can see two exchanged bundles, one from Node A to Node B, an another one from Node B to Node A. The scheme of the first tested scenario can be seen below where the data is exchanged from the sender of each node to the receiver of each one. Figure 40: First scenario. In the image of the results captured below it can be seen the two bundles exchanged between nodes, where the source and destination addresses are the ones that are specified above. The data exchanged can clearly be seen in the decoded part of the message on the Wireshark capture. -48The presential meeting where held at the Campus Nord installations of the Universitat Politèctica de Catalunya, and the author of this project is from Sant Sadurní d’Anoia, where he started all the commutes needed to go to the meetings. In this commute was used the public bus, for a distance of 40.6 kilometers, with an emission of 93 grams of CO2 per kilometer per trip, the total footprint for transportation is of about 98.17 kilograms of CO2. With all that take into account there is one last thing to calculate, the total environmental impact of the computer use of the project. This use contemplates the investigation, the coding, and the validation held in one computer that was access remotely and the code and documentation writing done in on laptop. Trying to make an approximate calculation of the energy consumed it is estimated an average us of the main remote computer of 30 hours per week and the secondary computer of the 30 hours accessing the remote computer and 5 hours a week using it both during 15 weeks. With a computer consumption of 180 W we can estimate a total energy consumption of 175.5 kWh. With an equivalence of 0.45 kg of CO2 for 1 kWh the total amount of carbon footprint is 79 kilograms of CO2. With all the calculations done the total carbon footprint due to this project is of 177.9 kilograms of CO2. 5.1.2. Economic impact The cost of the project can be calculated by counting the equivalent salaries of the project author and the project supervisor. In the next table is gathered the information necessary to make that calculation. Position Weekly dedication Wage Junior engineer 30 hours 12€/hour Professor 3 hours 35€/hour Table 1: Estimation of dedication and wage. -49With that information in mind and making some assumptions it’s possible to calculate the total cost of the project. Position Dedicated weeks Weekly Wage Social Security (33.33%) Total Junior engineer 15 360€ 120€ 7200€ Professor 15 105€ 35€ 2100€ Table 2: Cost estimation breakdown. As it’s seen in the table the total economic cost of the project is 9300€. 5.1.3. Social impact This project could have a direct social impact in the future if the development of it is continued, the possible real implementations could bring a DTN network with a light application above it. 5.2. Ethical implications The ethical implications of this project are positive due to the final objective of it, the overall objective aims to make internet more accessible in disruptive and delaying networks. Of course, there is a lot of work to do up to the point the ethical implications can be seen, but the final impact can be very positive. -506. Conclusion and Future Work ____________________________________________________________ CHAPTER 6 Conclusions and Future Work 6.1 Conclusions To sum up, the author of this project successfully implemented the CoAP over Bundle Protocol, making a testbed for each protocol and testing the final implementation that the author developed. The main result of the work established that is possible to deploy a CoAP over Bundle Protocol communication system if there is an intermediate layer between the two protocols. Considering the results it can be said that the author of the project has achieved the objectives established. Successfully learning about the CoAP Protocol and the Bundle Protocol, deploying a testbed for each protocol, implementing and testing an application using the two protocols. The only thing that the author had left behind is the unification of the UIRs that both protocols use, to make a more unified implementation. This project could bring some advances to the field of study, but it must also be said that there is a lot of work to do. 6.2 Future Directions The obvious next step in this implementation is the unification of the URIs as said before, making it simpler to use. It will be also interesting to develop a web application to make the test simpler. Another obvious improvement will be testing more values and different situations that the author has not thought about. Another future direction of the project is to improve the security and error detection capabilities of both protocols. -51Bibliography [1] Shelby, Z., Hartke, K., and C. Bormann, 7252, IETF Datatracker, June 2014, "The Constrained Application Protocol (CoAP)”, RFC 7252, <https://datatracker.ietf.org/doc/html/rfc7252>. [2] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture”, RFC 4838, IETF Datatracker, April 2007, <https://datatracker.ietf.org/doc/html/rfc4838 - autoid-2>. [3] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle Protocol Version 7", RFC 9171, IETF Datatracker, January 2022, <https://datatracker.ietf.org/doc/rfc9171/>. [4] Chrysn, aiocoap - Python CoAP library for the IoT, GitHub, August 2024, <https://github.com/chrysn/aiocoap?tab=readme-ov-file >. [5] D3TN, µd3tn - Python utilities for uD3TN, GitLab, October 2024, <https://gitlab.com/d3tn/ud3tn/-/tree/master/python-ud3tnutils?ref_type=heads>. [6] Carles Gomez and Anna Calveras, “Constrained Application Protocol (CoAP) over Bundle Protocol (BP)”, IETF Datatracker , June 2024, <https://datatracker.ietf.org/doc/html/draft-gomez-core-coap-bp-02>. Accessed October 2024. [7] T. Berner-Lee, R. Fielding, l. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, RFC 3986, IETF Datatracker, January 2005, <https://datatracker.ietf.org/doc/html/rfc3986>. [8] K. Scott, S. Burleigh, “Bundle Protocol Specification”, RFC 5050, IETF Datatracker, November 2007, < https://datatracker.ietf.org/doc/html/rfc5050>. [9] Ronan J, Walsh K, Long D. Evaluation of a DTN convergence layer for the AX. 25 network protocol. In Proceedings of the Second International Workshop on Mobile Opportunistic Networking 2010 Feb 22 (pp. 72-78). [10] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022. Available: < https://www.rfceditor.org/info/rfc9171>. [Accessed January 2025]. [11] S. Burleigh, K. Scott, “Interplanetary Overlay Network”, February 2008, <https://www.nasa.gov/directorates/somd/space-communications-navigationprogram/interplanetary-overlay-network/ > -52- [12] RightMesh, Terra - a lightweight and modular DTN library, GitHub, 2019, <https://github.com/RightMesh/Terra?tab=readme-ov-file>. [13] Shelby, Z., Hartke, K., and C. Bormann, 7252, IETF Datatracker, June 2014, "The Constrained Application Protocol (CoAP)”, RFC 7252, <https://datatracker.ietf.org/doc/html/rfc7252 - autoid-4>. [14] Shelby, Z., Hartke, K., and C. Bormann, 7252, IETF Datatracker, June 2014, "The Constrained Application Protocol (CoAP)”, RFC 7252, < https://datatracker.ietf.org/doc/html/rfc7252 - autoid-9>. [15] Shelby, Z., Hartke, K., and C. Bormann, 7252, IETF Datatracker, June 2014, "The Constrained Application Protocol (CoAP)”, RFC 7252, <https://datatracker.ietf.org/doc/html/rfc7252 - autoid-5>. [16] Shelby, Z., Hartke, K., and C. Bormann, 7252, IETF Datatracker, June 2014, "The Constrained Application Protocol (CoAP)”, RFC 7252, <https://datatracker.ietf.org/doc/html/rfc7252 - autoid-5>. [17] Python Software Foundation, Python 3, Version 3.13.1, 2025, Available: <https://www.python.org/>. [18] Wireshark Foundation. "Wireshark Network Protocol Analyzer". [Online]. Available: <https://www.wireshark.org/ >. [19] M. Bittencourt, F. Madeira, R. L. Oliveira. "Bringing HTTP semantic interoperability to constrained IoT devices with CoAP". arXiv preprint arXiv:2407.17166, July 2024. [Online]. Available: < https://arxiv.org/pdf/2407.17166>. [Accessed: October 2024]. -53Appendix A _________________________________________________________ APPENDIX A An appendix All the code developed for this project is available in the author's GitHub repository. The repository includes all necessary scripts, libraries, and documentation related to the project. Repository Link: https://github.com/maxlampu/CoAPoverBundle You can access the source code and any additional resources related to the project by visiting the link above.