oneM2M_Hackathon_Team_PennStateNitannyLions_2025

Overview

This project demonstrates a scalable IoT data management architecture built on the global oneM2M standard, designed to support large deployments of sensors, gateways, and applications across many rooms, zones, or buildings. The system uses BLE sensors feeding into distributed gateways, each running as middle nodes, which synchronize upward to a central IN-CSE on a shared local network. This hierarchical structure enables easy expansion, resource discoverability, and consistent data flow across any number of devices.

For a demonstration, we apply this scalable architecture to a Smart Healthcare Room Monitoring example. BLE sensors represent patient or room data sources, and the system uses oneM2M FlexContainers for structured sensor data and ACP-based role control to restrict access (e.g., nurses vs. doctors). A Django CloudAppAE dashboard subscribes to updates in real time, automatically adapting as new devices, rooms, or gateways are added which shows how the system scales seamlessly without reconfiguration.

By focusing on a distributed, multi-gateway oneM2M deployment, this project highlights how organizations can build large, modular, privacy-aware IoT systems that maintain low latency, secure communication, and future extensibility. The healthcare example showcases one scenario, but the architecture applies equally well to smart campuses, industrial monitoring, commercial buildings, or any environment requiring device growth at scale.

1. Problem statement

IoT deployments often start small but grow rapidly as more rooms, zones, or devices are added. Most systems aren’t designed for this growth which leads to fragmented data, inconsistent communication protocols, duplicated dashboards, and security issues as scale increases. When dozens of sensors expand into hundreds across gateways and applications, it becomes difficult to maintain uniform data models, real-time synchronization, resource discoverability, and role-based access control.

Without a standardized architecture, every expansion requires custom integrations, manual configuration, or complete system redesigns. This lack of scalability makes it challenging for organizations whether hospitals, campuses, labs, or enterprises, to reliably manage data from multiple distributed sources.

For demonstration, we apply this challenge to a hospital example, where multiple rooms generate vital, patient and environmental data. As more rooms and sensors are added, the system must maintain secure access, consistent data flow, and low latency, illustrating how important scalable IoT solutions are in real environments.

2. How we solve the problem

We address these scalability challenges by building a distributed, hierarchical IoT architecture using the oneM2M standard. Each physical area such as a room, floor, or zone runs its own gateway while synchronizing with a central IN-CSE. This allows new sensors, gateways, or entire spaces to be added without reconfiguring the system.

Sensors (BLE peripherals in our demo) transmit data to nearby gateways, which publish the information into the oneM2M resource tree using standardized containers, CINs, and FlexContainers. These resources automatically become discoverable to applications through the IN-CSE, regardless of how many devices or gateways are added.

A Django-based CloudAppAE subscribes to updates from the oneM2M system and adapts in real time as the deployment grows. Role-based ACP policies restrict data access for different user types and scale naturally across many rooms or devices. We demonstrate this with a hospital scenario (doctors with broad access, nurses with room-level access), but the architecture is general and applies to any multi-zone IoT environment.

By combining hierarchical CSEs, standardized data structures, and flexible access control, the system provides a foundation for large, secure, and rapidly expandable IoT deployments.

3. Positive impact / benefits

3.1. Seamless Scalability Across Rooms, Buildings, or Entire Campuses

Because each area operates its own middle node and synchronizes with a central IN-CSE, new sensors or gateways can be added without redesigning the system. Whether scaling from a single room to an entire hospital wing or from one lab to a full smart campus, the architecture expands effortlessly.

3.2. Standardized Data Model for Large Deployments

Using oneM2M FlexContainers and common resource structures ensures that every device follows the same data format. This eliminates the fragmentation typically seen in growing IoT systems and makes onboarding new devices or zones simple and error-free.

3.3. Strong, Role-Based Access Control at Scale

oneM2M <ACP> policies allow fine-grained permissions that scale across many devices and users. Whether applied to doctors and nurses in the demo scenario or security teams, building managers, and operators in other environments, access remains secure and consistent even as the deployment grows.

