The ESROS protocol realizes the services defined in the section entitled ESROS Service Definitions. Short operations are performed in a highly efficient manner. The protocol operation is summarized below and is described in detail in the following sections.
Two Functional Units are defined which realize the services with 2-Way handshake and 3-Way handshake, called 2-Way Handshake Functional Unit and 3-Way Handshake Functional Unit respectively.
The procedures specified in this section refer to Protocol Data Units (PDUs) which are defined in Section 4.4.
To access the ESRO Services, an ESROS user binds to an ESRO Service Access Point and specifies the SAP to be associated with 3-Way handshake Functional Unit or 2-Way handshake Functional Unit. ESROS provider generates a SAP descriptor which is passed to the user. The handshaking for all Invoke.requests addressed to that SAP and all PDUs addressed to that SAP will be either 3-Way or 2-Way based on the Functional Unit associated with SAP and specified by user at SAP bind time.
It is the responsibility of the ESROS peer users (invoker and performer) to address their operations to the appropriate SAP (3-Way or 2-Way) based on the agreement between users.
An ESROS user initiates the transfer of a PDU using the INVOKE service.
On receipt of an ESRO-INVOKE-PDU, the ESROS provider sends an ESROS-INVOKE.indication primitive to the ESROS performer user.
On receipt of an ESROS-INVOKE.request primitive from the ESROS user, the ESROS provider generates two invoke identifiers:
The provider communicates the Invoke-ID-Parameter to the invoker of the INVOKE service through the ESROS-INVOKE-P.confirm primitive.
The Invoke-Reference-Number distinguishes several invocations of the service in progress (asynchronous operations). It is also used as segment identifier when a Service Data Unit (SDU) is transferred using segmentation and reassembly. The ESROS provider may begin to reuse the Invoke-Reference-Number values whenever it chooses, subject to the constraint that it may not reuse an Invoke-Reference-Number value that was previously assigned to an invocation of the service for which it expects, but has not yet received, a reply. In other words the provider does not reuse a previously used Invoke-Reference-Number unless the corresponding service is fully completed. The same value of the Invoke-Reference-Number can be reused to identify the invocation between different peer entities. In that case, the combination of the peer entity's address and the Invoke-Reference-Number guarantees unique identification of each invocation.
When an ESRO Services user binds to an ESRO SAP, it associates its SAP descriptor to 3-Way Handshake Functional Unit or 2-Way Handshake Functional Unit.
Based on the Functional Unit associated with SAP, provider selects the corresponding Functional Unit for all Invoke Requests or PDUs addressed to that SAP.
PDUs sent by UDP use port ESRO_CL_PORT. PDUs carried by UDP are restricted to CLRO_SMALL_PDU_MAX_SIZE bytes (see 4.6.1)
Each PDU is encapsulated in a single UDP datagram.
For PDUs larger than CLRO_SMALL_PDU_MAX_SIZE but smaller than CLRO_SEGMENTED_PDU_MAX_SIZE bytes (see 4.6.1), segmentation and reassembly is used and each segment is transmitted in a UDP datagram.
PDUs sent using UDP may be lost, and hence a retransmission strategy is defined. When a PDU is segmented, the retransmission strategy is not applied to individual segments (i.e., loss of one segment results in retransmission of the whole SDU).
The optimal UDP retransmission policy will vary with the performance of the network and the needs of the transmitter, but the following are considered:
The retransmission interval should be based on prior statistics if possible. Too aggressive retransmission can easily slow response time of the network at large. Depending on how well connected the invoker is to its performer, the minimum retransmission interval should be RETRANSMISSION_INTERVAL (see 4.6.2) seconds.
Delivery of PDUs is asynchronous which means the ESROS does not wait for the result of a transmitted PDU and continues delivering the next PDUs.
This section describes the ESROS protocols in terms of state diagrams. The ESROS Finite State Machine is expressed as four separate transition diagrams. This is illustrated in Table 10.
Details of each of the two transition diagrams for connectionless transmission and different handshakings are described in the following sections. The state diagrams show the state, the events, the actions taken and the resultant state.The ESROS state transition diagrams for connectionless data transmission are presented in Table 11, Table 12, Table 13, and Table 14.
Transitions are identified by numbers on the state diagrams. The corresponding actions are listed next to each table.
This unit implements the Acknowledged Result model of ESRO Services. 3-Way handshaking is used in this unit.
The RESULT.confirm and ERROR.confirm primitives on performer are generated when ESRO-ACK-PDU is received.
The FAILURE.indication on performer side is resulted from remote or local failures. Not receiving ESRO-ACK-PDU or local failure can generate FAILURE.indication primitive.
The FAILURE.indication on invoker side is generated if a local failure happens or a ESRO-FAILURE-PDU is received.
The transmission of INVOKE, RESULT, and ERROR SDUs can be in a single PDU (when it fits in one UDP) or a sequence of segment PDUs.
 |
For each transition number in the state diagram Table 11, the corresponding actions are listed below:
On receipt of an ESROS-INVOKE.request, ESROS provider generates an Invoke- Reference-Number and an Invoke-ID (see Section 4.2.3). The provider issues an ESROS-INVOKE-P.confirm primitive and passes the Invoke-ID to the invoker.
The ESROS provider initiates the timer for the Invoke-ID and transmits the PDU. Based on the size of SDU, if segmentation is required, the SDU is segmented and transmitted in a sequence of segmented PDUs. If the ESRO-RESULT-PDU or ESRO-ERROR-PDU associated with the invoke ID is not received within the INVOKE_PDU_RETRANSMISSION_INTERVAL (see 4.6.2) period, the SDU is retransmitted (in one PDU or segmented and transmitted in a sequence of segment PDUs). The retransmission is repeated for a maximum of MAX_RETRANSMISSIONS unless an ESRO-RESULT-PDU or ESRO-ERROR-PDU is received.
If the ESRO-RESULT-PDU or ESRO-ERROR-PDU is received in a segmented format, the reassembly process reassembles the sequence of segment PDUs.
In the case that the Hold-on ESRO-ACK-PDU is received from the performer, the provider stops retransmitting the ESRO-INVOKE-PDU and waits for the ESRO- RESULT-PDU or ESRO-ERROR-PDU for a period equal to the multiplication of INVOKE_PDU_RETRANSMISSION_INTERVAL (see 4.6.2) and MAX_RETRANSMISSIONS (see 4.6.2, for future use).
In the case that the ESRO-INVOKE-PDU is sent MAX_RETRANSMISSIONS (see 4.6.2) times and no ESRO-RESULT-PDU or ESRO-ERROR-PDU is received, the ESROS provider sends an ESROS-FAILURE.indication primitive, with the Invoke-ID of the failed PDU and the Failure-value as parameters, to the invoker.
When an ESRO-RESULT-PDU or ESRO-ERROR-PDU is received (whether in one PDU or reassembled from a sequence of segmented PDUs), the provider issues an ESROS-RESULT.indication or ESROS-ERROR.indication to the invoker user, sends an ESRO-ACK-PDU and initializes the inactivity timer. In the case that duplicate ESRO- RESULT-PDU or ESRO-ERROR-PDU are received, they are ignored, the inactivity timer is reset, and an ESRO-ACK-PDU is retransmitted.
When no duplicate ESRO-RESULT-PDU or ESRO-ERROR-PDU is received for a period equal to INACTIVITY_TIME (see 4.6.2), or in the case of ESRO-INVOKE- PDU retransmission time-out, or in the case of internal failure, the provider initializes the reference number timer. After REFERENCE_NUMBER_TIME (see 4.6.2), the reference number is released.
 |
