8 Definition of the LLC peer-to-peer protocol

04.643GPPGeneral Packet Radio Service (GPRS)Mobile Station - Serving GPRS Support Node (MS-SGSN) Logical Link Control (LLC) layer specificationTS

8.1 General

In the following subclauses, a protocol for use by the GPRS logical link control layer between the SGSN and MS is specified, referred to as "LLC".

The LLC elements of procedure (frame types) that apply are:

– for unacknowledged information transfer:

– UI command; and

– for ABM acknowledged information transfer:

– SABM command;

– UA response;

– DM response;

– DISC command;

– RR command / response;

– RNR command / response;

– ACK command / response;

– SACK command / response;

– I command / response; and

– for both unacknowledged and acknowledged information transfer:

– FRMR response; and

– XID command / response.

For handling of timers, the procedures and terminology of Z.100 [15] are used:

Set <timer name> means that:

a) if the timer is inactive, the timer becomes active, i.e., a timer value is associated with the timer and it starts running; and

b) if the timer is active, the timer is first reset as in c) below, and then set as in a) above.

Reset <timer name> means that:

c) if the timer is active, the timer becomes inactive, i.e., the association with the timer value is lost and it stops running; and

d) if the timer is inactive, it remains inactive.

8.2 Procedure for the use of the P/F bit

Timer T200 shall be set when a command frame with the P bit set to 1 is transmitted. An LLE receiving a command frame with the P bit set to 1 shall set the F bit to 1 in the next response frame it transmits. An LLE receiving a command frame with the P bit set to 0 shall discard the command frame with no further action.

Only one frame with a P bit set to 1 shall be outstanding in a given direction at a given time. Before another frame with the P bit set to 1 can be transmitted, a response frame with the F bit set to 1 shall be received, N200 retransmissions of the outstanding frame shall occur, or the frame shall be discarded because of an unnumbered frame collision.

8.3 TLLI assignment procedures

TLLI assignment and unassignment is further described in clause 7 and annex B. The following two subclauses illustrate the TLLI assignment and unassignment procedures.

8.3.1 TLLI assignment

GMM shall assign a TLLI by sending an LLGMM-ASSIGN-REQ (TLLI New  all 1’s) primitive to LLME. Upon receiving LLGMM-ASSIGN-REQ, LLME shall enter the TLLI Assigned state, and set LLC layer parameters, states, and variables as defined in subclause 8.5.3.1. TLLI assignment is illustrated in Figure 12.

8.3.2 TLLI change

This procedure is used to change from a previously assigned TLLI value to a new TLLI value. GMM shall change TLLI by sending an LLGMM-ASSIGN-REQ (TLLI Old  all 1’s, TLLI New  all 1’s) primitive to LLME. Upon receiving LLGMM-ASSIGN-REQ, LLME and all its LLEs shall not change their states. This is illustrated in Figure 12.

8.3.3 TLLI unassignment

This procedure is used to unassign a previously assigned TLLI value. GMM shall unassign a TLLI by sending an LLGMM-ASSIGN-REQ (TLLI New = all 1’s) primitive to LLME. Upon receiving LLGMM-ASSIGN-REQ, LLME and all its LLEs shall enter the TLLI Unassigned state. This is illustrated in Figure 12.

Figure 12: TLLI assignment, change, and unassignment procedure

8.4 Procedures for unacknowledged information transfer

The procedures that apply to the unacknowledged transmission of information are defined below. No LLC layer error recovery procedures are defined for unacknowledged operation.

Figure 13: Unacknowledged information transmission

8.4.1 Transmission of unacknowledged information

Unacknowledged information shall be passed from layer 3 to the LLC layer with the LL-UNITDATA-REQ (L3‑PDU, Protect, Cipher) primitive. The L3‑PDU shall be transmitted in a UI command frame to the peer LLE. The PM and E bits in the UI frame shall be set according to the Protect and Cipher parameters received from layer 3.

8.4.2 Receipt of unacknowledged information

On receipt of a UI command frame the contents of the information field shall be passed to the appropriate layer‑3 entity with an LL-UNITDATA-IND (L3‑PDU) primitive, except:

– if the DLCI of the received UI frame is not supported by the receiver; or

– if N(U) of the received UI frame is in the range ( V(UR) ‑ 32 )  N(U)  V(UR) and if a UI frame with the same N(U) has already been received,

then the UI frame shall be discarded without any further actions.

V(UR) shall be set to N(U) + 1 unless N(U) is in the range ( V(UR) ‑ 32 )  N(U)  V(UR).

8.5 Procedures for establishment and release of ABM operation

8.5.1 Establishment of ABM operation

8.5.1.1 General

These procedures shall be used to establish ABM operation between the SGSN and an MS for a single SAPI.

Layer 3 shall request establishment of ABM operation by use of the LL-ESTABLISH-REQ service primitive. Re-establishment may be initiated as a result of the LLC layer procedures defined in subclause 8.7. All frames other than U and UI frames received during the establishment procedures shall be ignored.

8.5.1.2 Establishment procedures

An LLE shall initiate a request for the ABM operation to be set by transmitting the SABM command. All existing exception conditions shall be cleared, the retransmission counter shall be reset, and timer T200 shall be set. All mode-setting commands shall be transmitted with the P bit set to 1.