3.4. Reliable Real-Time Data Synchronization

The LAN-based hierarchy ensures low latency and consistent updates across multiple gateways. As the system expands, each new gateway integrates into the same unified resource tree, maintaining real-time responsiveness without increasing complexity.

3.5. Interoperable and Vendor-Neutral Expansion

Because the platform follows the oneM2M global standard, it supports sensors and gateways from different manufacturers. This prevents vendor lock-in and allows organizations to scale using a mix of BLE, Wi-Fi, cellular, or future IoT devices.

3.6. Adaptable Across Many Real-World Use Cases

Although the demo uses a hospital scenario, the same scalable architecture applies to:

• Smart campuses
• Industrial monitoring
• Building automation
• Environmental sensing
• Multi-lab research facilities
• Commercial security systems

Any environment with multiple zones or rooms benefits from the same architecture.

3.7. Built-In Support for Device Mobility and Handover

With RSSI-driven handover and gateway coordination, devices can move between areas without losing context. This is useful not only for patients in healthcare, but also for mobile sensors, equipment, and asset tracking in large deployments.

Architecture

Our system is designed around a scalable, multi-gateway oneM2M architecture that can grow from a few sensors to hundreds of devices distributed across multiple rooms, zones, or buildings. The structure follows the oneM2M hierarchical model, allowing seamless data flow, discoverability, and secure access control as the deployment expands.

1. High-Level System Architecture

The full data path is:

BLE Sensor → Local Gateway → IN-CSE → Application (CloudAppAE)

This architecture supports any number of gateways, each responsible for a room or zone. The IN-CSE acts as a global coordinator, maintaining a unified resource tree across the entire deployment.

This structure is ideal for scalable environments such as smart hospitals, campuses, research facilities, industrial sites, and multi-building IoT networks.

2. Layer Breakdown

A. Device Layer — BLE Sensor Nodes

BLE peripherals (e.g., Seeed XIAO nRF54L15, ESP32-S3) broadcast environmental or vital data. Each sensor can be added without reconfiguring the system, thanks to consistent data modeling using FlexContainers.

Key Scalability Features:

• Lightweight BLE footprint
• Auto-discovery through gateway scanning
• Uniform data structure for easy integration

B. Gateway Layer — Distributed Zones

Each zone or room has an nRF7002 DK acting as a BLE central. The gateway processes incoming data and forwards it to a Raspberry Pi.

Responsibilities:

• Scanning and connecting to sensors
• Parsing GATT data
• Publishing readings as CINs (contentInstances)
• Managing multiple sensors simultaneously

Multiple gateways can be added as the deployment grows. Each gateway becomes a new middle node in the architecture.

C. oneM2M Core Layer — Hierarchical Gateway | IN-CSE Model

Gateways (Zone-Level)

• Host sensor containers locally
• Generate CINs for every reading
• Announce resources upward

IN-CSE (System-Level)

• Central registry for all devices
• Stores unified resource tree
• Routes notifications to applications
• Enforces <ACP> at scale

This separation is what makes the system scalable. Each gateway will handle local traffic, while the IN-CSE coordinates the entire network.

D. Application Layer — CloudAppAE Dashboard

The dashboard is a Django application registered as a oneM2M AE. It subscribes to sensor containers across all gateways, enabling:

• Real-time monitoring
• Automatic device discovery
• Dynamically adapting views as gateways/sensors are added
• Scalable access control using <ACP>

In the hospital example, this provides doctor-level and nurse-level views, but the same mechanism applies to any multi-role environment.

3. Handover & Device Mobility Support

Sensors broadcast test advertisements, allowing gateways to grab RSSI data and the oneM2M application to determine which zone should own the device. This mechanism scales across many rooms or buildings, enabling:

• Mobile sensor tracking
• Smooth transitions between gateways
• Continuous monitoring without data loss

4. Simplified Resource Tree (Scalable Example)

