IrLAP - Link Access ProtocolConceptsThe IrLAP layer uses the IrPHY layer to provide a point-to-point, reliable, error-free link over the unreliable physical medium. The IrLAP layer is responsible for establishing and maintaining a link between two remote devices and delivering data packets. Link establishment consists of device discovery and connection parameter negotiation. Once connected, apart from link maintenance, the connection is dedicated to data packet delivery. Within IrDA, there is no collision detection. A corrupted or non-received frame must be re-transmitted. Frame TypesThere are 3 frame types, used in this order during the establishment of a link:
Un-numbered (U) FramesUn-numbered (U) frames do not have either Nr or Ns counters and are used for discovery and to establish the link. Important frame types are:
Discovery of other IrDA devices is performed using a series of XID frame exchanges. An IrLAP link is established using a SNRM / UA frame exchange both of which have the seven link parameters in the info field. Optionally, an IrLAP link disconnect is performed using a DISC / UA frame exchange where the UA frame has no parameters. The other un-numbered frame types: UI, TEST, RNRM, FRMR, DM, RD are not used for IrDA lite. Supervisory (S) FramesSupervisory (S) frames have only a Nr counter and are used once an IrLAP link has been established. Of major importance is the receive ready (RR) frame type which:
The other supervisory frame types: RNR, REJ, SREJ are not used for IrDA lite. Information (I) FramesInformation (I) frames have both Nr and Ns counters and are used by higher layers for both high-level control and data transfer. Frame AcknowledgmentsFrame acknowledgments apply to information frame types only and are performed using a 'sliding window' approach using two pairs of counters. Each node has a 'Nr' and 'Ns' pair of modulo-8 counters where the:
For a given local node, the Nr counter tracks the Ns counter of the remote node. For a given IrLAP point-to-point link, these counters are associated in two pairs:
This highlights why the RR frame is of major importance - it acts as the default acknowledge for I frames, eg high level (IrLMP/IrTTP) disconnects and data. [ E3 11 ] -> A: 0x71 C/R: 1 P/F: 1 RR Nr: 0 [ E2 71 ] <- A: 0x71 C/R: 0 P/F: 1 RR Nr: 3 [ E3 11 ] -> A: 0x71 C/R: 1 P/F: 1 RR Nr: 0 [ E2 71 ] <- A: 0x71 C/R: 0 P/F: 1 RR Nr: 3 [ E3 16 84 0B 02 01 ] -> A: 0x71 C/R: 1 P/F: 1 I Nr: 0 Ns: 3 C: 1 DS: 0x04 SS: 0x0B LMP disc [ E2 91 ] <- A: 0x71 C/R: 0 P/F: 1 RR Nr: 4 [ E3 11 ] -> A: 0x71 C/R: 1 P/F: 1 RR Nr: 0 [ E2 91 ] <- A: 0x71 C/R: 0 P/F: 1 RR Nr: 4 [ E3 11 ] -> A: 0x71 C/R: 1 P/F: 1 RR Nr: 0 For the above stack dump fragment, as seen by the initial RR frame exchange, the next I frame expected by the secondary node must have Ns = 3. Once this I frame has been received (in this case, a IrLMP disconnect request), the secondary acknowledges this by sending Nr = 4 in the next RR frame. This mechanism also allows an I frame exchange where the second I frame acknowledges the first I frame. [ E3 F1 ] -> A: 0x71 C/R: 1 P/F: 1 RR Nr: 7 [ E2 51 ] <- A: 0x71 C/R: 0 P/F: 1 RR Nr: 2 [ E3 F1 ] -> A: 0x71 C/R: 1 P/F: 1 RR Nr: 7 [ E2 51 ] <- A: 0x71 C/R: 0 P/F: 1 RR Nr: 2 [ E3 F4 04 0B 00 00 61 74 0D ] -> A: 0x71 C/R: 1 P/F: 1 I Nr: 7 Ns: 2 C: 0 DS: 0x04 SS: 0x0B COMM 0:3 [ E2 7E 0B 04 01 00 61 74 0D ] <- A: 0x71 C/R: 0 P/F: 1 I Nr: 3 Ns: 7 C: 0 DS: 0x0B SS: 0x04 COMM 0:3 [ E3 11 ] -> A: 0x71 C/R: 1 P/F: 1 RR Nr: 0 [ E2 71 ] <- A: 0x71 C/R: 0 P/F: 1 RR Nr: 3 [ E3 11 ] -> A: 0x71 C/R: 1 P/F: 1 RR Nr: 0 [ E2 71 ] <- A: 0x71 C/R: 0 P/F: 1 RR Nr: 3 For the above stack dump fragment, as seen by the initial RR frame exchange, the next I frame expected by the primary node must have Ns = 7 and for the secondary node must have Ns = 2. Once the first I frame has been received (in this case, IrCOMM data), the secondary acknowledges this by sending Nr = 3 & Ns = 7 in the second I frame. The primary then acknowledges this by sending Nr = 0 in the next RR frame. For a stack dump, the Nr, Ns of both nodes may be in sync - this is purely coincidental but common and occurs when the Nr and Ns for both nodes has been initialized to zero on entering NRM and there is an equal count of I frames exchanged between the primary and secondary nodes. [ 03 D1 ] -> A: 0x01 C/R: 1 P/F: 1 RR Nr: 6 [ 02 D1 ] <- A: 0x01 C/R: 0 P/F: 1 RR Nr: 6 [ 03 D1 ] -> A: 0x01 C/R: 1 P/F: 1 RR Nr: 6 [ 02 D1 ] <- A: 0x01 C/R: 0 P/F: 1 RR Nr: 6 [ 03 D1 ] For the above stack dump fragment, as seen by the RR frame exchange, the Nr for both nodes are in sync with the next expected I frame for both nodes must have Ns = 7. ServicesIrLAP supports these services:
IrLAP services use the two mandatory bytes of the IrLAP header. Service 1 of 4 - DiscoveryInitially, the link state is in normal disconnect mode (NDM). The secondary node(s) is discovered by the primary node with the sending of XID command frames, one per slot, which invite the secondary node to respond in one slot with an XID response frame. The seven initial parameters for an IrDA link include:
Both discovery and negotiation are performed using these default, 'lowest common denominator', well-known values for all seven parameters. For discovery, the XID to SNRM command frame timing is not specified by the IrDA specifications. After the primary node has sent the XID slot end command, the SNRM command must then be sent immediately. If not, some secondary nodes do not give a UA response to the SNRM command. This behaviour is seen for Nokia 6310 and Ericsson T68 mobile phones. Service 2 of 4 - Negotiation and ConnectionAfter discovery, link parameters are negotiated using a SNRM / UA frame exchange. Once the UA has been sent, on the subsequent RR frame exchange, the link is deemed connected at the IrLAP level and the link state moves to normal response mode (NRM). From this point onwards, the 32-bit device address is not used but the new 'session' 7-bit connection address is then used in the IrLAP header. During negotiation, after the secondary has sent the UA response, the time that the primary must wait before sending the RR command (at the new baud-rate) is not specified by the IrDA specifications and is implementation dependent. This must not be zero and must be less than about 100ms. A time of zero does not give the secondary sufficient time to change the baud-rate etc. For Nokia 6310 and Ericsson T68 mobile phones, a value of 50ms seems optimal. During the negotiation phase, on the SNRM / UA frame exchange, the primary and secondary may negotiate to change any of the seven link parameters to the minimum of the common set. Service 3 of 4 - Data TransferOnce connected, RR and I frames are exchanged with I frames containing payload data from the higher layers. Service 4 of 4 - DisconnectionAfter an IrLAP disconnect, the link state reverts back to NDM where there is no longer a logical connection at the IrLAP layer. To proceed, the primary must initiate a new discovery sequence. Microlite-IrDA NotesOne slot discovery is used - this forces a point-to-point link. For the IrLAP negotiation parameters, only the default speed of 9600 bps offered:
|
![]() |
![]() |
![]() |
© Copyright Kea Computing Ltd 2021 - All rights reserved | Legal Notice | Terms of Use | Kea Computing Ltd |
![]() |