How to Document a Private LoRaWAN Architecture for Technical Review

Document a private LoRaWAN architecture with a component boundary record, an interface register, named owners and acceptance evidence for each handoff. For a Robustel R1520LG project, state where the network server runs, how sensor observations reach the application and how authorised operators manage the gateway. A technical reviewer should be able to trace one representative observation and identify every unresolved dependency. Keep the dossier tied to the proposed hardware and software baseline so a review decision can be tested during commissioning.

Illustrative technical review of a private industrial sensor network.

Key Takeaways

• State the selected network-server arrangement and software baseline explicitly.
• Turn each connection into an interface record with an owner and a verification method.
• Document application data and gateway management as separate paths.
• Close review comments with evidence or a clearly assigned remaining condition.

In This Guide

• What should the architecture dossier contain?
• How do you make interfaces reviewable?
• What should reviewers ask about access and failure handling?
• Frequently asked questions

What should the architecture dossier contain?

Begin with a concise service statement: the assets being observed, the receiving application and the operational decision the information supports. Then identify the physical gateway, the selected network service, the relevant application integration and the management route. Give components stable names so the drawing, interface table and test record use the same identifiers.

Robustel's R1520-LG product description distinguishes an embedded ChirpStack path from connections to external network servers. Choose the intended arrangement in the project record. A drawing labelled only “gateway to cloud” leaves reviewers unable to see which party runs the network service and which component owns the application handoff.

Use six short records: scope, component inventory, interface register, access responsibilities, acceptance evidence and open decisions. Attach detailed configuration documents as references rather than filling the review with screenshots that lack an explanation of their purpose.

For a project using embedded ChirpStack, a useful review sequence is: identify the sensor, observe its network event, identify the integration responsible for the application handoff, and verify the receiving result. This is a documentation sequence, not a claim that a particular cloud or industrial protocol integration is automatically configured.

How do you make interfaces reviewable?

For every connection shown in the design, record what crosses it, who controls each end and what evidence will show it operating. An arrow without those details can conceal an unowned software component or an assumption about credentials.

Include the location of detailed settings, but do not copy secrets into the dossier. The review needs to establish that credential ownership and delivery are agreed; it does not need unrestricted access to production keys.

Add a dependency column when a row relies on a separately supplied application, software version or service. Give that dependency an owner and a due date. A reviewer can accept a conditional design only when the condition is specific enough for commissioning to verify later.

What evidence should accompany one representative observation?

Assign a test identifier and record the actual sensor, configuration baseline and observation time. Capture the successive handoffs the architecture claims to provide, ending with a result the application owner can interpret. Keep the observed value and its meaning together so a copied screenshot does not lose its context.

Robustel's local activation guide separates device activation from uplink verification. Preserve that distinction in the evidence table. Then add the project's application acceptance step, which needs its own agreed expectations and responsible reviewer.

Mark each handoff as planned, observed or accepted. “Observed” means someone captured an event; “accepted” means it satisfied a defined project requirement. This vocabulary helps prevent a successful demonstration from being treated as proof of every proposed production condition.

If the test used a substitute sensor or a temporary upstream connection, describe the substitution and which conclusions remain open. That keeps a useful preliminary test from obscuring the remaining work required for the actual deployment.

Illustrative comparison of field observations and application acceptance evidence.

What should reviewers ask about access and failure handling?

Review the management path independently from the application path. RCMS provides device-management functions, but the architecture dossier still needs the project's enabled features, responsible team and approved access method. A gateway-management connection should not be used as an unexplained substitute for the application's data delivery design.

Ask what evidence remains available if one handoff stops working. Who can identify the last successful sensor observation? Who can inspect the chosen network service? Who can investigate the receiving application? Record the answer and the relevant support procedure for each boundary.

Where the proposed design depends on buffering, automatic recovery or an optional connector, request evidence for that exact software configuration and an agreed test. Do not imply those behaviours simply by drawing a storage symbol or a second network line. The dossier should distinguish required behaviour from already demonstrated behaviour.

Finally, check the operating documentation. The RobustOS Pro manual entry includes R1520LG in its related products. Use the applicable procedures as configuration references, while keeping project-specific ownership and acceptance decisions in the dossier.

How should the review be closed?

Give each review comment a requirement, owner, evidence reference and outcome. Classify the result as accepted, accepted with an explicit condition or unresolved. Avoid closing a comment with “discussed” when the installation team still lacks a configuration decision.

Publish a dated design baseline internally that identifies the gateway configuration and software assumptions. Pass the open conditions to commissioning, each with its verification step. When the design changes, reopen only the affected interfaces and evidence rather than obscuring the change in a revised drawing alone.

Frequently asked questions about architecture review

Is a topology drawing enough for technical approval?

It is useful, but add interface ownership, dependencies and verification records. Reviewers need to understand how a connection will be implemented and how its result will be accepted.

Should the dossier include sensor keys or account passwords?

Reference the approved credential-management process and accountable owner. Keep secrets out of broadly circulated review documents and sanitise screenshots before attaching them.

Can the same document cover embedded and external network servers?

It can compare alternatives during design, but the accepted baseline should identify the selected arrangement. Record separate dependencies and owners for any alternative that remains under evaluation.

What if an application integration has not been tested yet?

Mark that handoff as planned and specify the evidence needed to accept it. Do not close the whole data path based only on a successful local sensor event.

What should you bring to the technical review?

Bring the six-record dossier, one representative observation plan and the unresolved decisions for the proposed R1520LG configuration. Use the official R1520LG documentation hub to assemble references, then close each interface with an owner and an acceptance method.

About the Author

Mark, Technical Support Engineer at Robustel

Mark is a Technical Support Engineer at Robustel with hands-on experience in industrial networking and edge connectivity. He helps customers plan, deploy, configure, and troubleshoot industrial IoT solutions, including cellular routers, edge gateways, and LoRaWAN systems. His work spans technical support, product training, configuration review, and practical deployment guidance for reliable and repeatable field operations across global projects and long-term operational support.