As new zones or sensors are added, they simply appear under new or existing middle nodes which require no redesign.

5. Why This Architecture Scales

• Modular zone-based gateways allow horizontal expansion
• Unified oneM2M data model ensures consistent integration
• Centralized IN-CSE maintains a complete global view
• FlexContainers enable structured, discoverable data across large deployments
• ACP policies scale to any number of users and devices
• Local network backbone keeps latency low even as the system grows

Implementation

1. Implementation overview

Our implementation follows a modular, zone-based approach designed to demonstrate how a oneM2M deployment can scale smoothly from a few devices to many rooms, gateways, and applications. Every component which includes sensor firmware, gateway logic, CSE instances, and the dashboard, was implemented to support easy expansion without redesign.

The full system flow is:

BLE Sensor → Local Gateway (nRF7002 + Pi) → IN-CSE → CloudAppAE Dashboard

Each layer operates independently but follows a unified oneM2M resource model, making the system naturally scalable and interoperable.

1.1. Sensor Layer Implementation

BLE peripherals (Seeed XIAO nRF54L15 and ESP32-S3) run lightweight firmware that broadcasts environmental or vital-sign data. These sensors use standard BLE GATT characteristics and provide RSSI information for mobility and handover support.

Why it scales:

• Any number of sensors can be added
• No custom integration per device
• FlexContainers allow consistent, discoverable data formatting

1.2. Gateway Layer Implementation

Each room or zone contains an nRF7002 DK acting as a BLE central. The gateway scans for sensors, connects automatically, parses readings, and forwards data to a Raspberry Pi via UART-over-USB.

On the Raspberry Pi, a local gateway script generates contentInstances (CINs) for each new reading. Multiple gateways can be deployed simply by adding more Pi gateways to the network.

Why it scales:

• Each new zone = just add another gateway
• Gateways operate independently with standardized behavior
• No changes needed at the IN-CSE or dashboard

1.3. oneM2M Service Layer Implementation

The IN-CSE runs ACME-CSE on a local machine and acts as the global coordinator. All gateways register to it automatically, forming the distributed resource tree.

The oneM2M structure makes the system scalable by design:

• IN-CSE aggregates, synchronizes, and exposes a global view
• FlexContainers organize sensor types consistently
• ACP policies enforce secure, role-based access regardless of scale

Why it scales:

• Adding a new gateway instantly expands the network
• All data becomes discoverable using standard oneM2M queries
• Hierarchical architecture handles growth naturally

1.4. Application Layer Implementation (CloudAppAE Dashboard)

The Django-based CloudAppAE is registered as a oneM2M AE and subscribes to containers across all gateways connected to the IN-CSE. When new CINs are created, the IN-CSE sends live notifications.

The dashboard:

• Adapts in real-time as new sensors or gateways appear
• Uses ACP rules to restrict user access
• Presents all gateways as part of one unified system

In the demo scenario, the UI shows rooms as “zones, ” but the design supports smart campuses, labs, or industrial floors equally well.

Why it scales:

• Subscriptions automatically apply to new rooms/sensors
• No dashboard reconfiguration needed for expansion
• Access policies apply uniformly across the hierarchy

1.5. Local Network Backbone

All components run on a shared LAN, not the cloud. This achieves:

• Low latency
• On-premises data security
• High reliability even as the deployment grows

The LAN model is ideal for hospitals, campuses, and industrial settings where data should stay local.

2. Device/sensor implementation

Our sensor layer is designed to be lightweight, low-power, and easy to scale across many rooms or zones. Each BLE device follows the same data model, allowing new sensors to be added without modifying the system architecture or the application layer.

2.1. BLE Peripheral Devices

We use two primary BLE platforms for demonstration:

• Seeed XIAO nRF54L15 (Sense)
• ESP32-S3 module

Both devices act as BLE peripherals that broadcast or transmit environmental and vital-sign data such as:

• Temperature (IR or onboard sensor)
• Humidity
• Ambient conditions
• Test advertisements for RSSI (used for handover logic)

