IEEE IoT Journal Submission Guide: Internet of Things Journal

Source: IEEE IoT Journal home page, IEEE IoT Journal author guidelines, accessed May 2026.

This is the IEEE IoT Journal-specific structural detail authors most often miss:

IEEE IoT Journal is a joint IEEE publication with broad society coverage:

1. IEEE Sensors Council

1. IEEE Communications Society

1. IEEE Computer Society

1. IEEE Signal Processing Society

1. IEEE Computational Intelligence Society as technical cosponsor

The strategic implication: this multi-society structure gives the journal unusual scope breadth across IoT systems, communications, sensors, signal processing, computing, and AI/ML for IoT. Manuscripts should make the relevant audience obvious. A paper centered on sensing hardware, wireless networking, embedded systems, edge AI, or application middleware may all fit IoT-J, but the abstract and cover letter should tell the editor which lane owns the work.

Verify the current Editor-in-Chief on the journal's editorial-team page before quoting any name in a cover letter. The Editor-in-Chief oversees the editorial board that handles IoT-J submissions. The board's Associate Editors screen for IoT-systems relevance, evaluate evaluation rigor against the multi-society scope, and check IEEE-format compliance before reviewer invitations go out. The journal's editorial focus spans:

• IoT systems architecture and design

• Edge and fog computing

• IoT security, privacy, and trust

• IoT communications and networking

• Sensor systems and data analytics

• AI/ML for IoT

• IoT in healthcare, transportation, industry, smart cities, and agriculture

• Blockchain and distributed ledger for IoT

• Energy-efficient IoT and green computing

• Emerging IoT architectures (6G, semantic IoT, digital twin, metaverse-IoT)

Three operational signals govern editorial assessment:

1. IoT-systems contribution. The journal requires substantive IoT-systems research, not generic networking or computing work that mentions IoT in the introduction.

2. Methodological rigor. Strong system evaluation through theory, simulation, prototype, real-world deployment, or rigorous experiments is required. Pure-design papers without evaluation face a higher editorial-screen risk.

3. Sponsoring-society alignment. Manuscripts that clearly articulate which sponsoring society's audience benefits most enable correct editor routing and faster review.

When we reviewed the 100 most recent IEEE IoT Journal papers used when this guide was built, the strongest submissions treated IoT as the system being studied, not as a marketing label. The abstract stated the IoT architecture, device or network constraint, application setting, and evaluation environment before leaning on generic AI or networking language.

In Manusights pre-submission reviews, the recurring risk is a paper whose experiments could belong to any distributed-systems, wireless, security, or machine-learning venue. If the table of baselines, first system figure, or dataset description does not make the IoT constraint visible, the manuscript can look like a generic technical paper with IoT added at the end. IoT-J needs the reader to see why constrained devices, sensing, edge deployment, data flow, security, or application service design changes the technical problem.

Recent IoT-J issues span:

• Federated learning and edge AI for IoT

• IoT security, intrusion detection, anomaly detection

• 6G and semantic IoT communications

• Digital twins and metaverse-IoT

• Blockchain and distributed ledger for IoT trust

• Healthcare IoT and wearable systems

• Industrial IoT and predictive maintenance

• Smart-city IoT and transportation

• Agriculture IoT and environmental sensing

• Energy harvesting and energy-efficient IoT

For specific recent papers and DOIs, see the IEEE IoT Journal current issue. For submission planning, the more useful pattern is not the DOI list. It is whether the recent papers make the IoT architecture, device constraints, service setting, and validation environment visible in the abstract, method, figures, and experimental table.

The official scope lists architecture, enabling technologies, communications and networking protocols, services, applications, and test-beds. Each lane needs different evidence.

This distinction matters because a paper can mention IoT throughout the introduction and still fail the fit test. The decisive question is whether the evaluation would look incomplete if the IoT device, sensing, edge, service, or application constraint were removed.

