Secure QR-Code Attendance over RPL-Based Low-Power IoT Networks: Security Analysis and Scalability Evaluation in Contiki-NG/Cooja

1. Introduction

Low-power Internet of Things (IoT) networks increasingly carry transactions whose correctness matters at the application layer, not only packets whose delivery matters at the network layer. This distinction is important for wireless sensor networks (WSNs) and low-power and lossy networks (LLNs), where modest processors, limited memory, shared radio channels, and restricted energy budgets constrain both communication and security design [1,2,3]. A protection mechanism that adds state, cryptographic operations, packet bytes, or retransmissions can strengthen assurance while also consuming scarce resources. Conversely, a network that is economical but unreliable can undermine an otherwise correct application because a legitimate transaction that never reaches the validation service cannot be accepted.

RPL was standardised for IPv6 routing in LLNs and remains a central protocol for constrained multi-hop IoT deployments [4]. Contiki-NG and Cooja provide a practical environment for studying such systems across routing, radio, and application behaviour [5,6]. Comparative benchmarking of low-end IoT operating systems also places Contiki-NG within the broader resource-constrained software landscape [7]. Recent work illustrates the security–performance coupling of RPL networks: replayed control traffic can disturb routing behaviour [8], Hello Flood attacks can degrade delivery and power-related metrics [9], and energy-aware parent selection introduces additional routing logic in exchange for resource and quality-of-service benefits [10]. These observations motivate application studies in which network behaviour and security outcomes are evaluated together.

QR-code attendance is a useful example because the visible interaction is simple while the trust problem is not. In a lecture, laboratory, workplace training session, or smart-building event, many participants may submit attendance within a short interval. A copied image can be forwarded to an absent participant, a previously accepted transaction can be retransmitted, an identifier can be altered, and legitimate traffic can be lost or delayed during a burst. The system therefore has two simultaneous obligations: the communication path must carry legitimate messages with acceptable delay, and the application must avoid turning repeated or invalid messages into durable attendance records.

Recent attendance systems have used hashing and public-key cryptography [11], dynamic QR values and UUIDs [12], additional identity checks [13], and QR/GPS combinations [14]. These approaches primarily strengthen the user-facing attendance workflow. By contrast, RPL-security research generally concentrates on control-plane or routing attacks rather than the semantic success of an attendance transaction [15,16]. The present study connects these two research directions by evaluating a post-scan QR attendance transaction over an RPL-based LLN and by keeping network delivery, application acceptance, and replay rejection as distinct but related observations.

The implemented replay-resistance mechanism is intentionally transparent. When a transaction passes the token and attendance rules, the server retains sufficient transaction state for the active attendance context. A later byte-equivalent or logically duplicate submission that maps to an already accepted event fails the duplicate/freshness predicate and is rejected. This mechanism is not presented as a new cryptographic primitive, nor is it equivalent to proving device possession of a nonce, one-time password (OTP), or time-based secret. Time-based tokens, nonces, and OTPs generate or validate freshness evidence; the mechanism studied here focuses on server-side prevention of a second durable attendance record for the same accepted logical event. The research contribution lies in analysing that application property together with RPL-network scalability and in explicitly separating what the baseline proves from properties that require cryptographic protection.

1.1. Research Challenges, Gaps, and Novelty

The first challenge is the difference between a visible QR value and an authenticated transaction. A QR image can be public or copied, so trust should ultimately be associated with the response sent to the server rather than secrecy of the visual code itself. The second challenge is duplicate state: replay resistance requires enough short-lived server state to recognise an already accepted logical event without allowing the cache to grow indefinitely. The third challenge is burst scalability. Attendance requests often arrive within a narrow window; increasing the number of active motes may raise contention, packet loss, and delay before validation is even reached. The fourth challenge is resource accountability. Terms such as “lightweight” and “energy efficient” should be supported by memory, CPU, radio, or energy measurements rather than inferred from a small algorithm alone.

The related literature leaves a gap at the boundary between these concerns. Secure attendance studies generally evaluate the application, authentication method, or mobile interface, while RPL-security studies evaluate routing behaviour or attack detection. Few studies report, within one attendance-oriented RPL experiment, both network-level delivery and application-level acceptance while also quantifying application replay rejection. A second gap concerns claim scope: a replay check is sometimes discussed as if it implied general authentication, even though QR cloning, message modification, node impersonation, gateway compromise, and routing attacks require different controls. A third gap is experimental traceability. Scalability claims are stronger when the measured range, unavailable metrics, and statistical limits are made explicit instead of being filled with assumed simulator defaults.

The novelty of this study is therefore methodological and architectural rather than cryptographic. First, it treats the QR scan as the start of a networked attendance transaction and evaluates PDR, loss, delay, ASR, and replay rejection along the same end-to-end path. Second, it formalises the baseline acceptance rule and shows the precise condition under which an exact replay is rejected. Third, it distinguishes the validated replay property from unimplemented properties such as authenticated payload integrity, secure enrolment, routing-layer defence, and measured energy efficiency. Fourth, it reports the demonstrated scaling envelope up to 50 motes without extrapolating a maximum deployment size that was not experimentally reached. Finally, it defines a concrete extension using NIST-standardised Ascon authenticated encryption, secure device enrolment, repeated runs, energy instrumentation, and hardware validation [17,18].

1.2. Research Questions and Key Contributions

The research questions were formulated from two issues that emerge from the problem addressed in this study. First, an attendance transaction carried over a low-power and lossy network depends on more than the correctness of the application logic; changes in network scale can affect whether the transaction reaches the receiving application within an acceptable time and is ultimately recorded. Examining network performance without considering the resulting attendance outcome would therefore provide only a partial view of system behaviour. Second, rejecting a repeated transaction is an important security property, but it should not be confused with complete authentication or end-to-end protection. The evaluation must consequently establish what the implemented validation mechanism actually demonstrates while identifying the security properties that remain outside the present implementation. These considerations motivate the following research questions:

• RQ1: What relationship exists between network scale, packet delivery, communication delay, and successful attendance recording in the evaluated RPL-based low-power IoT network?
• RQ2: What evidence does the implemented token and duplicate-validation mechanism provide for replay resistance, and what additional safeguards are required before stronger authentication and energy-efficiency claims can be supported?