Each sensor runs minimal firmware using Zephyr RTOS or ESP-IDF to keep the system simple and energy-efficient.

2.2. GATT-Based Data Model

Sensors expose their measurements through standard BLE GATT characteristics, making them universally compatible with BLE central devices. The GATT structure includes:

• Environmental Sensing Service (ESS)
• Notifications with new data
• Temperature characteristic
• Optional IR temperature characteristic

Using standard services ensures the system is device-agnostic and supports easy expansion with other BLE sensors.

2.3. Periodic Measurement & Broadcasting

Each sensor periodically updates its values and either:

• Notifies the gateway with data
• Broadcasts main BLE advertisements
• Broadcasts test BLE advertisements for RSSI data acquisition

This approach supports both connected-mode data transfer and broadcast-mode mobility detection, depending on the gateway logic.

Why this scales: Dozens or hundreds of sensors can broadcast simultaneously without coordination because BLE is designed for high-density environments.

2.4. Consistent oneM2M Data Formatting via FlexContainers

To ensure interoperability and scalability, all sensor data is formatted into a flexible, structured schema once it reaches the gateway:

• Each sensor maps to a specific FlexContainer profile
• Data fields (temp, IR, RSSI) are placed in named attributes
• The gateway publishes these into the IN-CSE using a uniform structure

This enables auto-discovery of new sensors by the dashboard and avoids sensor-specific hardcoding.

2.5. Framework Onboarding

Because the BLE devices follow the same structure:

• Only light manual configuration is required for new sensors
• Gateways automatically detect and parse incoming data over the BLE connection
• The Raspberry PI automatically announces the new sensor up to the IN-CSE
• The CloudAppAE automatically receives updates after subscriptions are applied

The behavior of the framework demonstrates how the system easily scales from a handful of sensors to large, distributed environments.

2.6. Handover implementation

Embedded devices

• Each seeed peripheral device is configured to display test advertisements while the main BLE connection is held by one of the central nRF7002 devices.
• Each nRF7002 device will parse the test advertisements and push the RSSI data associated with the seeed MAC address over USB using UART.

OneM2M Application

• Each Raspberry Pi 5 is running a script to parse the data being sent over UART from the nRF7002. This data is then sent up to the IN-CSE over Wi-Fi.
• The application compares the incoming RSSI data against a specified connection threshold. If the RSSI from the Raspberry Pi that holds the connection is below the threshold, then the application will compare the recent RSSI data packets to determine whether there is a better gateway to hold the connection.
• Upon determining there is a better connection, the application will remove the MAC address from every nRF7002 whitelist except the one which will hold the connection, send a disconnect command to the nRF7002 which currently holds the connection, then re-add the MAC address to the other whitelists after enough time has passed for the intended nRF7002 to pick up the seeed’s connection. These commands are orchestrated using “inbox” containers within each gateway’s Application Entity.

2.7. Dashboard / Application Implementation

The dashboard is a Django web app that shows all devices and sensors in real time. We built it to connect directly with the oneM2M IN-CSE so it updates automatically when new data arrives.

What We Used

• The app runs on Django 4.x with SQLite for storage. We added Bootstrap for the layout and Chart.js for graphs. The dashboard talks to the IN-CSE using standard oneM2M REST calls.
• When you open the app, it registers as an Application Entity and subscribes to all sensor containers. After this, the IN-CSE sends notifications whenever new readings come in.

Main Pages:

Welcome Page

• Gives a short welcome and description of the project prompting entering into the Home Page.

Home Page

• The home page gives a quick overview of the whole system. From here you navigate to Devices, Gateways, or Analytics using the blue nav bar or larger cards describing those pages.

Device List

• Every sensor shows up as a card with its name, status, and which gateway it connects to. When we add new sensors, they appear here without needing to add any code. There's a blue info box at the top explaining how devices join the system through BLE and oneM2M.

Device Details

• Click "View Details" on any sensor and you get a full page showing:

- Temperature reading

- Current gateway connection

- How often it updates

- Status badge showing if data looks good

• The page grabs the newest reading from the oneM2M tree and displays it in an easy format.

Gateways

• This page lists all the Raspberry Pi gateways running. You see how many are active, if they're synced up, and their paths in the resource tree. We use this to check that new gateways connect right and announce their data to the IN-CSE.

Analytics

• The charts page shows live graphs for each sensor. Temperature lines update every 5 seconds and display the last 50 readings. You watch data change over time and spot trends or weird values.

Handover Response

When a sensor moves between gateways this is what happens:

• Before handover, the device card shows something like "Connected to: gw-A" under the sensor name.
• During handover, the system detects better RSSI at another gateway. The sensor disconnects from the first gateway, updates its records, and the sensor reconnects to the new gateway. The IN-CSE sends a notification to the dashboard.
• After handover finishes, the device card updates to show "Connected to: gw-B" with a new timestamp. Data keeps flowing without gaps because oneM2M tracks devices by MAC address and AE ID not by gateway.
• Users see changes quickly. No data gets lost and no duplicate entries show up.

How You Use It

• You don't need to refresh the page. The dashboard polls for updates every 5 seconds and shows new data as it arrives.
• Click any device to see details. Switch to the Gateways page to check which are online. Open Analytics to watch sensor trends over time.
• The system handles all state through Django models and SQLite. When a notification comes in, the backend parses the JSON, saves the reading, and updates what you see on screen.

Scalability

• Adding new sensors or gateways doesn't change the dashboard. It queries the oneM2M tree every time and gets what’s there. You could go from 2 sensors to 50 and the UI adjusts on its own.
• This works because oneM2M gives us a standard way to find devices, read their data, and subscribe to updates. The dashboard treats everything the same no matter which gateway or sensor type you add.

Dashboard Views

2.8. Challenges & how we resolved them

Embedded side difficulties:

Debugging

• The nature of this kind of embedded development means that debugging is always a struggle as not every board will have an on board debugger.
• Our solution was to embed debugging statements throughout the code and inspect the output to make sure it is always functioning as intended.

Flashing

• There were some complications in flashing to some of our intended devices. Some code that would build could cause unintended effects on the board itself, inhibiting future flashes or the running of the code at all.
• Our solution was careful monitoring of changes made so that bad changes could be reverted. We also conducted much research in methods of fixing the flashing capabilities for our boards.

IN-CSE Overload from Excessive Sensor Data

• During early prototypes, the IN-CSE began to slow down because each gateway continuously pushed new CIN entries every second. Since oneM2M stores CIN object, the database quickly ballooned and caused:

- Long query times

- Slow dashboard loading

- Memory exhaustion inside the CSE

• Solution: Implemented automatic data trimming at the IN-CSE

- Each sensor container now keeps only the most recent 10 CIN entries

- Older entries are automatically deleted when new data arrives.

- This ensures the database remains small, fast and stable

Connecting Gateways to the IN-CSE

• At first, the gateways (Raspberry Pi + nRF7002 DK) could not reliably connect to the IN-CSE which was hosted on AWS.
• This made the system difficult to test and caused repeated failures in gateway registration and CIN publishing
• Solution: Instead of relying on cloud networking, we redesigned the architecture to run all components inside a single local network:

- The IN-CSE was moved to a laptop inside the same LAN.

- Each gateways were assigned local IPs (e.g., 192.168.x.x)

- All communication stayed within the LAN (no public IP, no port forwarding, no AWS networking issues)

- Registration became instant and reliable

Application Scenarios

The underlying architecture is designed for any large, distributed IoT environment. Below are several real-world scenarios where a scalable multi-gateway oneM2M system provides clear advantages.

1. Smart Healthcare Facility Monitoring

In a hospital, each room or ward has BLE sensors connected to local gateways. As the facility grows, adding new rooms, floors, or buildings causes the system to automatically adapt without reconfiguration. Doctors and nurses receive real-time data with role-based access, while the hospital benefits from a unified, secure monitoring system.