Layer 3-initiated establishment procedures imply the discard of all outstanding LL-DATA-REQ primitives and all queued I frames.

An LLE receiving a SABM command, if it is able to enter the ABM state, shall:

– inform layer 3 using the LL-ESTABLISH-IND primitive;

– if the received SABM command contains a Layer‑3 Parameters XID parameter, wait for the receipt of an LL-ESTABLISH-RES primitive from layer 3;

– respond with a UA response with the F bit set to the same binary value as the P bit in the received SABM command (i.e., F=1);

– reset timer T200 if active;

– set V(S), V(R), V(A), and B to 0;

– enter the ABM state;

– clear all existing exception conditions; and

– clear any existing peer receiver busy condition.

Upon reception of the UA response with the F bit set to 1, the originator of the SABM command shall:

– reset timer T200;

– set V(S), V(R), V(A), and B to 0; and

– enter the ABM state and inform layer 3 using the LL-ESTABLISH-CNF or LL-ESTABLISH-IND (see subclause 8.7.2) primitive.

Figure 14: Layer 3-initiated ABM establishment procedure

If the receiving LLE is unable to enter the ABM state, it shall respond to the SABM command with a DM response with the F bit set to the same binary value as the P bit in the received SABM command. ABM operation for SAPIs 1 and 7 is not permitted, and reception of a SABM command for these SAPIs shall be responded to with a DM response.

Upon reception of a DM response with the F bit set to 1, the originator of the SABM command shall indicate this to layer 3 by means of the LL-RELEASE-IND (Cause = ‘DM Received’) primitive, and reset timer T200. It shall then enter the ADM state. DM responses with the F bit set to 0 shall be ignored in this case.

Figure 15: Layer 3‑initiated ABM establishment procedure, unsuccessful

An LL-RELEASE-REQ primitive received during LLC layer initiated re-establishment shall be serviced on completion of the establishment operation.

8.5.1.3 Procedure on expiry of timer T200

If timer T200 expires before the UA or DM response with the F bit set to 1 is received, the LLE shall:

– retransmit the SABM command as defined above;

– set timer T200; and

– increment the retransmission counter.

After retransmission of the SABM command N200 times, LLME shall indicate this to GMM by means of the LLGMM-STATUS-IND primitive, and the LLE shall send an LL-RELEASE-IND (Cause = ‘No Peer Response’) to layer 3 and enter ADM state. If XID parameters were included with the SABM command, then the status of these parameters in the peer is unknown and should be re-negotiated.

8.5.2 Termination of ABM operation

8.5.2.1 General

These procedures shall be used to terminate ABM operation between the SGSN and an MS.

Layer 3 shall request termination of ABM operation by use of the LL-RELEASE-REQ service primitive. All frames other than U and UI frames received during the release procedures shall be ignored.

All outstanding LL-DATA-REQ primitives and all queued I frames shall be discarded.

If the Local parameter received in the LL-RELEASE-REQ primitive indicates local release, the LLE shall enter ADM state, reset timer T200, and notify layer 3 by means of the LL-RELEASE-CNF primitive. Otherwise, the procedures in subclauses 8.5.2.2 and 8.5.2.3 shall be followed.

8.5.2.2 Release procedure

An LLE shall initiate a request for release of the ABM operation by transmitting the DISC command with the P bit set to 1. Timer T200 shall then be set and the retransmission counter reset.

An LLE receiving a DISC command while in ABM state shall transmit a UA response with the F bit set to the same binary value as the P bit in the received DISC command. An LL-RELEASE-IND (Cause = ‘Normal Release’) primitive shall be passed to layer 3, and the ADM state shall be entered.

If the originator of the DISC command receives either:

– a UA response with the F bit set to 1; or

– a DM response with the F bit set to 1, indicating that the peer LLE is already in ADM state;

it shall enter the ADM state and reset timer T200.

The LLE that issued the DISC command is now in the ADM state and shall notify layer 3 by means of the LL-RELEASE-CNF primitive. The conditions relating to this state are defined in subclause 8.5.4.

Figure 16: ABM release procedure

8.5.2.3 Procedure on expiry of timer T200

If timer T200 expires before a UA or DM response with the F bit set to 1 is received, the originator of the DISC command shall:

– retransmit the DISC command as defined in subclause 8.5.2.2;

– set timer T200; and

– increment the retransmission counter.

If the LLE has not received the correct response as defined in subclause 8.5.2.2 after N200 attempts to recover, then LLME shall indicate this to GMM by means of the LLGMM-STATUS-IND primitive, and the LLE shall enter the ADM state and notify layer 3 by means of the LL-RELEASE-CNF primitive.

8.5.3 Automatic negotiation of LLC layer and layer‑3 parameters

Each LLE has an associated LLME that has the responsibility for initialising the LLC layer parameters necessary for correct peer-to-peer information transport. Initialisation of the parameters shall be done either according to the default values, or according to the values supplied by the peer entity. The latter method utilises the parameter negotiation procedure. The negotiable parameters are listed in Table 6.