Justification for RQ1. The first research question connects communication behaviour with the outcome that is meaningful to the attendance application. Increasing the number of participating motes can influence contention, packet delivery, packet loss, and delay, but these network effects become practically important only when they affect the completion of attendance transactions. RQ1 therefore examines packet delivery ratio (PDR), packet loss, end-to-end delay, and attendance success rate (ASR) together. This enables the evaluation to determine whether application-level performance follows changes observed in the underlying RPL network rather than treating network and application metrics as unrelated measurements.

Justification for RQ2. The second research question defines the security boundary of the present work. The implemented mechanism uses token checking and duplicate/freshness validation to determine whether a received attendance transaction should be accepted. The recorded replay experiments provide evidence about repeated submissions under the evaluated conditions, but they do not by themselves demonstrate cryptographic message integrity, secure device identity, resistance to routing manipulation, or measured energy efficiency. RQ2 was therefore formulated to assess the replay property that can be supported by the available evidence while making clear which additional mechanisms and experiments would be necessary for a stronger end-to-end security claim.

The study makes four principal contributions:

1.

An integrated low-power attendance architecture. The study models QR-based attendance as an end-to-end network transaction rather than as an isolated QR-scanning operation. The architecture separates attendance initiation, RPL-based low-power communication, gateway delivery, and server-side validation. This separation makes it possible to identify where communication failure and application rejection occur and provides a clearer basis for evaluating the interaction between network and attendance behaviour.

2.

A clearly bounded replay-resistance analysis. The work defines the conditions under which an attendance transaction is accepted and examines how token and duplicate/freshness checks respond when an already accepted transaction is submitted again. The security contribution is deliberately limited to the property demonstrated by the implementation and recorded replay experiments. The accompanying threat analysis also distinguishes this result from stronger properties such as cryptographic authentication, message-integrity protection, node impersonation resistance, and routing-layer security.

3.

An application-aware scalability evaluation. The experimental study evaluates the architecture with 5, 20, and 50 motes in Contiki-NG/Cooja and considers both network and application outcomes. Packet delivery ratio, packet loss, end-to-end delay, and attendance success are analysed together, allowing changes in low-power network performance to be related directly to the success of the attendance service. The evaluation therefore provides a measured scalability range without extrapolating an unsupported maximum network capacity.

4.

A deployment-oriented security and validation pathway. Beyond reporting the current simulation results, the study identifies the controls and measurements needed to progress toward a more complete operational system. These include authenticated transaction protection, secure device enrolment, routing-aware defence, repeated experiments across independent simulation runs, direct energy and memory measurements, and hardware-based validation under realistic wireless conditions. This contribution establishes a practical baseline against which the performance and resource cost of future security extensions can be assessed.

