May 2026 - In this interview, we speak to Samiullah Khairy (SK) who recently completed his studies at the University of Pisa. For his thesis, Samiullah worked on a project with the Consorzio Nazionale Interuniversitario per le Telecommunicazioni (CNIT). The project involves a container tracking system and includes oneM2M in an IoT data sharing capability. SK’s supervisor, Dr. Paolo Pagano, contributed to a oneM2M interview in 2024, when he described how CNIT operates an IoT and oneM2M testbed environment to support their work on developing the future of maritime ports.
Q: Would you begin by telling us about yourself?
SK: I recently completed my master’s degree in Computer Science and Networking from the University of Pisa, graduating in April 2026. Before that, I completed my undergraduate degree in Computer Science at Rana University in Kabul, Afghanistan. My interests span networked systems, cloud infrastructure, and IoT - particularly where these converge in real-world applications.
For my master’s thesis, I designed and built OCEAN DPP. This is a nine-microservice platform that integrates zero-knowledge proofs, blockchain anchoring, and IoT standards into a working proof-of-concept system for maritime container logistics. The system was validated on a live Italy-Germany container voyage. A journal paper based on this work is currently in preparation.
Q: What is CNIT?
SK: CNIT, which stands for Consorzio Nazionale Interuniversitario per le Telecommunicazioni, is Italy’s national, inter-University consortium for Telecommunications. It is a non-profit consortium established in 1995 that unites public Italian universities to perform research, innovation, and education/training. CNIT is active across Italy and the European continent.
For my project, I worked within the Networks of Embedded Systems laboratory at CNIT in Pisa. This laboratory focuses on large-scale digital infrastructures exploiting a fully equipped ICT testbed, located at the port of Livorno, to test final transport and logistics applications. Within this environment, my work focused on the design and implementation of IoT data pipelines and privacy-preserving digital product passport systems. I worked under the supervision of Dr. Paolo Pagano, and in collaboration with Dr. Mariano Falcitelli, a senior researcher at CNIT who coordinates several projects including LOGICA.
Q: What is the market context for the OCEAN-DPP project?
SK: End-to-end supply chain tracking is an important and emerging requirement in the global economy. When we look at maritime shipping, this transport mode applies to around 80 % of global trade. In the European Union, the Ecodesign for Sustainable Products Regulation (Regulation (EU) 2024/1781) requires digital product passports to enable supply chain tracking for physical goods. Digital Product Passports (DPPs) store product lifecycle information from production through to consumption and recycling. The regulation entered into force in July 2024. DPP obligations begin applying from 2027, starting with batteries. Other product categories will follow by 2030. Further details are available here.
In the maritime domain specifically, there are four main challenges. First, there is no maritime-specific DPP standard. As a result, there is no shared, standardised system for tracking containerised goods, despite the scale of the sector. Second, a typical shipment involves eight to fifteen different stakeholders. That means data is fragmented and siloed, with no shared event format and no tamper-evident record of what happened to a container during transit. Third, there is a real tension between privacy and compliance. Companies have an obligation to demonstrate compliance with regulations such as cold-chain temperature requirements, but doing so traditionally means sharing raw operational data, which they may not want to disclose to competitors or third parties. The fourth challenge follows from that: the trust deadlock. You either share everything and lose privacy, or you self-declare and lose verifiability.
OCEAN DPP addresses these challenges by combining multiple technologies with the aim of enabling interoperable, auditable, and privacy-preserving digital product passports.
Q: Let us turn to the technology components. Would you provide an architectural overview to set the scene?
SK: Yes, the system has five components. The first is a standardised event format. Sensors on a container report things like temperature, humidity, GPS position, and whether the container door is open or closed. That raw data needs to be translated into a format that any stakeholder can read and act on. For this we use the Electronic Product Code Information Services (EPCIS 2.0) standard from GS1, which defines a common structure for supply chain events. Each sensor reading is converted into an EPCIS event that tells you what, when, where, why, and how of what happened to that container.
Figure 1: OCEAN DPP Architecture
The second component handles compliance verification. This is where we use a cryptographic technique called a zero-knowledge proof. The idea is that a carrier can prove to a customs authority or insurer that the container stayed within its contractual temperature range throughout the journey, without revealing the actual temperature readings. The verifier sees only the proof object, in the form of three elliptic-curve points, which can be checked in a web browser in under ten milliseconds. External parties verifying compliance through the public portal cannot access the raw sensor data; the zero-knowledge proof gives them only what they need, which is a verified compliance verdict.
The third and fourth components are closely related. Anchoring every single event to a blockchain would be expensive and slow. So, the third component uses a Merkle tree which is a way of grouping events into a batch and computing a single fingerprint for the whole batch. Only that fingerprint needs to be sent to the blockchain. At a batch size of fifty events, this gives us a 98 % reduction in blockchain transactions compared to anchoring each event individually. The fourth component is IOTA, which we use as the anchoring layer: once a Merkle root is recorded on the ledger, Merkle inclusion proofs make any tampering with the underlying events detectable, regardless of whether the ledger itself could theoretically be altered.
The fifth component is where oneM2M comes in. We use Mobius4 CSE, an open source oneM2M platform developed by KETI in South Korea, as the storage and sharing layer. Once an event has been processed, enriched with its zero-knowledge proof and Merkle inclusion proof, and anchored on IOTA, a copy is stored in Mobius4 as a oneM2M ContentInstance resource. External parties such as customs agencies, port authorities, logistics partners, insurers can then query this data through our API gateway. The oneM2M access control policies let us specify exactly what information each type of user can see. A customs officer gets the compliance verdict and the cryptographic proof. They cannot see the raw sensor readings.
Q: How do these components come together in a typical use case?
SK: Let us take a refrigerated container carrying pharmaceuticals from the port of Livorno to a destination in Germany. A tracking device attached to the container continuously sends sensor readings as MQTT messages over the internet to our platform. The sensor readings include temperature, humidity, GPS position, gyroscopic data, and door seal status.
After that, the next thing that happens is translation. RabbitMQ receives those MQTT messages via its MQTT plugin and routes them through to an EPCIS translator service. This translator converts each raw sensor payload into a structured EPCIS 2.0 event. This is a standardised record that says that “this container, at this time, at this location, under these conditions, was in this state.”
Figure 2: Information Flows in OCEAN DPP System
Those translated events go to the DPP Core service, which does three things. It generates a zero-knowledge proof attesting whether the temperature reading was within the contractual threshold. It adds the event to the current Merkle batch. And when the batch is complete, it sends the Merkle root to IOTA for anchoring. A copy of the enriched event, consisting of the EPCIS record plus its proof plus its Merkle inclusion path, is then written to Mobius4 as a oneM2M ContentInstance.
At the front end, the system has three views. Authenticated users, such as the carrier and its operators, see a live dashboard where they can track temperature trends, see alarm conditions, and view the full event timeline for each container. There is also a public portal where customs agencies, port authorities, and insurers can enter a container ID and verify compliance. These users only see the zero-knowledge proof result and the IOTA anchor reference, and not the raw sensor data. Then, there is a REST interface that logistics partners and third-party systems can call to retrieve specific information about a shipment. The whole system works because all stakeholders are working from the same EPCIS 2.0 event standard.
Q: Did you test the system in laboratory or other conditions?
SK: During development we used emulators to test the system under controlled conditions. Then we moved to a real-world test. We used container tracking devices (CTDs) developed by CNIT in collaboration with other partners within the LOGICA project. Over the past several weeks we have been deploying and testing multiple CTDs and observing how the system behaves with live data. We are currently receiving real telemetry from these devices in the field. At the moment, they are deployed on trucks for initial ground-based testing while we prepare for maritime deployment.
For my thesis specifically, the field validation involved attaching a CTD to a refrigerated container that made the Italy-Germany round trip. The platform was deployed on a cloud server, and we received live MQTT telemetry throughout the journey. The full pipeline ran end-to-end, covering event ingestion, EPCIS translation, zero-knowledge proof generation, IOTA anchoring, and dashboard display. This happened under real internet connectivity conditions, including periods of intermittent signal. This was an exploratory test to confirm the system works in practice, not a controlled benchmark. There were systematic performance measurements carried out separately in the lab.
Q: What criteria are you using to evaluate the system?
SK: The field trials teach us about real operating conditions. Beyond that, I ran four specific evaluations in the lab.
The first measured end-to-end latency on how long it takes from a sensor reading arriving at the platform to the time it gets processed, proved, and stored, across different event rates. This matters because if a container breaches a temperature threshold, the carrier needs to know quickly so that they can intervene. We measured latency as we scaled from one container to ten simultaneous containers and found that, across tested event rates up to the platform’s sustained throughput of seven events per second, latency stays well below 200 milliseconds. That is fast enough for the real-time visibility an operator needs.
The second evaluation looked at the cost of privacy, specifically, how much latency overhead the zero-knowledge proof process adds. Proof generation takes about 300 milliseconds on average. For a container that reports every few minutes under typical operating conditions, this is an acceptable overhead. Verification in a browser takes approximately 10 milliseconds, so the public portal feels instant to anyone checking compliance.
The third evaluation examined the cost-effectiveness of Merkle-batched anchoring using IOTA as the ledger layer. We use IOTA as the anchoring layer to ensure that once a Merkle root is recorded on the ledger, any modification to the underlying events is immediately detectable through Merkle inclusion proofs. By batching fifty events into one Merkle tree and sending only the root to IOTA, we achieve a 98 % reduction in transaction volume compared to anchoring each event individually. The anchor latency at batch size fifty is around 3.5 seconds, which runs in the background without affecting the main pipeline.
The fourth evaluation tested reliability. The core question was whether the system loses any data when individual components fail. We ran the system normally and then deliberately killed different services one at a time to see what happened. First, we tested what happens when the Translator service, which converts raw MQTT payloads into EPCIS events, goes down. RabbitMQ buffered fourteen incoming messages during the outage and delivered them all once the service recovered, with zero loss. When we shut down the DPP Core service, which is the component that generates proofs and anchors events, RabbitMQ kept the unprocessed messages queued safely. When DPP Core came back online, it drained nineteen queued messages with zero loss.
We tested the same failure condition with the Mobius4 storage layer. When it went down, a dead-letter queue captured the eighteen events that could not be written, and they were replayed successfully on recovery. We also tested backpressure, which arises when sensor events arrive four times faster than normal for a sustained period. RabbitMQ buffered seventy-seven messages using its flow control mechanism and drained the queue to zero once the burst subsided, again with no data loss. In all four failure scenarios, the system recovered completely.
On scaling, we found that doubling the DPP Core capacity reduced median latency by 37 %. Doubling Mobius4 capacity eliminated connection errors entirely and increased the number of successfully processed events in the same test window by 74 %.
Q: What was your experience of using oneM2M standards and the Mobius platform?
SK: Mobius4 has been in use at CNIT for several years, which gave me confidence in its stability. It is open source and actively maintained. I did not need to modify the platform itself. The integration work was mostly about structuring our container data correctly as oneM2M Application Entity and ContentInstance resources, and making sure our API gateway proxied retrieval requests with proper authentication.
As for oneM2M standards more broadly, there is a lot to take in at first. I found the tutorials on the oneM2M website genuinely helpful, particularly the short videos and the notebook-based practical exercises. They made the resource model and the API structure much clearer than reading the specifications cold.
Q: Where can readers find more information about the project?
SK: The broader LOGICA project, which provided the research context for this work, has a page on the CNIT website.
A journal paper describing the OCEAN DPP architecture and evaluation results in full is currently in preparation, targeting the MDPI journal “Logistics,” which is a Q1 publication in the field. Once published, that will be the primary reference for anyone wanting the technical details.