LLC layer and layer‑3 parameters may be negotiated in ADM or ABM modes of operation. LLC layer and layer‑3 parameters may be negotiated with the exchange of XID frames, or with the exchange of SABM and UA frames. After successful negotiation with SABM and UA frames, the LLE shall be in ABM mode of operation, according to subclauses 8.5.1 and 8.7.

The LLE shall issue an XID command containing the parameters that the LLE wants to negotiate, and set timer T200. The peer LLE shall, upon receipt of the XID command, return an XID response containing the list of parameter values that the peer can support. Timer T200 shall be reset when the XID response is received. XID frames shall be transmitted with the P/F bit set to 1. This is illustrated in Error: Reference source not foundFigure 17.

Figure 17: XID negotiation procedure

LL-XID-IND shall be indicated to layer 3 if N201‑U or N201‑I have been changed.

XID frames can be used to negotiate layer‑3 parameters. In this case, layer 3 sends the parameters to an LLE with the LL-XID-REQ primitive. The LLE shall issue an XID command containing the layer‑3 parameters, and LLC layer parameters if any LLC layer parameters shall be negotiated. The peer LLE shall, upon receipt of the XID command, indicate the layer‑3 parameters to layer 3 and upon receipt of an LL-XID-RES primitive return an XID response containing the list of parameter values that the peer can support. The layer‑3 parameters received from the peer is sent to layer 3 with the LL-XID-CNF primitive. The LLE issuing the XID command shall set timer T200 when the XID command is transmitted, and reset timer T200 when the XID response is received. This is illustrated in Figure 18.

Figure 18: Layer 3 XID negotiation procedure

8.5.3.1 Negotiation of parameter Reset

The Reset parameter shall be used, in the SGSN originating Reset and in the MS receiving Reset, to:

– discard all requests pending from layer 3 to the LLEs with no further action;

– abort any ongoing ABM establishment, ABM release, and XID negotiation procedures, except the XID negotiation procedure used to negotiate the Reset parameter;

– set all LLC layer parameters to the default values given in Table 9;

– change any LLEs in ABM state to ADM state;

– set the unconfirmed state variable V(U) to 0;

– set the unconfirmed receive state variable V(UR) to 0; and

– set the OCs for unacknowledged information transfer to 0.

The Reset parameter shall be treated before any additional XID parameters present in the same XID frame.

8.5.3.2 Negotiation of parameter m

The following rules shall apply when mD and mU are negotiated:

– If mD is negotiated to 0, then the LLEs shall not keep count of outstanding I frame octets in the downlink direction. If mU is negotiated to 0, then the LLEs shall not keep count of outstanding I frame octets in the uplink direction.

– If a SABM or XID command with mD  0 is received in an LLE, and if the LLE does not want to apply the count of outstanding I frame octets in the downlink direction, then the LLE shall respond with mD = 0 and with N201‑I and kD so that N201‑I multiplied with kD is less than or equal to the received MD.

– If a SABM or XID command with mU  0 is received in an LLE, and if the LLE does not want to apply the count of outstanding I frame octets in the uplink direction, then the LLE shall respond with mU = 0 and with N201‑I and kU so that N201‑I multiplied with kU is less than or equal to the received MU.

– mD and mU shall be negotiated to values that allow at least one I frame with information field length equal to the negotiated value of N201‑I to be transmitted in each direction.

8.5.3.3 Unsuccessful XID negotiation

If a SABM or XID command with an invalid XID information field is received, then the SABM or XID command, respectively, shall be ignored.

If a UA or XID response with an invalid XID information field is received, then the UA or XID response shall be ignored, the SABM or XID command shall be retransmitted, and the retransmission counter shall be incremented. After retransmission of the SABM or XID command N200 times, LLME shall indicate this to GMM by means of the LLGMM-STATUS-IND primitive, and the LLE shall send an LL-RELEASE-IND (Cause = ‘Invalid XID Response’) to layer 3 if a UA response was received or if the LLE was in ABM state, and enter ADM state if not already in ADM state. If the LLE was in ADM state and the XID command frame contained a Layer‑3 Parameters XID parameter, then the LLE shall send an LL-STATUS-IND (Cause = ‘Invalid XID Response’) to layer 3.

An XID information field shall be treated as invalid if it:

– contains an XID parameter field that violates the LLC frame format (see Figure 3);

– contains the Reset, IOV‑UI, or IOV‑I parameter in the uplink direction;

– contains the IOV‑I parameter in an XID frame;

– contains the Layer‑3 Parameters parameter on a SAPI different from 3, 5, 9, and 11;

– in the SABM command case, contains the Reset parameter;

– contains the Reset parameter and this parameter is not the first parameter in the XID information field; or

– in the UA or XID response case:

– contains the Reset parameter;

– contains more than one instance of the same XID parameter type;

– contains an XID parameter with unrecognised Type field;

– contains an XID parameter with unsupported length;

– contains an XID parameter with a value that violates the sense of negotiation; or

– contains an XID parameter with a value that is out of range (see Table 6).

If a SABM or XID command with an XID parameter with an unrecognised Type field is received, then this parameter shall be ignored. If a SABM or XID command contains more than one instance of the same XID parameter type, then all instances except the first instance shall be ignored. If the received XID information field is valid, and if one or more XID parameters with recognised type but with unsupported lengths or out-of-range values are detected, then these parameters shall be responded to with lengths and values set according to the responder’s preferences.