Together, these contributions position the work as an evaluation of how lightweight attendance validation interacts with RPL-based communication, rather than as a claim of a new cryptographic primitive. The resulting framework links application success, network scalability, and a precisely defined replay property while keeping stronger security and energy-efficiency claims within the limits of experimentally demonstrated evidence. “`The remainder of the paper is organised as follows. Section 2 provides the technical background and motivates the choice of QR interaction for the target setting. Section 3 reviews recent RPL-security, lightweight-authentication, and secure-attendance studies and positions the contribution. Section 4 presents the architecture, protocol semantics, and threat model. Section 5 defines the simulation methodology, metrics, and statistical treatment. Section 6 reports the measured results. Section 7 interprets security, scalability, and deployment implications, Section 8 states the validity limits, Section 8.2 defines the next validation stage, and Section 9 concludes the paper.

2. Technical Background

The attendance architecture operates over a constrained IPv6 communication stack in which short application messages are transported through a low-power wireless network. IEEE 802.15.4 provides the low-rate link, 6LoWPAN adapts IPv6 to constrained frames, RPL Lite supplies routing toward the root or gateway, CSMA coordinates medium access, and UDP carries the attendance payload. RPL is especially relevant because a larger population can increase contention and forwarding activity even when the application message itself is small [4,5]. The study therefore evaluates the attendance service as a networked application rather than treating the QR interaction as an isolated web or mobile function.

2.1. QR Attendance as a Network Transaction

The simulation begins after visual recognition. A successful scan is abstracted into an attendance message containing the information needed by the validation service, such as participant identity, session context, timing/freshness information, and a token or transaction identifier. This boundary avoids attributing camera or QR-decoding accuracy to the network experiment. It also exposes the security-relevant event: the server must decide whether a delivered message is acceptable and whether the same logical attendance event has already been recorded.

Network delivery and attendance acceptance are deliberately separated. A legitimate message may fail before reaching the application because of packet loss, while a successfully delivered message may still be rejected by the attendance rules. This motivates the joint use of PDR and ASR later in the paper. A small PDR–ASR gap suggests that application success is tracking network delivery; a widening gap would indicate additional rejection or application-side failure after delivery.

2.2. Why QR Codes for the Target Setting?

QR codes are attractive when the deployment already has displays and camera-equipped phones or terminals because no dedicated contactless reader is required. A session value can also be rotated in software, making QR suitable for short attendance windows. These advantages do not make QR intrinsically secure: the image is observable and can be photographed or forwarded. The appropriate design assumption is therefore that the visual code is a challenge or session reference, while authenticity and freshness are enforced in the response transaction.

Table 1 contrasts QR interaction with common alternatives at an engineering level. NFC and RFID provide convenient proximity-based interactions but normally introduce dedicated tags or reader infrastructure; BLE supports passive proximity but adds beacon, scanning, and radio-management complexity; a mobile-identity-only approach can provide strong account integration but depends more heavily on enrolment and backend identity services. QR remains useful where low deployment cost and easy session rotation are priorities, provided that visual copying is treated as an expected attack surface rather than ignored [11,13,14].

2.3. Replay Semantics and Lightweight Security

Replay can occur at several layers. RPL control-message replay manipulates routing state and can affect availability or topology [8]; application replay resubmits an attendance event that was previously valid. The two attacks share the notion of stale information being reused but differ in object, consequence, and mitigation point. The present quantitative experiment addresses the application case. RPL attacks remain part of the broader threat model and require routing-aware controls.

The baseline uses deterministic token, authorisation, and duplicate checks rather than authenticated encryption. This design is small in logical complexity, but “lightweight” should not be interpreted as measured energy efficiency. NIST SP 800-232 makes Ascon-AEAD128 a relevant future protection mechanism for constrained devices because it provides authenticated encryption in a standardised lightweight family [17]. Secure enrolment is equally important because a cryptographic key must be associated with a trusted device or user before origin authentication can be claimed [18,19]. These distinctions are carried into the security model in Section 4.

3. Related Work and Research Positioning

Research relevant to this study falls into three closely connected areas: RPL security, lightweight authentication for constrained devices, and secure digital attendance. The literature has become substantially richer during 2024–2026, but the three areas are still usually evaluated with different objectives and metrics. The following review therefore concentrates on how each body of work informs the security or scalability claim made in this paper rather than treating all reported numerical results as directly comparable.

RPL security studies demonstrate that network-layer attacks can undermine application availability even when server logic is correct. Albinali and Azzedin empirically examine replay attacks against RPL and show that stale routing information can disrupt low-power networks [8]. Hkiri et al. evaluate Hello Flood behaviour in Cooja and report effects across delivery, delay, throughput, ETX, and power-related measurements [9]. Prajapati et al. provide a broad 2025 survey of RPL attacks and countermeasures [15]. Learning-based studies include black-hole detection by Ayoub et al. and an ensemble RPL detector by Etheridge and Anu, while Panda and Muthuraman extend simulation-driven analysis to multiclass routing-attack detection [16,20,21]. These studies establish that routing security cannot be inferred from an application-layer replay check. The resource cost of protection is equally important. Garcia Ribera et al. evaluate an IDS for RPL-based IoT and include overhead considerations [22]. Mokrani et al. propose LEA-RPL and analyse routing with energy and quality-of-service objectives [10]. Cross-layer studies further illustrate that security, routing decisions, and resource use interact across protocol layers [23,24]. A field-oriented WSN implementation by Matos et al. provides a useful contrast because energy is measured as part of the deployed low-power system rather than inferred from protocol simplicity [25]. This supports a conservative interpretation of the present work: PDR and delay can describe communication behaviour, but they cannot substitute for direct energy measurement.

Recent lightweight-security literature offers concrete mechanisms for strengthening the attendance transaction beyond the baseline. Broader multi-layer security research also reinforces the need to distribute controls across device, network, and application boundaries rather than treating a single rule as complete IoT protection [26]. Guşiţa et al. review lightweight cryptography and communication protection for IoT edge systems [2], and Haider et al. survey resource-efficient lightweight and hybrid cryptography [3]. NIST SP 800-232 standardises Ascon-based lightweight cryptographic functions, including Ascon-AEAD128 [17]. Fedrecheski et al. address zero-touch enrolment for constrained devices [18], while PUF-based work demonstrates how device-specific authentication can be evaluated formally and practically [19,27]. These mechanisms solve problems that duplicate detection does not: message integrity, key-bound origin authentication, and device identity.

Secure-attendance research has meanwhile moved beyond static QR registration. Irawan et al. combine RSA and hashing and explicitly examine a security–resource trade-off [11]. Annurrahma et al. use dynamic QR values with UUIDv4 and contextual validation [12]. Oyerinde et al. develop a secure higher-education QR attendance workflow [13], while Siregar et al. combine dynamic QR codes with GPS geofencing [14]. Alabi et al. and Abirami and Rohann provide additional recent examples of enhanced QR attendance designs [28,29]. The common direction is to reduce proxy attendance and code reuse, but these studies do not primarily investigate an attendance transaction traversing an RPL LLN under increasing node population.

The distinction between the present mechanism and conventional freshness schemes is important. A time-based token, nonce challenge, or OTP attempts to make each accepted exchange dependent on new freshness material. The baseline studied here does not claim a novel token-generation algorithm. Instead, its replay property is created at the acceptance boundary: once a logical attendance transaction has been accepted during the active context, the server-side state prevents that event from creating a second record. This is weaker than cryptographically binding a nonce to an enrolled device, but it is directly testable in the recorded scenarios and can be strengthened later without changing the network/application separation used for evaluation.

Table 2. Positioning of representative recent studies against the security and scalability dimensions examined here.

Reference	Primary focus	RPL/LLN	Replay-specific test	Energy measured	Research position relative to this work
Albinali and Azzedin [8]	RPL replay attacks	Yes	Routing replay	No	Establishes replay risk at the routing layer, not attendance semantics.
Hkiri et al. [9]	Hello Flood impact	Yes	No	Yes	Demonstrates multi-metric attack evaluation in Cooja.
Mokrani et al. [10]	Energy-aware RPL	Yes	No	Yes	Provides a routing/energy direction for a stronger follow-on design.
Panda and Muthuraman [16]	Multiclass RPL attack detection	Yes	Multiple routing attacks	Not central	Broader network security than the deterministic attendance checks.
Irawan et al. [11]	QR attendance authentication	No	Application security	Yes	Examines cryptographic attendance overhead without RPL scaling.
Annurrahma et al. [12]	Dynamic QR attendance	No	Code/session reuse mitigation	No	Strengthens freshness/context at the application layer.
Siregar et al. [14]	Dynamic QR + GPS	No	Proxy-resistance oriented	No	Adds contextual evidence but not LLN transport analysis.
Lim et al. [19]	Lightweight device authentication	No	Protocol-level	Yes	Illustrates formal authentication and constrained-device evaluation.
This study	Attendance integrity + LLN scaling	Yes	38 recorded application replays	No	Jointly relates delivery, delay, ASR, and exact replay rejection over an RPL-based attendance path.

Table 2. Positioning of representative recent studies against the security and scalability dimensions examined here.

Reference	Primary focus	RPL/LLN	Replay-specific test	Energy measured	Research position relative to this work
Albinali and Azzedin [8]	RPL replay attacks	Yes	Routing replay	No	Establishes replay risk at the routing layer, not attendance semantics.
Hkiri et al. [9]	Hello Flood impact	Yes	No	Yes	Demonstrates multi-metric attack evaluation in Cooja.
Mokrani et al. [10]	Energy-aware RPL	Yes	No	Yes	Provides a routing/energy direction for a stronger follow-on design.
Panda and Muthuraman [16]	Multiclass RPL attack detection	Yes	Multiple routing attacks	Not central	Broader network security than the deterministic attendance checks.
Irawan et al. [11]	QR attendance authentication	No	Application security	Yes	Examines cryptographic attendance overhead without RPL scaling.
Annurrahma et al. [12]	Dynamic QR attendance	No	Code/session reuse mitigation	No	Strengthens freshness/context at the application layer.
Siregar et al. [14]	Dynamic QR + GPS	No	Proxy-resistance oriented	No	Adds contextual evidence but not LLN transport analysis.
Lim et al. [19]	Lightweight device authentication	No	Protocol-level	Yes	Illustrates formal authentication and constrained-device evaluation.
This study	Attendance integrity + LLN scaling	Yes	38 recorded application replays	No	Jointly relates delivery, delay, ASR, and exact replay rejection over an RPL-based attendance path.

The table highlights the intended novelty boundary. The paper does not claim that duplicate checking supersedes dynamic tokens, OTPs, authenticated encryption, or RPL intrusion detection. Its contribution is a reproducible evaluation framework in which the success of the attendance service is interpreted alongside the behaviour of the constrained network carrying it. That framework exposes where stronger security controls should be inserted and, equally importantly, which additional measurements are needed to establish their cost.

4. System Architecture and Security Model

The proposed system combines QR-based attendance generation with low-power communication and server-side validation. A student device initiates an attendance transaction, which is carried through the RPL-based network toward the gateway and attendance application. The architecture separates message generation, network transport, and final attendance acceptance so that communication failures can be distinguished from application-level rejection.

The security model focuses on the transaction after the QR interaction has taken place. Before an attendance record is accepted, the received message is checked against the expected token, session context, and duplicate or freshness state. This design allows replayed transactions to be identified within the evaluated scenarios while keeping the security claim limited to the behaviour that is directly supported by the implementation.

The model also recognises that replay protection alone does not provide complete end-to-end security. Attacks involving message modification, node impersonation, routing manipulation, physical device compromise, or gateway compromise require additional controls such as authenticated payload protection, secure enrolment, and routing-aware security mechanisms. These boundaries are considered explicitly in the threat analysis that follows. “`

