These first weeks of work had the objective of converting the Android project (at the time just a regular Eclipse project) into Maven, in order to manage all the project dependencies, easing the knowledge and code sharing between the PT Inovação (Aveiro) team and myself. This involved a trial and error process that eventually got completed in the end of week 2.

During the first week, some first semester classes were still ongoing, with natural time consuming activities. Also, the PDI report deadline was the 16th of February, meaning that in the first week my attention was divided into all 3 tasks.

The work developed in these weeks was the first step of the implementation of the ETSI M2M procedures: Bootstrapping. This process involved the creation of secure connections (TLS) between the Gateway (in this case the Android smartphone) and the NSCL (PT Inovação's Server). This process needed the adaptation of the given certificate and key into extension adopted by the Android OS platform, which involved substantial trial and error procedures to correctly set it up.

There were significant difficulties in this process, since the PT Inovação team had no Android OS experience and couldn't help me with its limitations. There were several Android OS limitations discovered that we had to deal with:

The OS did not support the given certificate extension (Java Key Store) as it is not included in its libraries, so another approach had to be had. The files were converted into BKS and PKCS#12 in order to ensure the correct TLS connection. The final solution was written down in an instructions file, so that if this step is needed in the future, there is a HOW-TO guide.

Due to similar limitations, the suggested RestEasy client wasn't able to be implemented in Android OS. This forced the adaptation of Android/Apache native HttpClient and SSLSocketFactory to fit our BootStrapping needs.

During the course of this week, CoAP (Constrained Application Protocol) was implemented in the Gateway, and the DTLS (TLS for UDP connections) started to be implemented.

A significant code overhaul was also executed, to better separate the projects modules, improving the Gateway's handling of threads and memory.

This framework, used to implement the protocol on the Gateway, has a very limited API. This led to the drastic measure of importing the entire source code into the project, so that changes could be done, correcting and shaping it to fit some Android OS limitations. DTLS support is incomplete because of some of these problems, this issue will be revisited later.

Apparently, at this time, the NSCL still did not fully support CoAP communication, which meant that testing would be very difficult. This led to a shift in priorities, and the GSCL implementation is going to be done, first of all, over HTTPS.

During this week, the ETSI M2M standard documents were studied in great detail, in order to implement the GSCL in compliance with it. Given the proximity to a demonstration to be held in PT Inovação on the 28th March, it was decided to hardcode a first GSCL implementation, just to understand its functionality, with a scheduled re-work afterwards, to improve the versatility of the implementation.

By the end of the week, Jackson (JSON marshalling library) and NanoHTTPD (mini web-server) were successfully implemented into the project. The first will be used to serialize java objects to and from JSON strings, to ease the exchange of information between the Gateway and the NSCL. The second will be critical to allow the Gateway to receive commands, either subscriptions or specific management orders.

Since the beginning of the project, important members of the PT Inovação M2M team left. This left a void in knowledge, since the persons responsible for implementing the NSCL were suddenly gone. This made the GSCL implementation job harder, since simple questions mean that a major documentation search is needed.

The standard is composed by several technical reports and specifications, that specify in great detail all the exchanges possible between all the interveners. This is good as everything is documented, but poses some difficulties in finding the relevant information in all the documents.

During this week, the basis of the GSCL was successfully implemented in the Mobile M2M Gateway. By the end of the week, on the PT Inovação's workshop, the Gateway was successfully exchanging data with the NSCL, following the ETSI M2M standard.

For this to be successfully executed, there was the need to develop a better understanding about the Jackson library. This was needed to allow the payloads to be exactly as standardized, and to be successfully interpreted by the M2M Gateway, which was not happening by default.

The Jackson library is very complete and even has a module that allows the usage of JAXB annotations, such as the ones that the ETSI classes had. The problem is that this module is also built upon the “javax.bind.xml” libraries that the Android OS does not implement, having no effect on this project. This forced me to strip all the annotations, and replace them with Jackson annotations where needed.

This new lack of annotations caused the output to be different than what was expected, and to fix that there was the need to create custom Serializers and De-Serializers to comply with the standards.

This week was focused on the sensor gathering module of the Mobile M2M Gateway. Firstly the Zephyr Sensor was successfully debugged and correctly integrated with the GW. Then, on a lengthy meeting with my supervisor, Prof Ana Aguiar, some changes to the Gateway's architecture were decided. These changes were made to improve the scalability of new sensors, as well as removing original packages that did not make much sense as the development moved forward.

This re-design was also completed in the actual Gateway, providing a solid base for the addition of new sensors.

The changes needed on the Gateway, to accommodate the sensor became clear in the meeting with professor Ana Aguiar, but they involved a great deal of planning, to make sure that it would fit all kinds of sensors. This involved improving my programming skills, to do this efficiently.

During the course of these weeks, the design changes discussed in week 8 were implemented, adding consistency to the application's purpose, and focusing on the importance of connectivity (protocols and sensors), while also adding stability in the process.

Firstly focusing on the sensors, the handling of internal and external sensors was changed to a more scalable manner, and some bugs were corrected in the Zephyr's implementation. This also paved the way for other sensors implementation, but there were no available devices for integration.

The information flow inside the GW also changed a bit, with obsolete classes being removed and some memory handling improvements.

Then as for connectivity, the state machine in place that was handling the message flow to/from the NSCL started to be removed, since the message exchanges had to be in response to subscriptions, and not sequentially as was happening. This led to the implementation of a new local HTTP server based on Apache's HTTP classes, which supported TLS. The server was successfully implemented (with and without TLS) message handling logic began to be implemented, but not yet tested (see below).

The first problem with the sensors was that I began the efforts of integrating a sensor, that my supervisor thought was usable via bluetooth, and then figured out it used the Continua Alliance standard protocol. This led to a reach out to PT Inovação, so that we could agree on sensors and start to implement them. This caused the second problem, because after choosing to use PT's ForaCare devices, issues arose about the procedures to be taken regarding the Non Disclosure Agreement that PT already had, and how it extended to IT.

There were several issues with the re-implementation of the HTTPServer. This was re-implemented since the ETSI norm specifies that communications NSCL→GSCL are also encrypted. So, after implementing this over TLS using the Apache library, I realized (with help from Pedro Rocha) that were not using TLS yet. So, the secure connection was commented, and efforts turned to the handling of the subscriptions.

The problems returned when the need to test the subscriptions arose while I was not in PTIn's facilities, because the NSCL could not reach my Gateway. I tried to do this over VPN and over a mobile data connection, unsuccessfully. Professor Ana Aguiar will talk to CICA to name the Gateway in the Mobile Lab, while in the mean time, testing is limited to inside PTin.

During the course of these weeks, the main progress was the debugging, with Pedro Rocha (PT Inovação) of the steps taken to deliver sensor data onto the NSCL. By the end of week 11 this communication was being executed flawlessly from wihin PTin's network.

To attempt to test from from FEUP, there was the need to configure the internal DNS server within the Mobile Lab so that it could be accessed from anywhere inside the FEUP Network. After this was executed with help of Carlos Pereira and Paulo Vaz. Then, to allow the remote NSCL to reach our server, a request was sent to CICA, which led to the problem below.

Then, aside from the efforts to test from FEUP, there was also the beginning of the talks with PT, to reach a consensus on the best (or more practical) way to actuate over the Gateway. Details on this subject can be found here.

To allow the internal routing to be accessed from the outside, a request was sent by Professor Ana Aguiar. This however still has not been fulfilled, preventing the remote tests from the Mobile Lab.

This kind of actuation has never been done before, which makes this discussion so much more important and difficult.

During the course of these weeks, the process of testing from within FEUP's facilities, with the configured routes and external DNS, was completed successfully. The Mobile M2M Gateway is now able to exchange data with the NSCL correctly, facilitating the execution of tests.

Also, a strategy of actuation was chosen between us and PTin, defining a specific approach to this problem. The development of the Network Application (NA) that will make use of this strategy was also started, reusing much of the code written for the M2M-GW, specially communication-wise.

During the course of this week, the Network Application was built from scratch, based on the existing and functioning Gateway, since the communication procedures are very similar on both. To accomplish this, a new common module was built for the shared code between them, to ease the addition and maintenance of features that affect both the GW and the NA.

To start the registration process, the NA must first register itself into SclBase, and then subscribe the SCLS resource, to receive data from the Gateway's sensors. This was all accomplished by the end of the week, with successful tests showing the sensor data in the NA were executed.

The actuation discussed in the previous weeks was also implemented by the end of the week, but could not be fully tested because of an NSCL limitation.

There weren't any major setbacks this week. The progress even evolved fairly good given the tasks at hand.

During this week, the reverse information flow (from the NA to the GW) was implemented, since this was absolutely necessary to allow the Gateway to properly receive and process the commands to control the sensors. Mechanisms to execute this process were added to the NA and GW and successfully tested with the PT Inovação team in the middle of the week.

This week also marked the implementation of a test User Interface on the NA, to allow the user to view the received data.

Just as the week before, the work executed was very time consuming, but generally was very productive and went well.

During this week, some changes to the NA subscription procedures were implemented, to contemplate a case that happened when the Gateway started previously and the notification from the registration of its SCL was not received on the NA. This effectively meant that the NA did not “know” that SCL existed, which would cause issues. There is going to be a demonstration of this project on the 17th in Aveiro, and this was an important feature, since the GW and NA will be running in different devices.

Also with the demo in mind, a few changes were made to the way the NA's GUI acts in each situation, to improve feedback to the user.

This week also marked the start of the writing efforts for the dissertation.

Writing is always hard, and it takes a lot of time to start the routine where it becomes productive. Despite all this, the writing efforts are paying off, and I hope to have a draft of every chapter to include in the Working Version to upload on the 15th June.

During these weeks, the focus has been in writing the final document to be delivered on June 30th.

This project has a Redmine project a bit more specific about the details of this project. It can be viewed here.