Radio over IP gateway architecture
A Radio over IP (RoIP) gateway connects a radio system to an IP network so that voice and control can be transported beyond the physical reach of the local radio interface. The exact design varies considerably: a gateway may connect a fixed base station to a dispatch system, bridge two remote radio sites, expose a radio channel to a SIP environment, or form part of a standards-driven aviation voice system.
The useful architectural distinction is that a RoIP gateway normally has to carry two different kinds of information:
- real-time audio; and
- radio-control state such as push-to-talk (PTT), carrier/squelch indication, channel selection or other equipment-specific control.
SIP and RTP can provide the IP session and media layer, but they do not replace the radio-facing hardware and control logic.
The main building blocks
1. Radio-facing interface
The gateway must first interface with the actual radio equipment. Depending on the system, that interface may expose:
- balanced or unbalanced transmit/receive audio;
- microphone and speaker-level audio;
- E&M signaling;
- PTT input/output;
- COR/COS or squelch state;
- GPIO;
- serial control such as RS-232/422/485;
- a vendor-specific digital or Ethernet control interface.
This part of the design is highly application-specific. A gateway for a dispatch base station can have very different electrical and control requirements from a small mobile-radio bridge.
2. Audio path
The audio path typically performs some combination of:
- analog-to-digital and digital-to-analog conversion;
- gain control and level matching;
- filtering;
- codec encode/decode;
- packetization;
- buffering and jitter handling;
- muting or gating based on radio state.
For a simple implementation, the network side may use G.711. Other systems may require compressed codecs or application-specific media handling.
3. SIP signaling
SIP, standardized by RFC 3261, provides session establishment and teardown. In a RoIP design it can be used to register a gateway, establish a session to a dispatch console or peer gateway, negotiate media through SDP, and manage call state.
The important embedded-design point is that SIP should not need to own the radio hardware. The application can keep control of PTT, GPIO, channel selection and the local audio path while the SIP component handles standardized IP signaling.
4. RTP and RTCP media
RTP, standardized by RFC 3550, provides sequence numbers, timestamps and payload identification for real-time media. RTCP can provide reception and timing information associated with the RTP stream.
RTP itself does not guarantee latency, bandwidth or quality of service. A real RoIP product must still engineer the network path, buffering policy and failure behavior for the intended environment.
5. Radio control over IP
Audio alone is not enough for most two-way radio systems. The remote side needs to know when to transmit, and often whether a local receiver is active.
Possible designs include:
- application-specific signaling beside the RTP stream;
- SIP events or INFO messages where appropriate;
- RTP header extensions in standards-defined environments;
- separate TCP/UDP control channels;
- GPIO state mapped into a gateway-specific protocol.
The correct choice depends on interoperability requirements. In a closed system, a simple private control protocol may be acceptable. In an ecosystem that must interoperate with third-party radio or dispatch equipment, a defined industry profile can be much more important.
Half-duplex versus full-duplex behavior
Traditional two-way radio is often half duplex: only one direction should transmit on the RF channel at a time. An IP transport, however, is naturally capable of sending media in both directions simultaneously.
The gateway application therefore needs an explicit state model for:
- PTT ownership;
- transmit priority;
- simultaneous requests;
- squelch/COR transitions;
- timeout behavior;
- network loss while transmitting;
- local versus remote control arbitration.
Treating a radio channel as if it were an ordinary telephone call can produce subtle failures even when SIP signaling itself is correct.
Where ED-137 fits
For Air Traffic Management radio systems, EUROCAE's ED-137 family defines interoperability requirements for VoIP ATM components. The current radio work is under ED-137C/1 and subsequent changes/corrigenda. See ED-137 and SIP-based Radio over IP for a focused discussion.
A general RoIP product does not automatically need ED-137. Public safety, industrial, transportation and private radio systems may use completely different control models. The first architecture decision should therefore be whether the product is implementing a private RoIP system, a vendor ecosystem, or a defined interoperability standard.
Embedded implementation choices
A compact RoIP gateway frequently runs on embedded Linux, an RTOS or a custom processor where the application already owns the media devices and hardware-control interfaces. In that environment a SIP library is easiest to integrate when it exposes clean boundaries for:
- network send/receive;
- timers;
- signaling events;
- media packet delivery;
- application-owned call state.
SK400VOP was designed around this callback-oriented model so that the product keeps control of hardware-specific networking and media behavior.
Build an appliance or integrate a software component?
An off-the-shelf RoIP gateway is generally preferable when the available radio interface, control model and deployment format already match the requirement.
A custom gateway becomes more attractive when the project needs:
- unusual radio or audio hardware;
- proprietary control logic;
- a small or unusual compute target;
- deep integration into an existing product;
- a reusable SIP/RTP software component rather than a finished appliance;
- long-term ownership of the complete hardware/software design.
For software licensing or a custom radio gateway project, contact ZMATRIX.