Protocol Design

Shaping the way technical systems interact with each other to get the right result

Protocols underpin how we interact with each other – how we communicate, share information and provide services. Humans are flexible enough to adapt them for different circumstances – from a simple request to pass the salt during a meal to nations exchanging high-level diplomatic notes.

In the world of technical systems, protocols serve a similar purpose – making sure a desired outcome is achieved. But the big difference is that they need to be precisely defined and standardised to avoid problems.

A sensor system, for example, might be accessed by multiple systems – a power-monitoring system checking that the sensors have enough power to operate correctly, a system needing access to the sensor results to develop statistics for reports and a third system might need the results to control part of an industrial plant.

The protocol designer’s job is to identify and define these roles and then develop the messages that need to be exchanged in a protocol that allows all of them to access the sensors in the correct way to do their job – with the security systems configured to ensure they can do no more than that.

Real-world challenges

Long range communication, minimal energy consumption

Determining when parking spaces are free using low-cost battery-powered sensors that can report back to a central controller allows digital signage in a city to direct drivers to streets with spare parking spaces. The detection itself is a challenge because of the wide variety of materials in modern vehicle design – but communicating the result back to the controller is also non-trivial.

A very short-range interface was to be used just once after sensor installation so that the installer could use a terminal to configure the sensor’s identity and its radio and security settings – all to be linked at the central controller with installation location details.

The short-range protocol was simple but had to be reliable because after its use the interface was permanently disabled so that no one could tamper with the sensor without removing it from the ground. The sensor would then remain in the ground for years using a long-range radio protocol to communicate with a central controller which could be many km away. The protocol was therefore designed to enable long range communication whilst minimising energy consumption to enable reliable reporting of parking space occupancy status.

Formula 1 real time data transfer

A client wanted to transmit telemetry data from Formula 1 racing cars back to the pit lane in real time. But the regulations at that time forbade any digital data transfer from pit to car – so there was no standard protocol stack that could be used for the radio communications.

The challenge was to implement a reliable data transfer from car to pit without the feedback used in conventional protocol stacks to indicate loss of data and the need for re-transmissions.

Discussions led to the concession that a broadcast from the pit of a synchronisation signal did not contravene the spirit of the regulations. A protocol stack was then developed that offered several logical data channels with different quality-of-service characteristics, some timed to make use of the regular high-quality high-Doppler link available as a car approached and passed the pit lane.

Monitoring infrastructure at scale

Obtaining data from Internet of Things (IoT) sensors located in manholes to monitor a city’s infrastructure represents a communications challenge. After conducting a series of measurements, it was decided that the best approach would be to make use of cellular infrastructure. Antennas could be located near the manhole covers and enough signal penetration was observed at most locations for moderate data rates to be achieved at irregular intervals.

The protocol that was needed was therefore an application-layer protocol that used HTTPS as the transport mechanism. It had to handle intermittent connectivity and queue data, as necessary. An important aspect was that the queues were prioritised – with a last-in-first-out approach as the most recent alarms from the sensors would be of greatest interest.

Key skills

  • Protocol testing

    Developing equipment designed to test complex standardised protocol stacks used in radio communications.

  • Protocol implementation

    Implementing standardised protocol stacks.

  • Security of protocols

    Analysing security vulnerabilities in protocol stacks.

  • Custom protocol development

    Developing custom protocol stacks for systems requiring point-to-point and point-to-multipoint connectivity.

  • Mesh routing protocols

    Comparing the capabilities, benefits and constraints of routing protocols used in mesh networks.

Engineering is about compromise and a big one is about the costs and time of developing a custom protocol versus the constraints and manufacturing costs (licences, etc) of using a commercial implementation of a standard protocol. In general, we will try to keep the custom aspects of the protocol design to a minimum, using standard or commercial solutions as much as possible.

Peter Massam, Principal Technology Consultant
Peter Massam

Principal Technology Consultant

What sets us apart when it comes to protocol design?

Plextek has experience designing, developing, implementing, testing and using a range of custom and standardised wireless protocols for the products we have developed. In terms of the network types, these have included:

  • Local area networks – e.g. for industrial automation – using WiFi and WirelessHART
  • Personal area networks using Zigbee, Bluetooth and WiFi
  • Body area networks – e.g. dismounted position and navigation sensor, DPNS, systems – using Bluetooth Low Energy with custom profiles
  • Wide area networks – e.g. for asset management and tracking, utility sensor systems and control, emergency services tracking and communications – using LoraWAN, cellular 2G/3G/4G/5G and TETRA

Plextek’s extensive knowledge of the underlying techniques used in these protocols is significant and includes:

  • Frequency-band selection based on system requirements and national (Ofcom) and international (CEPT, ITU) regulations
  • Modulation characteristics and techniques that spread transmit energy across time, frequency and space domains:
    • Ultra narrowband (UNB) and ultra wideband (UWB)
    • Direct-sequence, frequency-hopping and chirp spread spectrum (DSSS, FHSS, CSS)
    • Antenna design, including beamforming methods
  • Time-, frequency-, code- and space-division multiplexing (TDM, FDM, CDM, SDM) and related multiple access techniques (TDMA, FDMA, CDMA, SDMA, MIMO)
  • Emission controls through passive design and active techniques such as open- and closed-loop power control
  • Error mitigation techniques, including forward error correction (FEC), automatic repeat request (ARQ) and adaptive coding and modulation (ACM) methods
  • Routing algorithms, proactive, reactive, link-state and distance-vector routing protocols (including OLSR and AODV), quality of service (QoS) aware routing algorithms and Q-learning with deep neural networks – deep Q networks (DQNs) – and graph neural networks (GNNs)
  • Data distribution methods, including publish-subscribe (MQTT, DDS) and client-server (REST, HTTP)
Contact Plextek

Contact Us

Got a question?

If you have got a question, or even just an idea, get in touch

Projects

View All