4.1. Layered Architecture and Transaction Path

Figure 1 separates the system into an attendance-source layer, an RPL-based communication layer, and a gateway/application layer. A student mote represents the post-scan client: visual recognition has already occurred and the device generates an attendance transaction for the active session. The transaction then traverses the low-power IPv6 stack toward the gateway, where server-side rules determine whether the event becomes a durable attendance record. This separation is useful because successful packet reception is necessary but not sufficient for successful attendance.

The communication path uses IEEE 802.15.4, CSMA, 6LoWPAN, IPv6, RPL Lite, and UDP. RPL provides the route toward the root/gateway, while the application retains the attendance state required for validation. The gateway is therefore a trust boundary: network delivery ends at the receiving service, but acceptance requires application checks. A future deployment can preserve this boundary while replacing the baseline token rule with authenticated encryption and securely enrolled device keys.

Figure 2 shows the logical message sequence. The client creates a transaction, the low-power network carries it to the gateway, validation is applied, and only an accepted event is committed. Retransmission or repeated delivery must not create an additional record for the same logical event.

4.2. Acceptance Rule and Replay Property

Let an attendance transaction be represented as

$$m_i=\langle u_i,s_i,t_i,x_i\rangle ,$$

(1)

where $u_i$ is the participant identity, $s_i$ is the attendance-session context, $t_i$ denotes freshness-related information available to the application, and $x_i$ denotes the token or transaction identifier. The server evaluates token validity, attendance authorisation, and duplicate state. A compact acceptance predicate is

$$\mathcal{A}\left(m_i\right)=V_{tok}\left(m_i\right)\wedge V_{auth}\left(m_i\right)\wedge \left[h\left(m_i\right)\notin {\mathcal{S}}_{s_i}\right],$$

(2)

where ${\mathcal{S}}_{s_i}$ is the set of already accepted logical transaction identifiers for session $s_i$. When Equation (2) is true, the record is committed and the corresponding identifier is added to ${\mathcal{S}}_{s_i}$.

This gives a bounded replay property. If a transaction $m_i$ has been accepted and its identifier remains in ${\mathcal{S}}_{s_i}$, then a later exact replay of $m_i$ during the same retained state interval fails the final predicate and cannot create a second accepted record. The argument depends on server state remaining intact and on the replay mapping to the same duplicate identifier. It does not prove that an attacker cannot construct a modified transaction with a new identifier, forge another user’s credentials, alter a message in transit, or compromise the server. Those properties require cryptographic integrity, origin authentication, enrolment, and platform protection.

Figure 3 presents the same logic as an operational validation path.

4.3. Threat Model and Attack Surfaces

The threat model distinguishes outsider, insider, and physical-compromise cases. An outsider is assumed able to observe a displayed QR code, capture or reconstruct application traffic within radio reach, submit unauthorised identifiers, and replay previously observed transactions. An enrolled insider possesses a valid identity or device but may attempt to reuse a legitimate attendance event, submit attendance on behalf of another user, or exploit a copied QR value. A physical-compromise adversary may obtain a device and extract locally stored material; this case is considered a deployment risk but is not experimentally defended by the baseline. Gateway compromise and backend administrative compromise are also outside the measured defence boundary because a compromised validation service can alter the acceptance state directly.

The main attack surfaces are the visual QR channel, the client/mote, the IEEE 802.15.4/6LoWPAN/RPL communication path, the gateway, and the attendance backend. Table 3 maps representative attacks to what the baseline can and cannot establish. This prevents the observed replay result from being extended to attacks for which no corresponding protection was implemented.