8.5.3.4 Procedure on expiry of timer T200

If timer T200 expires before the XID response with the F bit set to 1 is received, the LLE shall:

– retransmit the XID command;

– set timer T200; and

– increment the retransmission counter.

After retransmission of the XID command N200 times, LLME shall indicate this to GMM by means of the LLGMM-STATUS-IND primitive, and, if the LLE is in ABM state, then the LLE shall send an LL-RELEASE-IND (Cause = ‘No Peer Response’) to layer 3 and enter ADM state. If the LLE was in ADM state and the XID command frame contained a Layer‑3 Parameters XID parameter, then the LLE shall send an LL-STATUS-IND (Cause = ‘No Peer Response’) to layer 3. The status of the XID parameters that were included in the XID command is unknown in the peer, and should be re-negotiated. If the XID command frame did not contain a Layer‑3 Parameters XID parameter, then, as an implementation option, the LLE may wait for an implementation-specific amount of time and re-invoke the XID negotiation procedure.

8.5.4 TLLI Assigned / ADM state

While in the TLLI Assigned / ADM state:

– the receipt of a DISC command shall result in the transmission of a DM response with the F bit set to the value of the received P bit;

– on receipt of a SABM command, the procedures defined in subclause 8.5.1 shall be followed;

– on receipt of UI commands, the procedures defined in subclause 8.4 shall be followed;

– on receipt of XID commands, the procedures defined in subclause 8.5.3 shall be followed;

– on receipt of any unsolicited UA response an LLGMM-STATUS-IND primitive indicating a possible multiple- assignment of a TLLI value shall be issued;

– the receipt of an S or I+S command frame shall result in the transmission of a DM response with the F bit set to 0; and

– all other frame types shall be discarded.

8.5.5 Collision of unnumbered commands

In the collision cases in this subclause, if the XID or SABM command that shall be ignored and treated as not transmitted contains one or more XID parameters that are not negotiated as part of the collision resolution, then negotiation of these XID parameters shall be performed at the earliest opportunity after conclusion of the collision resolution.

An XID command with a valid XID information field that contains the Reset parameter shall not be ignored, and this requirement takes precedence over the collision cases in this subclause.

8.5.5.1 Identical transmitted and received commands

If the transmitted and received unnumbered commands are SABM commands and a Layer‑3 Parameters XID parameter is present in both or in neither, then the SABM command transmitted by the SGSN shall be ignored and treated as not transmitted. The LLE in the SGSN shall send the UA response at the earliest possible opportunity if it is able to enter ABM.

If the transmitted and received unnumbered commands are a SABM command with a Layer‑3 Parameters XID parameter and a SABM command without a Layer‑3 Parameters XID parameter, then the SABM command without Layer-3 Parameters shall be ignored and treated as not transmitted. This is illustrated in Figure 19.

Figure 19: Collision between LLE-initiated and layer 3-initiated ABM establishment procedure

If the transmitted and received unnumbered commands are DISC commands, then the LLEs shall send the UA response at the earliest possible opportunity, and enter ADM state after receiving the UA response. The LLEs shall notify layer 3 by means of the LL-RELEASE-CNF primitive.

If the transmitted and received unnumbered commands are XID commands and a Layer‑3 Parameters XID parameter is present in both or in neither, then the XID command transmitted by the SGSN shall be ignored and treated as not transmitted.

If the transmitted and received unnumbered commands are an XID command with a Layer‑3 Parameters XID parameter and an XID command without a Layer‑3 Parameters XID parameter, then the XID command without Layer-3 Parameters shall be ignored and treated as not transmitted.

8.5.5.2 Different transmitted and received commands

If the transmitted and received unnumbered commands are a SABM and a DISC command, the LLEs shall issue a DM response at the earliest possible opportunity. Upon receipt of a DM response with the F bit set to 1, the LLE shall enter the ADM state and notify layer 3 by means of the appropriate primitive. The LLE receiving the DISC command shall issue an LL-RELEASE-IND (Cause = ‘Normal Release’) primitive, while the other LLE shall issue an LL-RELEASE-CNF primitive.

If the transmitted unnumbered command is a SABM command, and the received unnumbered command is an XID command, then the LLE shall ignore the received XID command.

If the transmitted unnumbered command is an XID command, and the received unnumbered command is a SABM command, then the LLE shall send the UA response at the earliest possible opportunity if it is able to enter ABM. The transmitted XID command shall be treated as not transmitted.

If the transmitted and received unnumbered commands are a DISC and an XID command, then this shall not be considered a collision.

8.5.6 Unsolicited DM response and SABM or DISC command

When a DM response with the F bit set to 0 is received by an LLE, a collision between a transmitted SABM or DISC command and the unsolicited DM response may have occurred.

In order to avoid misinterpretation of the DM response received, an LLE shall always send its SABM or DISC command with the P bit set to 1.

A DM response with the F bit set to 0 colliding with a SABM or DISC command shall be ignored.

8.6 Procedures for information transfer in ABM operation

Having either transmitted the UA response to a received SABM command or received the UA response to a transmitted SABM, I frames and supervisory frames may be transmitted and received. The procedures that apply to the transmission of I frames are defined below.

NOTE: The term "transmission of an I frame" refers to the delivery of an I frame by the LLC layer to the RLC/MAC or BSSGP layer.

Each LLE shall store the history of the transmitted I frames, i.e., the LLE shall remember the I‑frame transmission sequence. The history is used to decide which I frames to retransmit. Due to retransmission, the history is not necessarily an in-order sequence.

A frame within the receive window is either:

– received: the frame has been correctly received; or

– not received: the frame has not been correctly received.

A frame within the transmit window is either:

– not yet transmitted: the frame has not yet been transmitted;

– transmitted: the frame has been (re‑)transmitted, but the LLE does not know if the frame has been received in the peer LLE;

– acknowledged: the frame has been acknowledged by the peer LLE; or

– marked for retransmission: the LLE has decided to retransmit this I frame.

I frames shall be transmitted in ascending N(S) order. When I frames are retransmitted, the frame with the lowest N(S) shall be retransmitted first. This is used by the receiving LLE to detect lost frames as described in subclause 8.6.3.1.

8.6.1 Transmitting I frames

Information received by the LLE from layer 3 by means of an LL-DATA-REQ primitive shall be transmitted in an I frame, provided that the LLE is not in the peer receiver busy condition. The control field parameters N(S) and N(R) shall be assigned the values V(S) and V(R), respectively. V(S) shall be incremented by 1 at the end of the transmission of the I frame.

The I frame buffer variable B shall be incremented with the length of the information field of I frame number N(S), so that B = B + L(N(S)). The value of B shall never exceed M. If L(N(S))  M ‑ B (where M is the maximum buffer size – see subclause 8.9.7), then the LLE shall not transmit any new I frames, but may retransmit I frames as a result of the error recovery procedures as described in subclauses 8.6.3 and 8.6.6.

When there is an opportunity to transmit a frame, then the LLE shall do one of the following in order of priority:

– If there are any I frames marked for retransmission and if the LLE is not in the peer receive busy condition, then the LLE shall increment by 1 the retransmission count variable for the I frame with the lowest send sequence number N(S). If the retransmission count variable exceeds the value of N200, then the LLE shall initiate the re-establishment procedure as described in subclause 8.7.2. If the retransmission count variable does not exceed the value of N200, then the LLE shall retransmit the I frame.

– If the LLE has a new I frame to transmit, if V(S)  V(A) + k (where k is the maximum number of outstanding I frames – see subclause 8.9.8), and if the LLE is not in the peer receiver busy condition, then the new I frame shall be transmitted.

– If the LLE has an acknowledgement to transmit (see subclause 8.6.3.1), then the LLE shall transmit an S frame.

If the LLE wants to request an acknowledgement (see subclause 8.6.3.3), then the A bit of the transmitted frame shall be set to 1.

When the SGSN or MS is in the own receiver busy condition, it may still transmit I frames, provided that a peer receiver busy condition does not exist.

Figure 20: Transmitting and receiving I frames

8.6.2 Receiving I frames

When an LLE is not in the own receiver busy condition and receives a valid I frame whose N(S) is equal to the current V(R), the LLE shall:

– pass the information field of this frame to layer 3 using the LL-DATA-IND primitive;

– increment by 1 its V(R); and

– if the A bit of the received I frame was set to 1, then the LLE shall respond to its peer with an RR, RNR, SACK, or ACK frame (see subclause 8.6.4.1).

When an LLE receives a valid I frame whose N(S) is not in the range V(R)  N(S)  V(R) + k, the LLE shall discard the frame as a duplicate.

When an LLE is not in the own receiver busy condition and receives a valid I frame where V(R)  N(S)  V(R) + k, then the LLE shall store the I frame until all frames from V(R) to N(S) ‑ 1 inclusive are correctly received. The LLE shall use the control field information of the received I frame before storing the frame. The LLE shall then:

– pass the information field of this I frame to layer 3 using the LL-DATA-IND primitive; and

– set its V(R) = N(S) + 1.

When an LLE receives a valid I frame and the LLE is in the own receiver busy condition, then the acceptance of the I frame is implementation dependent.

8.6.3 Sending and receiving acknowledgements

NOTE: Sending and receiving acknowledgements refer to the transmission and reception of frames carrying ABM acknowledgement information, i.e., I+S and S frames.

8.6.3.1 Sending acknowledgements

Whenever an LLE receives a frame with the A bit set to 1, it shall transmit an I+S or S frame. Whenever an LLE detects an error in the sequence of received I frames, it shall transmit an I+S or S frame. The supervisory function bits of the transmitted frame shall be set according to subclause 8.6.4.1.

The receiving LLE shall use the knowledge of the (re‑)transmission strategy of its peer LLE (see subclause 8.6.1) to detect sequence errors. If the LLE receives an I frame with a higher N(S) than the N(S) of the previously received I frame, and if there are I frames missing between these two N(S) values, then the LLE shall assume that the missing I frames have been lost. If the LLE receives an I frame with a lower N(S) than the N(S) of the previously received I frame, it can assume that its peer LLE has (re‑)started retransmission due to the reception of an acknowledgement.

8.6.3.2 Receiving acknowledgements

On receipt of a valid I+S or S frame , the LLE shall, if N(R) is valid, treat the N(R) contained in this frame as an acknowledgement for all the I frames it has transmitted with an N(S) up to and including the received N(R) ‑ 1. A valid N(R) value is one that is in the range V(A)  N(R)  V(S). If N(R) is not valid, then the received A bit shall be treated as defined in subclause 8.6.3.1, and N(R), and the SACK bitmap if received, shall be disregarded.

For each I frame transmitted with N(S) in the range V(A)  N(S)  N(R):

– the LLE shall issue an LL-DATA-CNF primitive to layer 3 to confirm the delivery of an L3‑PDU to layer 3 in the peer; and

– the frame length L(N(S)) shall be subtracted from the I frame buffer variable B, so that B = B ‑ L(N(S)). The value of B shall never be less than 0.

V(A) shall then be set to N(R).

On receipt of a valid ACK frame, the LLE shall consider the I frame transmitted with sequence number N(R) + 1 as acknowledged.

On receipt of a valid SACK frame, the LLE shall consider all I frames with the corresponding bit set to 1 in the SACK bitmap as acknowledged.

If timer T201 is active and associated with an acknowledged I frame, then timer T201 shall be reset.

The LLE shall determine which I frames to retransmit by analysing its I frame transmission sequence history and the acknowledgements received. An unacknowledged I frame that was transmitted prior to an acknowledged I frame shall be considered lost and shall be marked for retransmission. Acknowledged I frames shall be removed from the I frame transmission sequence history.

8.6.3.3 Requesting acknowledgements

The LLE shall request an acknowledgement from the peer LLE by transmitting an I+S or S frame with the A bit set to 1. The LLE may request an acknowledgement at any time. An acknowledgement shall be requested when:

– the last I frame in a sequence of one or more I frames is transmitted; or

– B  M ‑ N201 as a result of the transmission of the I frame, unless the next I frame to be transmitted is available and has an information field length that is less than or equal to M ‑ B; or

– V(S) = V(A) + k as a result of the transmission of the I frame.

When requesting an acknowledgement, the LLE shall set timer T201 and associate the timer with the I frame currently being transmitted, or, if the A bit is transmitted in an S frame, with the I frame last transmitted.

8.6.4 Peer receiver busy condition

After receiving a valid RNR frame, the LLE shall:

– set a peer receiver busy condition;

– not transmit nor retransmit any I frames to the peer LLE;

– treat the N(R) contained in the received RNR frame as an acknowledgement for all the I frames that have been (re‑)transmitted with an N(S) up to and including N(R) ‑ 1, and set its V(A) to the value of the N(R) contained in the RNR frame;

– set timer T201 to initiate the inquiry process; and

– reset the retransmission count variable.

If timer T201 expires, the LLE shall:

– if the value of the retransmission count variable is less than N200:

– transmit an appropriate supervisory frame (see subclause 8.6.4.1) with an A bit set to 1;

– set timer T201; and

– add one to its retransmission count variable;

– if the value of the retransmission count variable is equal to N200, initiate a re-establishment procedure as defined in subclause 8.7. LLME shall indicate this by means of the LLGMM-STATUS-IND primitive to GMM.

The LLE receiving the supervisory frame with the A bit set to 1 shall respond, at the earliest opportunity, with an appropriate supervisory frame (see subclause 8.6.4.1) to indicate whether or not its own receiver busy condition still exists.

Upon receipt of the supervisory frame, the LLE shall reset timer T201, and:

– if the frame is an RR, ACK or SACK frame:

– the peer receiver busy condition shall be cleared;

– if timer T201 was active before the peer receiver busy condition was set, and if the associated I frame is still not acknowledged, then timer T201 shall be set and associated with the same I frame; and

– the LLE may transmit new I frames or retransmit I frames as defined in subclauses 8.6.1 or 8.6.3, respectively; or

– if the frame is an RNR frame, then the LLE shall proceed according to subclause 8.6.4, first paragraph.

Upon receipt of a SABM command, the LLE shall clear the peer receiver busy condition.

8.6.4.1 Supervisory frame selection

If the LLE is in the own receiver busy condition, the appropriate supervisory frame is the RNR frame.

Otherwise, if the highest-numbered I frame was received with N(S) = V(R), the appropriate supervisory frame is the RR frame.

Otherwise, if the highest-numbered I frame was received with N(S) = V(R) + 1, the appropriate supervisory frame is the ACK frame.

Otherwise, the appropriate supervisory frame is the SACK frame.

8.6.5 Own receiver busy condition

When the LLE enters the own receiver busy condition, it shall transmit an RNR frame at the earliest opportunity.

All received I frames may be discarded, after updating V(A). If the A bit of a received I frame was set to 1, then the LLE shall transmit an RNR frame.

All received supervisory frames shall be processed, including updating V(A). If the A bit of a received S frame was set to 1, then the LLE shall transmit an RNR frame.

To indicate to the peer LLE the clearance of the own receiver busy condition, the LLE shall transmit an appropriate supervisory frame (see subclause 8.6.4.1).

The transmission of a SABM command or a UA response (in reply to a SABM command) also indicates to the peer LLE the clearance of the own receiver busy condition.

8.6.6 Waiting for acknowledgement

Frames may be lost any time during transmission due to e.g., transmission errors. An LLE that has not received acknowledgement for a transmitted I frame shall therefore on the expiry of timer T201 take appropriate recovery action.