Value Added:

• Automatic onboarding of new rooms
• Role-based privacy using <ACP>
• Real-time vitals and environmental monitoring
• BLE handover supports mobile patients or equipment

2. Smart Campus Environmental Monitoring

University campuses often consist of many buildings with unique environmental conditions. BLE or Wi-Fi sensors placed throughout classrooms, labs, and halls can report temperature, occupancy, CO₂, and air quality. Each building acts as a zone with its own gateway, all synchronized to a central IN-CSE.

Value Added:

• Potential to scale from a single building to an entire campus
• Central dashboard with building-level or admin-level permissions
• Compatible with mixed sensor vendors and technologies
• Ideal for sustainability initiatives and energy optimization

3. Industrial Multi-Zone Equipment Tracking

Factories contain dozens of machines, each needing status monitoring, vibration sensing, or thermal safety checks. Sensors installed on equipment report to nearby gateways, while the system maintains a global view across the entire plant.

Value Added:

• Zone-based gateways isolate heavy traffic
• IN-CSE provides plant-wide visibility
• FlexContainers support structured industrial data models
• Mobile tool or asset tracking via RSSI-based handover

4. Commercial Building Automation (Multi-Floor or Multi-Site)

Large office buildings can deploy sensors for occupancy, lighting, temperature, or air quality across many floors. Each floor runs its own gateway, and building owners access a centralized dashboard.

Value Added:

• Unified monitoring across multiple floors
• Easier expansion to new offices or buildings
• ACP allows tenant-specific or staff-specific access
• Low-latency operation within a local network

5. Research Labs & Multi-Room Test Facilities

Laboratories often need controlled environments with precise monitoring. Sensors can track temperature, humidity, chemical levels, freezer levels, and more. As labs expand or add new rooms, the oneM2M hierarchy scales effortlessly.

Value Added:

• Scales to many rooms or specialized chambers
• Real-time alerts and lab-specific dashboards
• Supports privacy for restricted-access projects
• Easily integrates new sensor types

6. Asset Tracking & Mobile Device Networks

In environments where devices or equipment frequently move, such as hospitals, warehouses, or large campuses, the BLE handover becomes essential. Sensors broadcast RSSI values to determine which gateway should manage them.

Value Added:

• Smooth transitions between gateways
• Continuous monitoring of moving assets
• Scalable to hundreds of mobile devices

Summary

This project demonstrates how the oneM2M standard can be used to build a scalable, multi-gateway IoT ecosystem that could be grown from a few sensors to entire buildings or campuses. By combining BLE peripherals, distributed gateway nodes, a hierarchical IN-CSE, and a dynamic Django CloudAppAE dashboard, the system delivers real-time monitoring, automatic device discovery, role-based access control, and seamless device mobility through BLE RSSI-based handover.

While our prototype specifically focuses on demonstrating BLE-based handover across multiple gateways, the underlying architecture is general-purpose. The same scalable, multi-gateway oneM2M design can be applied to hospitals, smart campuses, industrial facilities, research labs, commercial buildings, or any environment that requires secure, low-latency IoT coordination at scale.

Thanks to a modular device layer, zone-based gateways, and consistent oneM2M data modeling, the system remains easy to expand, vendor-neutral, and future-proof. With its strong foundation in standardized data flow, local network reliability, and privacy-aware access control, this project provides a blueprint for next-generation large-scale IoT deployments across virtually any domain.

Project Acknowledgements

Project Sponsor

We would like to thank Penn State University for its continued support and academic resources, and Exacta Global Smart Solutions for providing critical materials and technical assistance. Their combined contributions were instrumental in completing this project.

Nordic Devices

We extend our thanks to Nordic Semiconductor for providing the nRF7002 Development Kits, nRF9151 Development Kits, and Thingy:91 X Devices. These resources have supported our current work and will continue to be used as development progresses.

Demo Video: