December 2025 - In this interview, we hear from one of the teams that participated in the 2025 oneM2M International Hackathon organised by South Korea agencies. This was a global event that brought together students and developers to explore open, interoperable IoT architectures. Specifically, we spoke to a group of students (Team) from Penn State University (PSU) and their hackathon project mentor, Bob Flynn (BF).
Q: Would you begin by introducing the hackathon project team?
Team: We are a group of Penn State Engineering students working on our senior capstone project, under the direction of Professor Kyusun Choi. Bob is our project sponsor and supports us as we work on our solution. Our team represents a mix of hardware, embedded, and full-stack software expertise, which aligned well with the multidisciplinary nature of this IoT project. We are Eric Shin, Khairol Eimannajwan, (Professor Choi), Cole Nelson, Donald Jeter Boswell, Ethan Liu, Steven Bowman, and David Johnson (see team photo). Our team includes six computer engineering majors and one computer science student, which aligned well with the hardware/software scope of our solution.
BF: I am Bob Flynn, an embedded systems engineer with a background in digital signal processing and IoT platform development. I chair oneM2M’s Testing & Developers Ecosystem (TDE) Working Group. My work with oneM2M began at InterDigital Communications, where I helped design and test a full oneM2M common services entity (CSE) platform.
I later founded Exacta Global Smart Solutions, focusing on embedded development and standards-based IoT architectures. I’ve sponsored several Penn State capstone teams, and I enjoy mentoring students as they apply open standards like oneM2M to real, scalable IoT challenges. My work now focuses on helping the next generation of engineers understand how open standards enable scalable IoT ecosystems.
Q: Would you tell us about the involvement between your department at PSU and oneM2M?
Team: As college of engineering students at Penn State, we have the opportunity to work on a real-world project to support a company’s technical requirements and gain hands-on engineering experience. We were selected for this project based on our individual backgrounds and interests. Although none of us had any knowledge of oneM2M before beginning this project, we all came to learn more about it and gained interest through our project sponsor Bob, and his company Exacta Global Smart Solutions.
Q: Would you describe the scope of the project your team worked on?
BF: The project set out to demonstrate how IoT systems can scale beyond a single room or gateway. This is something that many real deployments struggle with as devices move across a work area or as new areas come online. A hospital is a good example: sensors and medical devices and the system must maintain secure, uninterrupted data flow as devices move and new gateways come into range.
What made this project especially interesting is that the team explored handover between oneM2M CSEs, which is a novel concept in IoT. Instead of a device being tied to one gateway, the architecture allowed a Bluetooth Low Energy (BLE) sensor to transition from one area to another while the oneM2M platform preserved the data model, access control, and continuity of reporting.
The goal was not just to build a prototype but to show how open standards like oneM2M can support scalable, multi-gateway environments and enable mobility in a way most IoT systems do not yet address. This prototype explores concepts not yet widely implemented in the IoT industry and aligns with emerging research directions within oneM2M.
Team: We looked at the requirement from a technical scalability angle and built a distributed, hierarchical IoT architecture using the oneM2M standard. This handles real-time data and provides secure access and seamless handover for BLE devices. This solution allows users to deploy a network for any type of application to ensure real-time data delivery over IoT devices. Using the hospital as an example environment, each physical area such as a room, floor, or zone runs its own gateway while synchronizing with a central system (an IoT platform, which is an IN-CSE in oneM2M terminology). This makes it possible to add new sensors, gateways, or entire spaces without reconfiguring the system.
We broke the project into three parts. We had a chunk of our team working on hardware solutions, based on Nordic Semiconductor devices, and integrating them within the handover application. A second group built out our advanced frontend application and ensured scalability and ease of use for our framework. The final group of students focused on everything oneM2M-related and acted as intermediaries between the frontend and the embedded solutions to bring our whole project together.
Since the team was selected for this project and not the other way around, our technical difficulties came from a lack of prior knowledge with the Nordic SDK and oneM2M standards. By diving into the project and meeting in person together 3-4 times a week, we learned from each other and become experts in each of our own roles. The content for this solution would be out of the scope for a single person to learn. Having seven team members all focus on their respective parts and share their knowledge, we were able to attack the project with confidence.
Q: In oneM2M terms, what were some of the more advanced challenges this project addressed?
BF: One of the most advanced—and frankly, novel—challenges the team explored was the idea of handover to oneM2M CSEs. Mobility is well understood in cellular networks, but in the IoT world it is still an emerging problem. Industry systems today tend to pin a device to a single gateway or cloud endpoint. When the device moves or conditions change, the flow of data breaks, security contexts reset, and applications lose continuity.
In this project, the students examined how a BLE sensor could move between different physical areas—different rooms, floors, or zones—while oneM2M CSEs maintained uninterrupted data management. These ideas align with emerging discussions in oneM2M about mobility and context transfer, but they are not yet part of the normative specifications.
To prototype this behaviour, the team had to work with several advanced oneM2M concepts, including:
- Dynamic registration, deregistration, and re-association flows as devices transition between gateways.
- Synchronization between MN-CSEs and an IN-CSE to preserve the same resource structure even as the device changes its point of attachment.
- Continuity of containers, subscriptions, and access control policies across multiple CSEs.
- Real-time discovery of available gateways and the appropriate routing of sensor data.
This type of ‘CSE-level handover’ is a direction that aligns with ongoing research in oneM2M about mobility, context transfer, and distributed service hosting. The students were essentially prototyping ideas that could influence future architectures for smart buildings, hospitals, manufacturing lines, and other environments where devices move, and where systems cannot tolerate gaps in data.
From a mentoring perspective, seeing undergraduates work on ideas that are ahead of what current IoT platforms offer commercially was extremely rewarding.
Q: What are the technical details for what the team built?
Team: For hardware, we used the Nordic SDK for development, and for the frontend solution everything is built out in Django and Python.
We simulated a temperature sensor using a BLE device. This sensor would connect to different gateways that might be distributed in our hospital environment. For the gateways, we used Raspberry Pis combined with a Nordic Semiconductor board (Thingy:91x). We also used the Raspberry Pis for IoT platform capabilities (MN-CSE) to manage commands and data being sent between devices and to send data to the visualization dashboard which runs on the Django App.
BF: One aspect I want to highlight is the team’s use of Nordic Semiconductor hardware. They worked primarily with the Thingy:91X and related development boards. These are widely used devices across the IoT industry because they provide:
- Cellular, Wi-Fi, and BLE connectivity in a compact form factor.
- Excellent low-power performance, which is essential for mobile or battery-based sensors.
- A highly mature SDK (the nRF Connect SDK), built on the Zephyr RTOS.
- Robust real-time debugging and logging tools that helped the students quickly identify issues during testing.
Nordic has supported Penn State capstone teams for several years. I want to thank Katie Oberti and Wes Cherry at Nordic Semiconductor for donating equipment and providing technical guidance. Their support directly contributed to the team’s ability to build an end-to-end system that included embedded devices, gateways, and a functioning IoT platform.
Team: Here is an image of the homepage of our application. It shows the main components and technical details. Anyone who clones our Github and runs the Django App will be able to customize the dashboard.
Q: How did the team test the finished solution?
Team: As this was a learning exercise, solution testing was mainly done throughout development. Due to the large number of dependencies between hardware devices, it was important to be robust in our debugging so we could quickly pinpoint issues as they arose.
For functional demonstration of device mobility, we made a video (see link below) to demonstrate a sensor connecting to one gateway and sending its data. We then walked the sensor to a different location and observed the handover from one gateway to another with continuous data management enabled by oneM2M functions.
Q: What lessons did the team learn from the hackathon project?
Team: For the Hackathon, we learned to focus on collaboration and project management. This was a large and complicated project, and it was quite daunting at first. By breaking it up into smaller, more achievable sub-projects, we were able to attack it with more confidence. We also gained valuable experience in time management and what deliverables should look like.
Q: Your project won a prize at the hackathon. What did the judges like about the team’s submission?
Team: We think that the judges appreciated our expertise and integration of oneM2M standards into our solution. We also made sure to explain that the project we demonstrated was only the beginning. There are goals to further improve our project and use more advanced oneM2M capabilities, and we were able to speak to these goals in detail.
Q: What advice do you have to developers and next year’s students looking at IoT and capstone projects?
Team: Do not overcomplicate solutions. Often the simplest way is the best.
It is important to have some base knowledge before diving into a new project. That makes it important to use your resources and documentation whenever possible. Documentation is always going to be the best source of information, even better than AI!
Do not be afraid to ask for help. There were several developers on the ACME oneM2M team who were happy to help us with issues we faced. People want to help, let them!
Make sure to stay on top of tasks. Working 1 hour a day for a couple of weeks is going to end up being way more productive than 10 hours in a single day.
BF: I would like to add something from the mentor side. Students often underestimate how important architecture is in IoT. Devices will change, radios will change, SDKs will change—but if you design a strong architectural foundation, everything else follows. oneM2M gives developers that blueprint.
This team learned early that jumping directly into coding leads to rework. By stepping back to design the hierarchy of gateways, CSEs, and devices, they were able to build a solution that could scale from a single room to an entire hospital floor. That mindset is what differentiates academic prototypes from scalable, production-ready architectures.
Q: Where can readers find more information about the project?
Team: There is a lot more information and project documentation in our Hackster.io article. This article goes into depth on our technical solution and how the handover actually works.
Our GitHub is open to clone and use if anyone would like to use our framework. We have in-depth READMEs explaining setup, and how the solution works. The repository includes reproducible instructions so others can build on the solution.
There is also a 2-minute video that demonstrates our solution, I think this is the most important thing to watch to understand this project.
