ESRO is a transport-level protocol implemented in the LEAP wireless protocol and is detailed in RFC 2188: AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2.

"When TCP is too much and UDP too little" (Banan 1995), Efficient Short Remote Operations provides reliable connectionless remote operation services, and runs on top of UDP. ESRO takes care of segmentation and re-assembly, concatenation and separation as well as multiplexing. Obviously LEAP is IP-based because it runs over top of UDP which in turn runs over top of IP.

ESRO provides the above services to applications and also has much in common with protocols like Remote Procedure Calls (RPC). This simply means that an 'invoker' directs an operation to be performed on a remote device (performer) and feedback is returned to the invoker.

ERSO has two modes of operation: Acknowledged Result and Non-Acknowledged result. The easiest way to distinguish between these two modes is to think of Acknowledged as a 3-way handshake and Non-Acknowledged as a 2-way handshake (terminology is consistent with RFC 2188).

Acknowledged Result

The messages passed between Invoker and Performer in Acknowledged Result works like this (the terminology are actual primitives used in the protocol):

  1. Invoker sends ESROS-INVOKE.request to the Performer
  2. Performer sends ESROS-RESULT.request to the Invoker to complete the operation.
  3. The Invoker will send an ACK to acknowledge it received the RESULT.

This is pretty reasonable but the one caveat to the issue would be that "the mechanism by which the acknowledgment is accomplished may not be reliable." (Banan, Taylor, Cheng 1997). Acknowledged Result is referred to as a 3-way handshake because it takes 3 exchanges between Invoker and Performer to be completed successfully.

Non-Acknowledged Result

Non-Acknowledged works exactly the same as Acknowledged expect the final ACK is not included in the exchange. This is referred to as a 2-way handshake because only 2 exchanges between Invoker and Performer are required.

Non-Acknowledged Result can be used to reduce overhead in a more reliable environment.


One of the major criticisms of WAP is that it is not IP-based in a world that is moving towards IP convergence. LEAP is unequivocally IP-based: ESRO runs over top of UDP, which in turn runs over IP.

ESRO primitives work directly with standard IP and port numbers. For instance, the INVOKE primitive works with Invoker-address and Performer-address parameters where the addresses are defined as:

ESRO Service Access Point (SAP) Selector, Transport Service Access Point (TSAP) Selector (e.g., port number), and Network Service Access Point (NSAP) address (e.g., IP address). This parameter has to be supplied (Banan, Taylor, Cheng 1997)


ESRO implements multiplexing by the use of the Invoke-ID. Concurrent ( ESRO performs asynchronous operations) invocations of the same ESRO service by a user are tagged with unique Invoke-IDs. The Invoke-IDs are used to associate a particular INVOKE primitive with it’s relevant RESULT or ERROR replies. ESRO can re-use Invoke-IDs for new operations once previous operations are completed to the degree that ESRO can expect no further messages with that tag.

The Invoke-IDs provide another layer of granularity to segregate operations aside from just identifying them by {IP-Address - Port - SAP} tuples. That tuple could not distinguish two instances of the same service being performed on the same target, which would mean ESRO could not multiplex multiple instances of the same service and they would have to be performed in a serial (synchronous - a capability ESRO does provide if needed but it’s implementation specific) fashion.

Segmentation and Re-Assembly

The ESRO segmentation and re-assembly is accommodated by:

  • Use of two additional PDU codes for segmented INVOKE PDU.
  • Use of one byte segmentation information, which contains First/Other flag and segment number.
  • Use of unused bits of RESULT and ERROR PDUs to identify a segmented RESULT or ERROR PDU.

The ESRO primitives are encapsulated into a single PDU. When they are small enough those PDUs are transmitted in a single UDP datagram. Otherwise, they are segmented and sent in multiple UDP datagrams and the re-assembled on the other side.

Strangely, if part of those segmented PDUs is lost (i.e., 1 UDP datagram containing a portion of the entire PDU is lost) then the entire PDU is re-transmitted. I thought this was strange since it would seem like it would be more efficient to send just the lost segment, but the RFC was pretty clear on it’s operation though. This was probably a tradeoff between efficient bandwidth use and light (dumb) clients. It’s possible Neda decided it was better to take a slight performance hit than build more smarts into the ESRO devices.

The additional PDU codes for INVOKE PDUs and the unused bits of the RESULT and ERROR PDUs (those are items 1 and 3 on the above list) are all used the same way, to signal to the other side that this is part of a segmented PDU.

This is how the one byte of segmentation information is used:

The first segment will be marked ‘First’, and it’s "sequence number" won’t actually contain a sequence number since we already know it’s the first. That area will contain the total number of segments.

Following segments will be marked ‘Other’, indicating that they are not the First. Their sequence number section will actually be their sequence number indicating the order they come in the entire sequence.

The receiving end thus has enough information to perform re-assembly of the segmented PDU.

Log in or register to write something here or to contact authors.