A formal protocol tool such as ProVerif, Scyther, AVISPA, or Tamarin would be appropriate once the proposed authenticated transaction format and key-establishment protocol are fully specified. Applying such a tool to the present non-cryptographic duplicate rule would overstate what is being verified. The current paper therefore provides a formal acceptance predicate and a bounded replay argument, while identifying machine-checked authentication/freshness proofs as a requirement for the cryptographic extension. Recent PUF-based work illustrates the value of combining formal protocol analysis with constrained-device measurements [19].

Figure 4. Application-level replay and unauthorised-identity workflows considered by the security model. Quantitative attack counts are available for replay; unauthorised-identity behaviour is therefore interpreted qualitatively.

Figure 4. Application-level replay and unauthorised-identity workflows considered by the security model. Quantitative attack counts are available for replay; unauthorised-identity behaviour is therefore interpreted qualitatively.

5. Simulation Methodology and Experimental Evidence

The experimental evaluation was designed to examine how the proposed attendance mechanism behaves when operated over an RPL-based low-power and lossy network. Contiki-NG and the Cooja simulator were used to model the communication environment, allowing network behaviour and application-level attendance outcomes to be examined under increasing numbers of participating motes. The methodology focuses on measurable indicators that are directly supported by the recorded experiments, including packet delivery ratio, packet loss, end-to-end delay, attendance success rate, and replay-rejection behaviour. Particular attention was given to separating observed experimental evidence from parameters that were not directly measured during the simulations. This distinction is important for maintaining reproducibility and avoiding conclusions based on assumed simulator defaults. The following subsections therefore describe the evaluated network configurations, recorded performance measures, security-event observations, and the procedures used to interpret the resulting data. “`

5.1. Contiki-NG/Cooja Setup

The evaluation uses Contiki-NG and Cooja, a combination widely used for observing constrained-network routing and application behaviour [5,6]. Three recorded attendance-network sizes are available: 5, 20, and 50 student motes communicating toward a central gateway/server. The network size is the controlled scalability factor. The accompanying Cooja configuration views show random mote placement within the displayed coordinate field for the recorded scenarios; however, the physical unit represented by that field, per-run coordinates, radio range, and route-depth distribution are not available as numerical logs. Those quantities are therefore not reconstructed from default Cooja settings.

Figure 5. Contiki-NG/Cooja workflow used to configure the attendance scenarios and observe communication and application outcomes.

Figure 5. Contiki-NG/Cooja workflow used to configure the attendance scenarios and observe communication and application outcomes.

Table 4 shows the configuration information used in the analysis. Values that were not directly recorded are marked as unmeasured rather than replaced by plausible defaults. This distinction is important because radio model, retry timing, traffic schedule, topology depth, and energy instrumentation can materially change LLN results.

5.2. Parameter Scope and Reproducibility

The QR generation frequency, token lifetime, application timeout, and cryptographic parameters are not treated as measured independent variables in the current simulation because the experiment begins at the post-scan transaction boundary and the baseline does not implement authenticated encryption. Assigning concrete values after the fact would create an artificial parameter set unrelated to the recorded outcomes. For a deployment-oriented extension, the QR/session lifetime should be shorter than the attendance window and enforced at the server; the retransmission timeout should be defined independently from transaction freshness so that a legitimate retry cannot silently create a second record; and the authenticated-payload configuration should specify nonce construction, tag size, key lifetime, and enrolment procedure. Ascon-AEAD128 is proposed for that extension because it is standardised for constrained devices in NIST SP 800-232 [17].

A fully reproducible rerun would additionally require executable application source, the complete Cooja scenario files, simulator/build version, topology and radio parameters, random seeds, traffic schedule, and raw per-run logs. These materials are not available as a complete executable set for the present evaluation. Consequently, this paper does not report newly invented Cooja scenarios beyond the recorded 5-, 20-, and 50-mote cases. All quantitative tables and plots in Section 6 are based on the recorded experimental values or transparent mathematical transformations of those values.

5.3. Evaluation Metrics

Let $N_{tx}$ and $N_{rx}$ denote transmitted and received application packets. Packet delivery ratio and packet loss are

$$\begin{array}{cc}\hfill \mathrm{PDR}(\%)& ={\displaystyle \frac{N_{rx}}{N_{tx}}}\times 100,\hfill \end{array}$$

(3)

$$\begin{array}{cc}\hfill \mathrm{Loss}(\%)& =100-\mathrm{PDR}.\hfill \end{array}$$

(4)

For successfully delivered packet j, with send and receive times $t_{tx}^{\left(j\right)}$ and $t_{rx}^{\left(j\right)}$, average end-to-end delay is

$$\overline{D}={\displaystyle \frac{1}{N_{rx}}}{\displaystyle \sum _{j=1}^{N_{rx}}}\left(t_{rx}^{\left(j\right)}-t_{tx}^{\left(j\right)}\right).$$

(5)

If $N_{int}$ attendance events are intended and $N_{acc}$ are durably accepted, attendance success rate is

$$\mathrm{ASR}(\%)={\displaystyle \frac{N_{acc}}{N_{int}}}\times 100.$$

(6)

For replay testing, with $N_{rep}$ injected replay events and $N_{rej}$ rejected events,

$$\mathrm{RRR}(\%)={\displaystyle \frac{N_{rej}}{N_{rep}}}\times 100.$$

(7)

The delivery-to-application gap is also reported as

$$G_{PA}=\mathrm{PDR}-\mathrm{ASR},$$

(8)

which helps determine whether application success changes broadly in step with network delivery.

5.4. Statistical Treatment and Metric Availability

Only aggregate PDR, loss, delay, and ASR values are available for each network size; repeated independent runs, per-packet samples, and variances are not available. Confidence intervals or significance tests for those metrics would therefore require invented distributions and are not reported. Replay testing is different because event counts are available. Exact two-sided Clopper–Pearson 95% intervals are consequently reported for replay rejection, including an aggregate interval for 38 successful rejections out of 38 attempts.

Table 5 makes the reviewer-requested metric coverage explicit. Throughput, direct energy, and memory overhead are valuable scalability metrics, but no measured values for them are present in the recorded experiment; they are therefore specified as requirements for the extension rather than populated with assumed numbers.

6. Results and Evaluation

This section examines the behaviour of the proposed attendance architecture across the evaluated RPL-based network configurations. The analysis considers both communication-level performance and application-level outcomes so that changes in network behaviour can be related directly to the successful completion of attendance transactions. The reported results are based on the measurements obtained from the evaluated Contiki-NG/Cooja scenarios rather than on assumed or extrapolated values. The evaluation focuses on packet delivery ratio, packet loss, end-to-end delay, attendance success rate, and replay-rejection behaviour. Particular attention is given to how these measures change as the number of participating motes increases and whether deterioration at the network layer is reflected in the attendance application. Replay experiments are analysed separately to determine how consistently repeated transactions are rejected under the recorded test conditions. Together, these results provide evidence of the system’s observed scalability and security behaviour while keeping the interpretation within the limits of the available experimental data.

6.1. Network and Application Outcomes

Table 6 reports the recorded values used throughout the analysis. Increasing the network from 5 to 50 motes reduces PDR from 98.2% to 91.7%, increases packet loss from 1.8% to 8.3%, raises average end-to-end delay from 12 to 37 ms, and lowers ASR from 96.5% to 89.4%. These results show a gradual rather than abrupt degradation over the evaluated range.

Figure 6 plots PDR and ASR on the same scale. The two measures remain close at each network size, suggesting that application success broadly follows the ability of the network to deliver the underlying transaction rather than diverging sharply because of application rejection.

The PDR–ASR gaps are 1.7, 1.6, and 2.3 percentage points for 5, 20, and 50 motes, respectively. These values are small relative to the overall delivery rates. Because per-transaction traces are unavailable, the relationship should be interpreted as an observed association rather than as a causal decomposition of every failed attendance event.

6.2. Packet Loss and Delay Scaling

Packet loss rises by 6.5 percentage points between the smallest and largest scenarios, matching the absolute PDR decrease. Figure 7 shows the trend. The increase is consistent with greater stress on a shared low-power medium, but no collision, queue-overflow, parent-change, or retransmission counters are available to identify a single mechanism. The result therefore establishes that reliability falls as the evaluated population grows; it does not assign the loss to an unmeasured cause.

Average delay increases from 12 to 37 ms, a 25 ms absolute increase and approximately 208.3% relative increase from the 5-mote baseline. Figure 8 shows this growth. Although the proportional change is large because the baseline is small, the measured average remains below 40 ms at 50 motes. The observed 50-mote point therefore remains responsive for the tested workload, but the data do not identify a saturation point beyond that scale.

Table 7. Derived descriptive changes in network and application performance from 5 to 50 motes.

Performance Measure	Change (5–50 Motes)	Interpretation
Packet delivery ratio (PDR)	$-6.5$ percentage points ($-6.62\%$ relative)	Delivery decreases with network size, while remaining above 90% at the largest evaluated point.
Packet loss	$+6.5$ percentage points	Loss increases as the network grows; causal attribution requires per-run link and queue counters that are not available.
Average end-to-end delay	$+25$ ms ($+208.3\%$ relative)	Delay has the largest proportional change but remains below 40 ms in the 50-mote scenario.
Attendance success rate (ASR)	$-7.1$ percentage points ($-7.36\%$ relative)	Application success decreases at a rate close to the decline in PDR.
PDR–ASR gap	1.7–2.3 percentage points	Application success remains close to network delivery throughout the tested scale.

Table 7. Derived descriptive changes in network and application performance from 5 to 50 motes.

Performance Measure	Change (5–50 Motes)	Interpretation
Packet delivery ratio (PDR)	$-6.5$ percentage points ($-6.62\%$ relative)	Delivery decreases with network size, while remaining above 90% at the largest evaluated point.
Packet loss	$+6.5$ percentage points	Loss increases as the network grows; causal attribution requires per-run link and queue counters that are not available.
Average end-to-end delay	$+25$ ms ($+208.3\%$ relative)	Delay has the largest proportional change but remains below 40 ms in the 50-mote scenario.
Attendance success rate (ASR)	$-7.1$ percentage points ($-7.36\%$ relative)	Application success decreases at a rate close to the decline in PDR.
PDR–ASR gap	1.7–2.3 percentage points	Application success remains close to network delivery throughout the tested scale.

These results answer RQ1 within the measured range. Increasing population is associated with lower delivery and ASR and with higher delay, but the service remains operational at 50 motes. The study does not claim that 50 is the maximum practical network size; it is the largest demonstrated operating point available in the experiment.

6.3. Replay-Rejection Analysis

Replay testing provides the strongest event-level security evidence. Table 8 reports both the observed rates and exact confidence intervals. The observed rejection rate is 100% in each scenario, but the intervals are intentionally shown because a finite number of successes does not prove perfect rejection for all future traffic. Across all 38 replay attempts, the exact two-sided 95% interval is 90.75–100%.

Figure 9. Recorded replay injections and rejections. The plotted bars use the observed event counts only; no interpolated attack data are introduced.

Figure 9. Recorded replay injections and rejections. The plotted bars use the observed event counts only; no interpolated attack data are introduced.

The replay result is consistent with the acceptance rule in Equation (2): once the transaction identifier is present in the retained duplicate state, resubmission of the same logical event fails the novelty check. This answers the demonstrated part of RQ2. It does not establish protection against a modified payload that produces a different identifier, a valid credential used by an imposter, a compromised endpoint, or RPL control-plane manipulation. Those residual cases are addressed in the threat matrix and deployment extension.

Unauthorised or spoofed identity behaviour is represented by the application workflow, but a complete attempt/rejection count is not available for that class. Reporting a numerical spoofing-detection percentage would therefore be unsupported. The defensible conclusion is qualitative: the baseline contains an authorisation predicate intended to reject identity/session combinations that do not satisfy the attendance rule; cryptographic proof of identity remains outside the measured design.

6.4. Demonstrated Deployment Envelope

Table 9 states the strongest deployment claim supported by the measured data. This form is preferable to inferring a maximum population from three aggregate points. The 50-mote scenario demonstrates that the tested workload can sustain 91.7% PDR, 37 ms average delay, and 89.4% ASR. Whether a real deployment can support 75, 100, or several hundred simultaneous clients cannot be answered without additional network sizes, repeated seeds, and offered-load experiments.

7. Discussion and Results Interpretation

The results show why attendance correctness should not be reduced to either a network metric or an application-security metric. As the number of motes rises, PDR and ASR decline together, while the small PDR–ASR gap indicates that the application continues to convert most delivered legitimate traffic into accepted attendance records. At the same time, every recorded exact replay is rejected. These observations describe two different properties: communication remains usable over the tested scaling range, and the retained duplicate state prevents the same accepted logical transaction from being counted twice. The security boundary is equally important. The baseline does not make the QR image secret, and it does not cryptographically bind an observed QR value to a particular device. A photograph of the visual challenge can therefore still be copied. The appropriate deployment pattern is to make the QR value short lived and to authenticate the response rather than relying on secrecy of the image. A nonce, counter, or session challenge can provide explicit freshness, while an enrolled device key can bind the response to a trusted endpoint. Ascon-AEAD128 is a current lightweight option for protecting that response, but its actual latency, packet expansion, RAM, flash, and energy cost must be measured rather than assumed [17].

The same reasoning applies to node impersonation and man-in-the-middle modification. A server can reject a malformed token or unauthorised identity without being able to prove that an apparently valid message originated from the claimed device. Authenticated encryption would add integrity, but origin assurance still depends on enrolment and key management. ELA provides one recent direction for lightweight zero-touch enrolment [18], while PUF-assisted work illustrates device-bound authentication alternatives [19,27]. Any such extension should include revocation and stolen-device handling because possession of a legitimately enrolled endpoint changes the attacker model. Routing defence remains separate from attendance validation. An attacker who disrupts RPL can reduce availability without ever producing a duplicate attendance message. Replay of RPL control traffic, Hello Flood behaviour, rank manipulation, sinkholes, and selective forwarding therefore require routing-layer monitoring or protocol hardening [8,9,15]. A useful cross-layer design would protect the attendance payload cryptographically while collecting routing evidence at a capable gateway, avoiding the assumption that every constrained mote should execute a heavyweight detection model.

The choice of QR code is consequently best understood as an interaction and deployment choice, not as the security primitive itself. QR is attractive when the environment already has a screen and camera-equipped client, when session values need to be changed rapidly, and when dedicated NFC/RFID readers or BLE beacon infrastructure would add operational cost. Its main weakness is precisely that visual information is easy to copy. Treating the QR as a public short-lived challenge and the network response as the protected object resolves this tension more cleanly than attempting to make a displayed image confidential.

Practical deployment introduces additional factors that simulation cannot reproduce completely. Human movement can block or reflect radio paths; nearby Wi-Fi and Bluetooth traffic can increase interference; phones and embedded devices may have heterogeneous radios and power-management behaviour; a gateway may be temporarily unavailable; and users need clear feedback when a transaction is delivered but not yet durably accepted. A production design should therefore distinguish “received” from “accepted” status, retain idempotent duplicate handling during controlled retries, define an offline/fallback attendance procedure, protect personal data at rest, and log administrative changes to the final attendance record. Energy should be measured at the service outcome rather than inferred from packet delivery. One useful metric is joules per accepted attendance transaction, accompanied by radio transmit/listen time, CPU active time, low-power time, RAM/flash footprint, and packet-size expansion for each security configuration. This would allow the additional cost of authenticated encryption, enrolment, or routing defence to be expressed against the useful work delivered by the system. Energy-aware RPL methods such as LEA-RPL provide one route for testing whether routing improvements offset some of that overhead [10]. For experimental reproducibility, the next validation package should preserve source code, Cooja scenarios, Contiki-NG version or commit, compiler options, random seeds, run duration, traffic schedule, radio and propagation model, node positions, raw logs, and analysis scripts. This information is not merely administrative: it determines whether another researcher can reproduce the measured security percentages and scalability trends or explore how sensitive they are to topology and timing choices.

8. Limitations, Threats Validity, and Deployment Validation

The findings should be interpreted within the boundary of the implemented simulation. QR image capture and decoding are not simulated; the experiment begins with the post-scan attendance transaction. The results therefore characterise low-power message delivery, application acceptance, and exact replay handling rather than camera accuracy or QR-recognition reliability. The term unauthorised/spoofed identity refers to an application submission that fails the attendance rule, not to a complete physical-layer, link-layer, or IP-address spoofing study.

8.1. Limitations and Threats to Validity

Statistical generalisation is limited by the available experimental record. PDR, loss, delay, and ASR are represented by one aggregate value for each network size, without repeated-run samples, random-seed distributions, or per-packet raw data. Confidence intervals and significance tests for those metrics cannot be calculated responsibly from the available information. Replay events are an exception because individual attempt and rejection counts are available, permitting exact binomial confidence intervals. The resulting aggregate interval is still a finite-sample statement and should not be interpreted as proof of universal 100% rejection.

External validity is also bounded by network scale and simulation conditions. The largest evaluated scenario contains 50 student motes. The observed trend should not be extrapolated to hundreds or thousands of clients, and the current data do not identify a saturation point. A real classroom or workplace can contain people, walls, heterogeneous devices, Wi-Fi/Bluetooth interference, changing radio orientation, and mobility patterns not fully reproduced by the simulation. Hardware experiments under representative interference are therefore required before operational latency, delivery, or capacity limits are claimed.

The attack model is intentionally narrower than a complete end-to-end adversarial evaluation. Exact application replay is measured; cryptographic message modification, node impersonation, RPL control-plane manipulation, jamming, gateway compromise, backend compromise, stolen-device use, key extraction, and side-channel attacks are not experimentally defeated by the baseline. The threat matrix makes these exclusions explicit so that the observed replay result is not reported as a generic intrusion-detection rate. Finally, energy efficiency is not an experimental result of the current study. Direct CPU activity, radio duty cycle, per-transaction energy, and memory footprint were not measured. PDR, delay, and the simplicity of a validation rule cannot substitute for those measurements. This limitation is particularly important for secure low-power WSN research, where an added defence may improve security while simultaneously increasing airtime, computation, or retransmissions. The next stage must therefore quantify security benefit and resource cost together.

8.2. Deployment-Oriented Validation Plan

A stronger second-stage evaluation should compare security configurations under repeated network and attack experiments rather than adding isolated features. The baseline would retain token validation and duplicate state. A second configuration would add Ascon-AEAD128 with an enrolled symmetric key, allowing authenticated-payload overhead to be measured separately. A third configuration would combine authenticated attendance with a lightweight RPL monitoring or energy-aware routing mechanism. Secure enrolment can be treated as a separate provisioning phase so that one-time enrolment cost is not mixed with steady-state attendance traffic.

The network design should retain the existing 5-, 20-, and 50-mote points for continuity and extend them with denser scenarios. For each population, sparse and dense placements, different routing depths, and multiple offered loads should be run over independent random seeds. The primary outputs should include PDR, loss, throughput, delay distribution, ASR, route depth/parent changes, radio and CPU energy, and RAM/flash footprint. Repetition enables means, dispersion, confidence intervals, and effect sizes to be reported rather than relying on a single aggregate value.

Security testing should separate application and routing attacks. Application experiments should include exact replay, replay with modified fields, forged/unauthorised identity, altered authentication tags, and benign retransmissions that resemble duplicates. Routing experiments should include RPL replay, rank manipulation, and feasible flooding/DoS cases. For each class, the experiment should record injected events, correctly rejected/detected events, misses, false positives, response latency, and incremental communication/energy overhead. Once the cryptographic message flow is fully specified, formal verification with a tool such as ProVerif, Scyther, AVISPA, or Tamarin should test freshness and authentication properties independently of the network simulation.

The practical hardware stage should use constrained sensor or IoT nodes and a real border router in a classroom-like environment. Power instrumentation should report radio transmit/listen time, CPU activity, low-power time, total energy, and energy per accepted attendance transaction. Controlled Wi-Fi/Bluetooth interference and human occupancy should be introduced so that the simulation trend can be compared with real wireless behaviour. The same stage should measure QR/session rotation, retry behaviour, gateway outage handling, and user feedback because these implementation details can affect both security and perceived reliability.

Table 10. Minimum reproducibility artefacts for the extended evaluation.

Artefact	Required content
Contiki-NG source	Client, gateway/server, attack generator, security configurations
Cooja scenarios	Node types, positions, radio model, run duration, seed, topology
Build metadata	Contiki-NG version/commit, toolchain, compile flags
Traffic definition	Message interval, attendance window, payload format, retry rule
Security parameters	Token/session lifetime, nonce/counter construction, key/tag sizes, enrolment assumptions
Attack definition	Attacker capability, start/stop time, injected counts, replay source, benign-retry controls
Energy instrumentation	CPU/radio/low-power measurement method and conversion to joules per accepted event
Raw logs and scripts	Per-run packet, route, validation, attack, energy logs and reproducible analysis code

Table 10. Minimum reproducibility artefacts for the extended evaluation.

Artefact	Required content
Contiki-NG source	Client, gateway/server, attack generator, security configurations
Cooja scenarios	Node types, positions, radio model, run duration, seed, topology
Build metadata	Contiki-NG version/commit, toolchain, compile flags
Traffic definition	Message interval, attendance window, payload format, retry rule
Security parameters	Token/session lifetime, nonce/counter construction, key/tag sizes, enrolment assumptions
Attack definition	Attacker capability, start/stop time, injected counts, replay source, benign-retry controls
Energy instrumentation	CPU/radio/low-power measurement method and conversion to joules per accepted event
Raw logs and scripts	Per-run packet, route, validation, attack, energy logs and reproducible analysis code

9. Conclusions

This paper examined a QR-code attendance transaction carried over an RPL-based low-power IoT network in Contiki-NG/Cooja. The study intentionally begins after the visual scan so that communication reliability, application acceptance, and replay behaviour can be evaluated without attributing QR-decoding performance to the network experiment. The architecture combines IEEE 802.15.4, 6LoWPAN, IPv6, RPL Lite, CSMA, and UDP with server-side token, authorisation, and duplicate/freshness checks. Across the recorded scale from 5 to 50 motes, PDR decreases from 98.2% to 91.7%, packet loss rises from 1.8% to 8.3%, average end-to-end delay increases from 12 to 37 ms, and ASR decreases from 96.5% to 89.4%. The PDR–ASR gap remains between 1.6 and 2.3 percentage points, indicating that application success broadly tracks network delivery over the evaluated range. These observations answer RQ1 while defining a measured operating point rather than an inferred maximum capacity.

For RQ2, all 38 recorded exact replay transactions are rejected by the duplicate/freshness mechanism. The exact two-sided 95% confidence interval for the aggregate replay-rejection proportion is 90.75–100%, which is a more defensible statement than treating an observed 100% rate as a universal guarantee. The formal acceptance predicate explains the bounded property: an already accepted logical transaction cannot be accepted again while its duplicate identifier remains in the server’s active state. The same argument does not establish resistance to crafted message variants, QR forwarding, cryptographic man-in-the-middle attacks, node impersonation, routing manipulation, physical device compromise, or backend compromise. The principal contribution is therefore the combination of a clearly scoped replay property with network/application scalability measurements and an explicit security boundary. A deployment-ready extension should authenticate the transaction rather than the visible QR value, bind keys to securely enrolled devices, add routing-aware protection, repeat simulations across seeds and topologies, measure throughput and memory, and quantify radio/CPU energy. Hardware tests under realistic interference are also required before the architecture can be described as an energy-efficient operational WSN solution. This progression preserves the simplicity of QR interaction while moving the trust decision to the protected network transaction where it can be measured and verified. Future work will extend the present framework by introducing authenticated transaction protection, secure device enrolment, and routing-aware security mechanisms so that replay resistance can be evaluated alongside stronger end-to-end security properties. Further experiments will also consider larger and more varied RPL topologies, repeated simulation runs, direct energy and memory measurements, and hardware-based testing under realistic wireless interference to determine how well the observed behaviour translates to practical deployments.