Submission caps: 8 pages of IEEE double-column text is the standard length envelope, after which a $175 per-page mandatory charge applies. Final papers typically include 4 to 8 figures (counted as roughly half-column or full-column placements within the 8 pages), and the abstract sits in the 150 to 250 word band. Reproducibility appendices and prototype telemetry move to supplementary files rather than pushing the manuscript over the page budget.

IoT-J publishes its medians openly: 6.9 weeks to first decision, 14.5 weeks to ePublication. Treat as planning ranges, not promises.

• Day 0: IEEE Author Portal upload. The portal accepts the package, runs IEEE format and originality checks, and routes to an Associate Editor matching the IoT subdomain.

• Days 1 to 14: Administrative and editor assignment. Editorial staff verify IEEE format, abstract length (150-250 words), and ORCID compliance; the Associate Editor evaluates IoT-systems fit.

• Days 14 to 28: Reviewer invitations. IoT-J typically invites three reviewers spanning the relevant sponsoring societies (Sensors, Communications, Computer, Signal Processing).

• Days 28 to 70: Peer review. Reviewer reports return on a 4 to 8 week cadence; system-evaluation-heavy papers extend the timeline because reviewers verify prototype results.

• Days 49 to 70: First editorial decision. The 6.9-week median lands here. Major revision is the most common outcome for papers that pass desk review.

• Days 70 to 100: Revisions and acceptance. Single-revision acceptances run roughly 3 to 4 months total.

• Days 100 to 105: ePublication. The 14.5-week median submission-to-ePub reflects single-revision acceptances; multi-round revisions extend the timeline.

This page handles the public submission rules; the draft still needs a journal-specific fit check.

The review tells you whether your paper clears the IEEE IoT Journal fit check before upload, especially around generic networking, distributed-systems, signal-processing, or ML manuscript with IoT framing retrofitted to the abstract, pure-design or pure-theoretical manuscript without prototype, testbed, simulation-with-realistic-traces, or deployment evidence, and evaluation-table mismatch where the introduction promises IoT-relevant constraints but the results table reports generic accuracy / throughput / loss.

Paid Manusights reviews include a 60-day money-back guarantee, and we do not train models on submitted manuscripts.

Across IoT-J targeted manuscripts, three recurring decision risks matter most across submissions that IoT-J editors filter out at the desk-screen stage. (Per IoT-J author-guideline statistics, submission-to-first-decision averages 6.9 weeks and submission-to-ePublication averages 14.5 weeks;

the multi-society sponsorship structure across ComSoc / Computer Society / SPS / SMC / SenC means the EiC routes manuscripts across five technical-area lanes within the first read, and cross-society misroutes get desk-rejected with redirect within 2-3 weeks.) Use the three checks below before you open Author Portal upload slot.

A Manusights review checks whether your paper clears the IEEE IoT Journal-specific readiness checks that official IEEE instructions cannot evaluate from a generic Author Portal checklist. Paid Manusights reviews include a 60-day money-back guarantee; submitted manuscripts are not used for model training.

Generic manuscript with IoT framing

Across IoT-J targeted manuscripts, we consistently see authors submit work where the underlying contribution is a generic wireless-networking protocol, distributed-systems contribution, signal-processing technique, or machine-learning architecture.

The abstract then retrofits IoT framing by inserting "for IoT" or "in IoT scenarios" without making the contribution actually IoT-specific.

IoT-J handling editors (drawn from the five sponsoring societies) specifically check whether the contribution is IoT-system-specific (named IoT scenario with explicit device-class constraints, edge-fog-cloud topology, sensor-actuator-network architecture, real-deployment context) or whether IoT is the application label for an underlying contribution that lives in another technical area.

Manuscripts with retrofitted framing get redirected within 2-3 weeks to IEEE TNSM / TON for networking, IEEE TPDS for distributed systems, IEEE TSP / TSIPN for signal processing, IEEE TII for industrial-IoT specifically, IEEE Sensors Journal for sensor-hardware focus, IEEE TWC / TVT / TCOM for wireless, or IEEE Communications Surveys & Tutorials for survey-shaped work.