The LLE shall maintain an internal retransmission count variable for each transmitted I frame.

If timer T201 expires, the LLE shall increment by 1 the retransmission count variable for the I frame associated with timer T201, and:

– if the value of the retransmission count variable does not exceed N200, set timer T201, and retransmit the I frame with the A bit set to 1; or

– if the value of the retransmission count variable exceeds N200, initiate a re-establishment procedure as defined in subclause 8.7.2. LLME shall indicate this by means of the LLGMM-STATUS-IND primitive to GMM.

8.7 Re-establishment of ABM operation

8.7.1 Criteria for re-establishment

The criteria for re-establishing the ABM mode of operation are defined in this clause by the following conditions:

– the receipt, while in the ABM state, of a SABM;

– the receipt of an LL-ESTABLISH-REQ primitive from layer 3 (see subclause 8.5.1.1);

– the occurrence of N200 retransmission failures (see subclauses 8.6.4 and 8.6.6);

– the occurrence of a frame rejection condition as identified in subclause 8.8.2; and

– the receipt of an unsolicited DM response with the F bit set to 0 (see subclause 8.8.4) while in ABM state.

8.7.2 Procedures

In all re-establishment situations, the LLE shall follow the procedures defined in subclause 8.5.1. All locally-generated conditions for re-establishment shall cause the transmission of the SABM.

In the case of LLC layer and peer-initiated re-establishment, the LLE shall issue an LL-ESTABLISH-IND primitive to layer 3 and discard all outstanding LL-DATA-REQ primitives and all queued I frames, and LLME shall issue an LLGMM-STATUS-IND primitive to GMM.

In case of layer 3-initiated re-establishment, or if an LL-ESTABLISH-REQ primitive occurs pending re-establishment, the LL-ESTABLISH-CNF primitive shall be used.

Figure 21: LLC-initiated ABM re-establishment procedure

8.8 Exception condition reporting and recovery

Exception conditions may occur as the result of lower layer errors or LLC layer procedural errors.

The error recovery procedures available to effect recovery following the detection of an exception condition at the LLC layer are defined in this subclause.

8.8.1 Invalid frame condition

Any received invalid frame shall be discarded, and no action shall be taken as a result of that frame.

8.8.2 Frame rejection condition

A frame rejection condition results from one of the conditions described in subclause 6.4.1.5 items 1) to 3).

Upon occurrence of a frame rejection condition, the LLME shall issue an LLGMM-STATUS-IND primitive; and the LLE shall:

– discard the frame causing the frame rejection condition;

– transmit a FRMR response frame; and

– if the LLE is in ABM operation, initiate re-establishment (see subclause 8.7.2).

8.8.3 Receipt of a FRMR response frame

Upon receipt of a FRMR response frame, the LLME shall issue an LLGMM-STATUS-IND primitive.

8.8.4 Unsolicited response frames

The action to be taken on the receipt of an unsolicited response frame is defined in Table 8. Upon the receipt of an unsolicited UA response, the LLE shall assume a possible multiple-TLLI assignment, and LLME shall inform GMM by means of the LLGMM-STATUS-IND primitive.

Table 8: Actions taken on receipt of unsolicited response frames

Unsolicited

State

Response
Frame

TLLI Assigned
/ ADM

Local
Establishment

Local
Release

ABM

Timer
Recovery

UA response
F = 1

LLGMM-STATUS-IND

Solicited

Solicited

LLGMM-STATUS-IND

LLGMM-STATUS-IND

UA response
F = 0

LLGMM-STATUS-IND

LLGMM-STATUS-IND

LLGMM-STATUS-IND

LLGMM-STATUS-IND

LLGMM-STATUS-IND

DM response
F = 1

Ignore

Solicited

Solicited

LLGMM-STATUS-IND

LLGMM-STATUS-IND

Re-establish ABM

DM response
F = 0

Ignore

Ignore

Ignore

LLGMM-STATUS-IND

Re-establish ABM

LLGMM-STATUS-IND

Re-establish ABM

Supervisory
response

Ignore

Ignore

Ignore

Solicited

Solicited

A UA or XID response frame with the F bit set to 1, and that does not contain a Layer‑3 Parameters XID parameter, received while a SABM or XID command respectively that does contain a Layer‑3 Parameters XID parameter is outstanding, shall be ignored.

A UA or XID response frame with the F bit set to 1, and that contains a Layer‑3 Parameters XID parameter, received while a SABM or XID command respectively that does not contain a Layer‑3 Parameters XID parameter is outstanding, shall be ignored.

8.9 List of LLC layer parameters

The LLC layer parameters listed in this subclause are associated with each DLCI, except the LLC version number and IOV‑UI that are associated with a TLLI.

A method of assigning these parameters is defined in subclauses 6.4.1.6 and 8.5.3.

Table 9 provides an overview of the LLC layer parameters and summarises the recommended default values to be used in GSM networks. The term default implies that the value defined should be used in the absence of any negotiation of alternative values.

Some of the parameters, e.g., T200, T201, and N200, may have the same name as parameters used in other GSM specifications. All the parameters listed here are local to the LLC layer protocol, and shall not impact or be impacted by parameters with the same name in other specifications.