For each transition number in the state diagram above, the corresponding actions are listed below:
On receipt of an ESRO-INVOKE-PDU, the ESROS provider issues an ESROS-INVOKE.indication to the ESROS performer user. The provider ignores the duplicate ESRO-INVOKE-PDUs.
In the case of internal failure or no response from performer user, the provider sends an ESRO-FAILURE-PDU and releases the invoke reference number.
On receipt of a Hold-on request from the performer user, or based on other information, provider sends a Hold-on ESRO-ACK-PDU (future use).
On receipt of either ESROS-RESULT.request or ESROS-ERROR.request from the ESROS performer user, the ESROS provider initiates the retransmission timer for the ESRO-RESULT-PDU or ESRO-ERROR-PDU and transmits the ESRO-RESULT-PDU or ESRO-ERROR-PDU in a single PDU or in a sequence of segment PDUs. If the ESRO-ACK-PDU associated with the Invoke-ID is not received within RESULT_ERROR_PDU_RETRANSMISSION_INTERVAL (see 4.6.2), the PDU is retransmitted.
When provider is waiting for ESRO-ACK-PDU and a duplicate ESRO-INVOKE-PDU arrives, ESRO-RESULT-PDU or ESRO-ERROR-PDU is retransmitted (in a single PDU or in a sequence of segment PDUs), the retransmission timer is reset and counter for number of retransmissions is re-initialized to 1.
If after MAX_TRANSMISSIONS (see 4.6.2) no ESRO-ACK-PDU is received, the provider issues an ESROS-FAILURE.indication primitive, with the Invoke-ID of the failed PDU and the Failure-value as parameters, to the performer user. Then the provider sets the reference number timer and releases the reference number after REFERENCE_NUMBER_TIME (see 4.6.2).
On receipt of ESRO-ACK-PDU associated with the Invoke-ID before MAX_TRANSMISSIONS (see 4.6.2), the provider issues a ESROS-RESULT.confirm or ESROS-ERROR.confirm primitive and sets the reference number timer and releases the reference number after REFERENCE_NUMBER_TIME (see 4.6.2).
The duplicate ESRO-ACK-PDU and duplicate ESRO-INVOKE-PDUs are ignored while provider waits for the reference number timer to expire.
This Functional Unit implements the Not-Acknowledged Result model of ESRO Services. 2-Way handshaking is used in this unit.
The RESULT.confirm and ERROR.confirm primitives on performer side are generated based on time-out, i.e. when no duplicate ESRO-INVOKE-PDU is received in a specified period of time, provider issues RESULT.confirm or ERROR.confirm primitive.
The FAILURE.indication on performer side is generated as a result of local failure or after time-out of retransmission of ESRO-RESULT-PDU or ESRO-ERROR-PDU.
The FAILURE.indication on invoker side is generated if a local failure happens or a ESRO-FAILURE-PDU is received.
The transmission of INVOKE, RESULT, and ERROR PDUs can be in a single PDU (when it fits in one PDU) or a sequence of segmented PDUs.
 |
For each transition number in the state diagram above, the corresponding actions are listed below:
On receipt of an ESROS-INVOKE.request, ESROS provider generates an Invoke- Reference-Number and an Invoke-ID (see 4.2.3). The provider issues an ESROS-INVOKE-P.confirm primitive and passes the Invoke-ID to the invoker.
The ESROS provider initiates the timer for the Invoke-ID and transmits the PDU. The PDU is transmitted as a single PDU or a sequence of segment PDUs. If the ESRO- RESULT-PDU or ESRO-ERROR-PDU associated with the invoke ID is not received within the INVOKE_PDU_RETRANSMISSION_INTERVAL (see 4.6.2) period, the PDU is retransmitted. The retransmission is repeated for a maximum of MAX_RETRANSMISSIONS unless an ESRO-RESULT-PDU or ESRO-ERROR-PDU is received.
In the case that the ESRO-INVOKE-PDU is sent MAX_RETRANSMISSIONS (see 4.6.2) times and no ESRO-RESULT-PDU or ESRO-ERROR-PDU is received, the ESROS provider sends an ESROS-FAILURE.indication primitive, with the Invoke-ID of the failed PDU and the Failure-value as parameters, to the invoker. If ESRO- FAILURE-PDU is received, the ESROS provider sends and ESROS-FAILURE.indication primitive, with the Invoke-Id of the failed PDU and the Failure- value as parameters to the invoker.
When an ESRO-RESULT-PDU or ESRO-ERROR-PDU is received, the provider issues an ESROS-RESULT.indication or ESROS-ERROR.indication to the invoker user, and initializes the Reference-Number timer. In the case that duplicate ESRO-RESULT-PDU or ESRO-ERROR-PDU are received, they are ignored. In the case of internal failure, the provider initializes the reference number timer. After REFERENCE_NUMBER_TIME (see 4.6.2), the reference number is released.
 |
For each transition number in the state diagram above, the corresponding actions are listed below:
On receipt of an ESRO-INVOKE-PDU (as a single PDU or reassembled from a sequence of segment PDUs), the ESROS provider issues an ESROS-INVOKE.indication to the ESROS performer user. The provider ignores the duplicate ESRO-INVOKE-PDUs.
In the case of internal failure or no response from performer user, the provider sends an ESRO-FAILURE-PDU and releases the invoke reference number.
On receipt of either ESROS-RESULT.request or ESROS-ERROR.request from the ESROS performer user, the ESROS provider initiates the inactivity timer for the ESRO- RESULT-PDU or ESRO-ERROR-PDU and transmits the ESRO-RESULT-PDU or ESRO-ERROR-PDU (in a single PDU or as a sequence of segment PDUs.) If a duplicate ESRO-INVOKE-PDU associated with the Invoke-ID is received within INACTIVITY_TIME interval (see 4.6.2), the PDU is retransmitted.
If no duplicate ESRO-INVOKE-PDU is received within the INACTIVITY_TIME interval (see 4.6.2), provider issues a ESROS-RESULT.confirm or ESROS-ERROR.confirm primitive and sets the reference number timer and releases the reference number after REFERENCE_NUMBER_TIME (see 4.6.2).
The duplicate ESRO-INVOKE-PDUs are ignored while provider waits for the reference number timer to expire.
Small ESRO Service Data Units (ESRO-SDUs) can benefit from the efficiencies of connectionless feature of ESROS (See Section 4.3.1).
When an ESRO-SDU is too large to fit in a single connectionless PDU it is segmented and reassembled. There might be similar mechanisms in the upper layers with different levels of efficiency. When in addition to the ESROS segmentation/reassembly, the upper layers are capable of segmentation/reassembly services, then the ESROS user can decide whether to use ESROS segmenting/reassembly mechanism depending on the factors such as reliability of the underlying network.
In the case of segmentation/reassembly in ESROS layer, transmission of operation segments is not acknowledged. This results in an efficient transmission over a reliable underlying network. However failure of one segment results in retransmission of all segments.
When acknowledged segments are desired, the ESROS user should implement it using the acknowledged result service of ESROS.
The ESROS segmentation/reassembly is accommodated by:
Segmentation and Assembly applies to INVOKE, RESULT, and ERROR SDUs.
The sender of the message is responsible for segmenting the ESRO-SDU into segments that fit in CL PDUs. The segmented ESRO-SDU is sent in a sequence of segments each carrying a segment of the SDU. The Invoke-Reference-Number is a unique identifier that is used as the segment identifier which relates all segments of an ESRO-SDU. In addition to this identifier, the first segment specifies the total number of segments (number-of-segments). Other segments have a segment sequence number (segment- number). The receiver is responsible for sequencing (based on segment-number) and reassembling the entire ESRO-SDU.
The sender maps the original ESRO-SDU into an ordered sequence of segments. Several ESRO-SDU segment sequences can exist over the same ESROS association, distinguished by their Invoke-Reference-Number (used as segment identifier.)
All segments in the sequence have the same Invoke-Reference-Number assigned by sender.
The first segment specifies the total number of segments. All segments in the sequence except the first one shall be sequentially numbered, starting at 1 (first segment has an implicit segment number of 0).
Each segment is transmitted in one UDP PDU and is sent by sender. All segments of a segmented ESRO-SDU are identified by the same Invoke-Reference-Number. For a given operation, the receiver should not impose any restrictions on the order of arrival of segments.
There is no requirement that any segment content be of CLRO_SMALL_PDU_MAX_SIZE for connectionless transmission; however, no more than CLRO_MAX_PDU_SEGMENTS segments can be derived from a single ESRO-SDU.
The receiver reassembles a sequence of segments into a single ESRO-SDU. An ESRO-SDU shall not be further processed unless all segments of the ESRO-SDU are received. Failure to receive the SDU shall be determined by the following event:
In the event of the above mentioned failure, the receiver shall discard a partially assembled sequence.
The reassembly is done as described below:
Sender sends all segments of a segmented ESRO-SDU one after the other. There is no mechanism for retransmission of a single segment. In the case that the sender receives a failure indication for a segment, it means that receiver has failed in reassembly process, and the sender retransmits the whole ESRO-SDU (all segments).
The Reassembly Timer is a local timer maintained by the receiver of the segments that assists in performing the reassembly function. This timer determines how long a receiver waits to receive all segments of a segment sequence.
The Reassembly Timer shall be started on receipt of a segment with different sequence identifier (Invoke-Reference-Number). On receipt of all segments composing a sequence, the corresponding reassembly timer shall be stopped.
The value of the Reassembly Timer is defined based on the network characteristics and the number of segments. This requires that the transmission of all segments of a single ESRO-SDU must be completed within this time limit.
Five PDU types are used in the ESRO protocol which are described in the following sections. PDU type coding is presented in Table 15.
The octets are numbered in increasing order, starting from 1. The bits of an octet are numbered from 1 to 8, where 1 is the low-order bit.
Bit string format of the ESRO-INVOKE-PDU is represented in Table 16 and Table 17.
 |
Bit string format of the ESRO-RESULT-PDU is represented in Table 18 and Table 19.
Bit string format of the ESRO-ERROR-PDU is represented in Table 20 and Table 21.
Bit string format of the ESRO-ACK-PDU is represented in Table 22 and Table 23.
Bit string format of the ESROS-FAILURE-PDU is represented in Table 24 and Table 25.
The first nibble of the first octet of ESRO-FAILURE-PDU shall be set to zero.
Bit string format of the ESRO-INVOKE-SEGMENTED-PDU is represented in Table 25 and Table 26.
Note: Invoker SAP = Performer SAP - 1.
The values of the three fields Performer-SAP, Parameter-Encoding-Type, and Operation-Value of the first segment are used by performer and these fields are ignored in the segments other than the first one.
Bit string format of the ESRO-RESULT-SEGMENTED-PDU is represented in Table 28 and Table 29.
The values of the Parameter-Encoding-Type field of the first segment is used by invoker and this field is ignored in the segments other than the first one.
Bit string format of the ESRO-ERROR-PDU is represented in Table 30 and Table 31.
The values of the Parameter-Encoding-Type field of the first segment is used by invoker and this field is ignored in the segments other than the first one.
The procedure for concatenation and separation conveys multiple ESRO-PDUs in one TSDU. This is accomplished by ESRO-CONCATENATED-PDU.
An ESRO-CONCATENATED-PDU can contain one or more of the following PDUs: INVOKE, RESULT, ERROR, FAILURE, and ACK.
The ESRO-PDUs within a concatenated set may be distinguished by means of the length indicator. A one byte length indicator comes before each ESRO-PDU.
The number of ESRO-PDUs in an ESRO-CONCATENATED-PDU is bounded by the maximum length of TSDU.
The ESROS provider concatenates PDUs as follows:
When the ESRO service provider receives a PDU with PDU type code 8, it separates the concatenated PDUs as described below:
Bit string format of the ESRO-CONCATENATED-PDU containing multiple concatenated ESRO-PDUs is represented in Table 32.
This field is contained in one octet and comes before each ESROS-PDU in the concatenated PDU. The length indicated is total length of the ESRO-PDU (including header and data) coming after it in octets.
This field contains an ESRO-INVOKE-PDU, ESRO-RESULT-PDU, ESRO-ERROR- PDU, ESRO-FAILURE-PDU, or ESRO-ACK-PDU.
The length of this field is specified by the length indicator field coming before it.
The value of this parameter should be chosen based on the specifics of the subnetwork in use. For example, in CDPD the maximum size of SN-Userdata size can be up to 2048 bytes (see part 404-2.b of CDPD Specification V1.1). Based on this value and IP and UDP protocol information fields, the value of CLRO_SMALL_PDU_MAX_SIZE may be determined for CDPD. Again based on the specifics of the subnetwork, the optimum value of CLRO_SMALL_PDU_MAX_SIZE may best be determined based on field experience and may be smaller than the maximum size that the subnetwork supports.
The value of this parameter should be chosen based on the specifics of the subnetwork in use. The optimum value of CLRO_SEGMENTED_PDU_MAX_SIZE may best be determined based on field experience.
The value of this parameter should be chosen based on the specifics of the subnetwork in use. The optimum value of CLRO_MAX_PDU_SEGMENTS may best be determined based on field experience. In any case, this value should be smaller than 127.
The INVOKE_PDU retransmission interval should be specified and optimized based on the characteristics of the network in use.
The RESULT and ERROR-PDU retransmission interval should be specified and optimized based on the characteristics of the network in use.
The maximum number of retransmissions should be specified and optimized based on the characteristics of the network in use.
The minimum waiting time during which no duplicate PDU is received should be specified and optimized based on the characteristics of the network in use.
ESRO protocol uses UDP port number 259.