The fix is to rewrite the contribution statement so the IoT-system specificity is load-bearing (e.g., "we present an in-network aggregation scheme for LoRaWAN gateways under duty-cycle constraints" rather than "we present a new aggregation protocol for IoT"), name the device class, network topology, and operational constraints in the first abstract sentence, and demote the underlying technique to a methodological tool.

Check whether your IEEE IoT Journal abstract and Figure 1 make the IoT constraint visible →

Pure-design or pure-theoretical manuscript

We frequently see IoT-J manuscripts present novel architectures, protocols, or algorithms with only conceptual analysis (architectural diagrams, complexity analysis, security proofs in formal models) and no system-level evaluation.

IoT-J's editorial culture treats this as preliminary work, not as publishable IoT systems research.

The specific evaluation elements IoT-J reviewers (most of whom are systems-and-deployment-oriented) check for:

• prototype implementation on real IoT hardware (Raspberry Pi / ESP32 / nRF52 / STM32 / Arduino / Jetson-class edge device named with specific SoC + memory + power profile)

• testbed evaluation on documented infrastructure (FIT IoT-LAB, w-iLab.t, FABRIC, CityLab, GENI, IoT Open-Testbed) or named lab deployment with topology described

• simulation with realistic traces (NS-3 with real packet traces, OMNeT++ with real-deployment topology, Cooja with real-device firmware) rather than uniform-random assumptions

• measured energy consumption on real hardware via INA219 / Otii Arc / Joulescope shunts where energy is claimed

• measured end-to-end latency including network round-trip on real radios where edge-latency is claimed

• documented scalability evaluation across at least 2 orders of magnitude in node count.

Manuscripts that omit any of these elements when the contribution claim depends on them face desk rejection within 2-3 weeks.

The fix is to include at least one of prototype-on-real-hardware OR public-testbed-deployment OR realistic-trace-simulation as primary evidence, anchor every claimed system property (latency / energy / scalability / reliability / privacy overhead) in a measurement methodology subsection, and report measurement uncertainty bounds appropriate to IoT hardware.

Check whether your IEEE IoT Journal evidence package is concrete enough for review →

Evaluation table misses IoT constraints

Across IoT-J targeted manuscripts, the third recurring pattern is a results table that does not match the IoT claim made in the introduction. Specifically:

• introductions promise edge-latency improvements but results report only accuracy and F1

• introductions promise on-device memory constraints but results omit model-size / activation-memory / parameter-count breakdowns

• introductions promise energy efficiency but results omit Joules-per-inference or milliwatts-active-power measurements

• introductions promise privacy-preservation but results omit privacy-budget (epsilon for DP), communication overhead, or attack-resistance evaluation

• introductions promise deployment robustness but results omit packet-loss / device-heterogeneity / network-churn sensitivity

• introductions promise multi-device scaling but results test only single-device or small-cluster. IoT-J reviewers check this match explicitly and revision requests demanding the missing measurements often add 4-6 months to the timeline

The fix is to enumerate every claim made in the introduction's contribution statement as a checklist, map each claim to a specific column in the results table or a specific subsection of the evaluation, and either deliver evidence for every claim or weaken the claim before submission.

Specifically include: latency in milliseconds with confidence intervals across at least 100 runs; energy in microJoules-per-inference measured on real hardware; memory in kilobytes for model + activations; communication overhead in bytes-per-round for distributed protocols; privacy budget for any DP / federated / SMPC claim; failure-mode behavior under packet loss, device churn, and adversarial conditions where relevant.

Check whether your IEEE IoT Journal results table matches the submission claims →

• Is IEEE IoT Journal a good journal?

• IEEE T-WC Submission Guide

• IEEE Transactions on Industrial Informatics Submission Guide

• IEEE Sensors Journal Submission Guide

If the paper is already in the portal, use the IEEE Internet of Things Journal Under Review status guide to interpret the live status label, decide when to follow up, and prepare the reviewer-risk map before a decision arrives.

Last verified: May 2026 against IEEE IoT Journal editorial pages.