8.9.1 LLC version number (Version)

The LLC version number (Version) is an LLC layer parameter. The default version number is given in Table 9.

8.9.2 Input Offset Value (IOV)

The Input Offset Value (IOV) is an LLC layer parameter used for ciphering. IOV is a random 32 bit value, generated by the SGSN. See also annex A.

The value for IOV can be different for I frames and UI frames. IOV‑UI is IOV for UI frames. IOV‑I is IOV for I frames.

The default values of IOV are given in Table 9. The following rules apply to default IOV values:

– After a change of Kc to a different value, negotiation of IOV‑I may be omitted and the default value applied. If ABM is re-established for an LLE, and Kc is not changed to a different value since ABM was last (re‑)established for this LLE, then a random IOV‑I value shall be negotiated.

– After a change of Kc to a different value, negotiation of IOV‑UI may be omitted and the default value applied. If the unconfirmed send state variable V(U) is reset for an LLE, and Kc is not changed to a different value since V(U) was last reset for this LLE, then a random IOV‑UI value shall be negotiated.

8.9.3 Retransmission timers (T200 and T201)

The retransmission timers (T200 and T201) are LLC layer parameters. Upon expiry of timer T200 or T201, retransmission of a frame may be initiated according to the procedures described in clause 8. The default value of timers T200 and T201 for each SAPI is given in Table 9. The value of timer T200 shall be used when setting timer T201.

8.9.4 Maximum number of retransmissions (N200)

The maximum number of retransmissions of a frame (N200) is an LLC layer parameter. The default value of N200 for each SAPI is given in Table 9.

8.9.5 Maximum number of octets in an information field (N201)

The maximum number of octets in an information field (N201) is an LLC layer parameter. See also subclause 5.4. The default value of N201 for each SAPI is given in Table 9. The minimum value of N201 shall be 140 octets, and the maximum value shall be 1 520 octets.

The value of N201 may be different for I frames and U and UI frames. N201‑U is used for U and UI frames, and N201‑I is used for I frames.

8.9.6 Maximum number of octets in the layer‑3 header (N202)

The maximum number of octets in the layer‑3 unitdata PDU header (N202) is an LLC layer parameter. The N202 value shall be 4 for LLC version number 0.

NOTE: The N202 value of 4 octets coincides with the maximum-length SNDCP SN‑UNITDATA PDU header.

8.9.7 Maximum I frame buffer size (m)

The maximum I frame buffer size (m) that may be used to buffer outstanding I frame information fields at any given time is an LLC layer parameter that shall be either 0 or from 9 through 24 320 in units of 16 octets. The default values of m are given in Table 9. If the value of m equals 0, then the LLE shall not keep count of the number of outstanding I frame octets, i.e., the I frame buffer variable B shall not be used. M is the maximum buffer size expressed in octets, so that M = m • 16.

The value of m can be different in each direction of transmission. mD is m in the downlink direction. mU is m in the uplink direction.

8.9.8 Maximum number of outstanding I frames (k)

The maximum number (k) of sequentially-numbered I frames that may be outstanding (i.e., unacknowledged) at any given time is an LLC layer parameter that shall not exceed 255. k is also denoted window size. The default values of k are given in Table 9.

The value of k can be different in each direction of transmission. kD is k in the downlink direction, and kU is k in the uplink direction.

8.9.9 LLC layer parameter default values

Table 9: LLC layer parameter default values

LLC
Parameter

SAPI 1
GMM

SAPI 3
User Data 3

SAPI 5
User Data 5

SAPI 7
SMS

SAPI 9
User Data 7

SAPI 11
User Data 11

Version

0

IOV‑UI

0

IOV‑I

Note 2

227 • SAPI

227 • SAPI

Note 2

227 • SAPI

227 • SAPI

T200 and T201

5 s

5 s

10 s

20 s

20 s

40 s

N200

3

3

3

3

3

3

N201‑U

400

500

500

270

500

500

N201‑I

Note 2

1 503

1 503

Note 2

1 503

1 503

mD

Note 2

1 520

760

Note 2

380

190

mU

Note 2

1 520

760

Note 2

380

190

kD

Note 2

16

8

Note 2

4

2

kU

Note 2

16

8

Note 2

4

2

NOTE 1: Proper LLC operation requires that timer T200 be greater than the maximum time between transmission of command frames and the reception of their corresponding response or acknowledgement frames.

NOTE 2: This parameter applies to ABM procedures. ABM operation is not allowed for GMM and SMS that use only UI frames for information transfer.

NOTE 3: The default values for SAPIs 3, 5, 9, and 11 have been chosen to correspond with the four GPRS quality of service delay classes, see 3GPP TS 02.60. However, there is no fixed relationship between SAPI and delay class. The LLC layer parameters for any SAPI can be negotiated to support any QoS profile, see 3GPP TS 03.60.

NOTE 4: Proper LLC operation requires that the values for N201‑U and N201‑I are not greater than the maximum number of octets in an information field that can be transmitted or retransmitted over the Gb interface, see 3GPP TS 08.18. It is the responsibility of the SGSN to negotiate N201‑U and N201‑I to values compatible with the usage of the Gb interface.

Annex A (normative):
Ciphering