ETSI TC SMG TDoc SMG 938/97 Madrid, Spain Agenda item · PDF fileCR # Rev Title Description SMG3 A SMG3 Pl SMG#24 ... Figure 1 in subclause 4.1 contains an incorrect reference to Frame

ETSI TC SMG TDoc SMG 938/97Madrid, Spain Agenda item 5.1, GPRS15-19 December, 1997

1

Source: Rapporteur GSM 04.64

Topic: GPRS

Title: Change Requests to GSM 04.64

Date: 8 December, 1997

Introduction

GSM 04.64 is the GPRS logical link control layer (LLC) specification.

GSM 04.64 v5.0.0 was approved by SMG#23 in October 1997.

This document contains an overview of all known change requests (CRs) to GSM 04.64, and thestatus of each CR.

Rapporteur's contact details

Hans Petter Naper +47 23 19 40 04 (phone)Motorola +47 23 19 40 01 (fax)P.O. Box 143, Økern +47 92 65 66 44 (mobile)N-0509 Oslo, Norway [email protected]

CRs to GSM 04.64 v5.0.0

CR # Rev Title Description SMG3 A SMG3 Pl SMG#24A001 1 Various corrections

and alignments withother specifications

Various outstanding issues. Fora list of changes, see the CRcover page.

Agreed Agreed

A002 1 NACK / SACKprocedure

Specifies more rigid handling ofthe retransmission procedures.

Agreed Agreed

A003 0 T200 default values Changes the T200 defaultvalues for QoS 3 and QoS 4.

Agreed Agreed

A004 0 Introduction of newprimitive

Adds a mechanism to indicatethe send sequence numberassigned to each I frame tolayer 3.

Agreed Agreed

A005 0 Frame RejectResponse

Adds SACK frame errors to theFRMR cases.

Agreed Agreed

A006 1 Minimum value forN201

Sets the minimum value forN201 to 140 octets.

Agreed Agreed

A007 1 Cipher parameterInput

Modifies the calculation of theciphering Input parameter.

Agreed Agreed

A008 1 Introduction of DataMode parameter inLLC

Allows layer 3 to select LLCand RLC/MAC transmissionmode.

Agreed Agreed

A009 0 Separate N201parameter for I and U-UI frames

Separates N201 in two; one forI frames, and one for U and UIframes.

Agreed Agreed

A010 1 Cell Update Procedure Clarifies which LLC frame totransmit to do a cell update orto respond to paging.

Agreed Agreed

A011 1 ABM SAPIs Clarifies the ABM is not allowedfor SAPIs 1 and 7.

Agreed Agreed

2

A012 1 Update of serviceprimitive names

Aligns the service primitive andservice access point nameswith GSM 04.07.

Agreed Agreed

A013 1 Maximum number ofoctets in aninformation field, N201

Sets the N201 maximum valueto 1520 octets.

Agreed Agreed

A014 0 Removal of the lengthindicator field

Removes the length indicatorfield from all LLC frames.

Agreed Agreed

ETSI STC SMG3 TDoc SMG3 97P____Brentford, England3-5 December, 1997

CHANGE REQUEST No. A001 rev. 1

Technical Specification GSM 04.64 version 5.0.0

Submitted to SMG for approval without presentation ("non-strategic") [ ]

with presentation ("strategic") [ ]

Status at SMG [ ]: Approved [ ] Rejected [ ] Postponed [ ]

Phase 1: [ ] Phase 2: [ ] Phase 2+: [Release 97] Work item: GPRS

Other phase(s) affected: [ ] If yes, linked CR(s):

Proposed change affects: SIM [ ] ME [x] Network [x]

Source: SMG3 WPA Date: 28 November, 1997

Subject: Various corrections and alignments with other specifications

Category: F - Correction [ ]A - Corresponds to a Phase 2 correction [ ]B - Addition of Feature [ ]C - Functional modification of Feature [x]D - Editorial modification [ ]

Reason for change:

This document contains a number of unrelated requested changes to GSM 04.64:

a) Figure 1 in subclause 4.1 contains an incorrect reference to Frame Relay. The term Network Service (NS) shallbe used instead as defined in GSM 08.16.

b) Subclause 6.3.1 should refer to the P/F bit and not only the P bit.

c) Subclause 6.5.1.6 contains an incomplete description of what to do after an XID command has beenunsuccessfully transmitted N200 times. The proposed new text improves the description and aligns the handlingof this unsuccessful case with the handling of similar unsuccessful cases for e.g., SABM.

d) Table 7 assumes that the MS uses only one TLLI. However, MSs that support anonymous service may have morethan one TLLI in operation simultaneously. Table 7 should be updated accordingly.

e) In subclause 7.2.1.2, the note should explain that GMM-TRIGGER-REQ is also used to trigger LLC to transmit aframe as a page response.

f) UI frames may be sent unciphered even if ciphering is enabled, as indicated with the E bit in the UI frame header.It is of interest to GMM to know whether a UI frame was received ciphered or unciphered. Therefore, a Cipherparameter should be added to the LL-UNITDATA-IND service primitive.

g) LLC operation in the SGSN may be suspended due to either timeout of the READY timer, or due to suspendedoperation for a class-B MS. In the first case, the MS shall be paged when there are downlink LLC frames to betransmitted to it. In the latter case, paging shall not take place until the MS resumes operation. In order todifferentiate between the two suspend cases, a new Page parameter should be added to the GMM-SUSPEND-REQ primitive in the SGSN.

h) Upon normal deactivation of PDP contexts, it is not necessary to exchange LLC DISC and UA frames. In orderto be able to indicate whether DISC shall be sent, a Local parameter should be added to the LL-RELEASE-REQprimitive.

Sections affected, and additional explanation of details of change (if needed):

4.1, 6.3.1, 6.5.1.6, 7.1.2, 7.2.1.2, 7.2.1.3, 7.2.1.4, 7.2.1.5, 7.2.2.2, 7.2.2.5, and 8.5.2.1.

Attached revised pages:

2

If other core Specifications are affected, necessary (and attached) Joint CRs:

See GSM 10.60.

Affects(possibly):

MS Test Specifications [ ] BSS Test Specifications [ ] O&M Specifications [ ]

Attached CRs?:

Cross Phase Compatibility:Change affects operation of: Phase 1 MS in Phase 2(+) NW [ ] Phase 2(+) MS in Phase 1 NW [ ]

CR to 09.90 attached:Change affects operation of: Phase 1 SIM in Phase 2(+) ME[ ]

CR to 09.91 attached:Phase 2(+) SIM in Phase 1 ME [ ]CR to 09.91 attached:

Other comments:

4.1 Reference modelA model of layering the protocols in GPRS is illustrated in Figure 1.

Um GbMS BSS SGSN

SNDC SMSGMM

LLC

RLC

MAC

GSM RF

Relay

RLC

MAC

GSM RF

BSSGP

NetworkService

L1

SNDC SMSGMM

LLC

BSSGP

Network Service

L1

Figure 1: Protocol layering in GPRS

The LLC layer operates above the RLC and BSSGP layers in the reference architecture to provide logical links betweena MS and its SGSN.

Above the LLC layer is located the SubNetwork Dependent Convergence (SNDC) layer, that controls the transfer ofuser data network layer PDUs (N-PDUs) between the MS and SGSN. The SNDC functionality is described inGSM 03.60 and specified in GSM 04.65 [11].

The logical link control layer Service Access Points (SAPs) are the points at which the LLC layer provides services tothe layer-3 protocols in Figure 1. In addition to the SNDC protocol, LLC provides service to the GPRS MobilityManagement (GMM) protocol, and to the SMS protocol.

A LLC layer connection is identified by the DLCI consisting of the SAP Identifier (SAPI) and the MS's TemporaryLogical Link Identifier (TLLI).

Each LLC frame consists of the header, trailer and information field. The header and trailer fields contain informationsuch as SAPI, frame number and checksum, that are used to identify the frame and to provide reliable transmission. Theinformation field is variable length. Both transmission and retransmission of each frame are controlled by the LLC layer.

Many of the formats and procedures are similar to the reference protocols, and differences are introduced only whereneeded to reflect the unique aspects of the GPRS architecture and requirements.

3

6.3.1 Information transfer format - I

The I format shall be used to perform an information transfer between layer-3 entities. The functions of N(S), N(R), andP/F are independent; that is, each I frame has an N(S) sequence number, an N(R) sequence number that may or may notacknowledge additional I frames received by the LLE, and a P/F bit that may be set to 0 or 1. The use of N(S), N(R),and P/F is defined in clause 8.

Each I frame also contains a supervisory information field, in effect "piggy-backing" an S frame with each I frame, sothat it may be considered to be an I+S frame.

6.5.1.6 Exchange Identification (XID) command/response

This frame shall be used to negotiate and re-negotiate LLC layer parameters and layer-3 parameters. XID frames can betransmitted in ADM and ABM.

The negotiation procedure is one-step, i.e., one side shall start the process by sending an XID command, offering acertain set of parameters from the applicable parameter repertoire (see Table 1) the sending entity wants to negotiate,proposing values within the allowed range. In return, the other side shall send an XID response, either confirming theseparameter values by returning the requested values, or offering higher or lower ones in their place. See Table 1 for senseof negotiation. Default values as defined in subclause 8.9 shall apply to those parameters that are not commented uponby the responding side. This shall end the negotiation process.

Both entities shall support the negotiated values, however under certain conditions one or more parameters may need tobe re-negotiated (e.g., in the case of a change in SGSN).

XID frames shall always be used with the P/F bit set to 1.

Without any prior XID exchange, default values shall apply.

Negotiated XID parameters shall apply to the LLE identified by the DLCI of the XID frames used, except Version thatapplies to a LLME (i.e., a TLLI), and except Layer 3 Parameters that apply to the layer 3 above the LLE.

In the case of a collision of XID commands, all XID commands shall be ignored. The MS shall restart the parameternegotiation on expiry of timer T200, while the SGSN shall do so on expiry of twice the value of timer T200. Anunsuccessful XID exchange shall be repeated on expiry of timer T200. After N200 times of unsuccessful repetition, thelink may be terminated (e.g., TLLI may be released by the SGSN).After retransmission of the XID command N200times, LLME shall indicate this to GMM by means of the GMM-STATUS-IND primitive, and the LLE shall send a LL-RELEASE-IND to layer 3, and enter ADM state if not already in ADM state.

Table 1 lists the negotiable LLC layer parameters. Figure 2 shows the format of the XID information field.

2

1

Octet8 7 6 5 4 3 2 1

Length

Bit

XL

Length

Parameter Type

High-order octet

Low-order octet

…

n

…

2 or 3

X X

Figure 2: XID parameter field format

A parameter item consists of one or two type/length octets followed by the value of that parameter. The XID Length(XL) bit indicates whether the Length field is 2 bits or 8 bits long. If XL is set to 0, then Length consists of 2 bits andtype/length occupies one octet. If XL is set to 1 then Length consists of 8 bits and type/length occupies two octets. Thelength indicator gives the number of octets that the value actually occupies. The parameter items can be arranged inarbitrary order. The parameter items shall begin in the first octet of the XID information field and follow oncontiguously.

4

Table 1: LLC layer parameter negotiation

Parameter Name Type Length Format(87654321)

Range Units Sense ofNegotiation

Version (LLC versionnumber)

0 1 0000bbbb 0-15 - down

T200 (retransmissiontime-out)

1 2 0000bbbbbbbbbbbb

1 - 4 095 0.1 seconds up

N200 (maximumretransmissions)

2 1 0000bbbb 1 - 15 - down

N201 (maximuminformation size)

3 2 00000bbbbbbbbbbb

500 -1 500

octets down

kD (window size in thedownlink direction)

4 1 00bbbbbb 1 - 32 frames down

kU (window size in theuplink direction)


Layer-3 Parameters 6 Variable See GSM 04.65- All other Types and Ranges are reserved for future versions of this specification.- The length for Layer-3 Parameters shall be set equal to the number of octets received from layer 3.

FFS: The exact maximum value for N201 is 1 600 - BSSGP protocol overhead - LLC protocol overhead, andwill be calculated later when GSM 08.16 and GSM 08.18 are being completed. This FFS item affects allreferences to the maximum information size in this document.

Version shall not be negotiated while in ABM.

T200 and N200 can be negotiated in ADM and ABM. The new value of T200 shall only apply to timers set after thenegotiation has been completed.

N201, kD, and kU can be negotiated to any value in Range in ADM. In ABM, N201, kD, and kU can only be negotiatedto the same or higher value as previously used.

5

7.1.2 Generic names

The generic name specifies the activity that the identified layer should perform. Table 2 lists the primitives defined inthis specification.

Table 2: LLC layer service primitives

Generic Name Location Type ParametersMS SGSN REQ IND RES CNF

GMM ↔ LLMGMM-ASSIGN X X X TLLI Old, TLLI New, Kc,

RAND, Ciphering AlgorithmGMM-TRIGGER X X TLLIGMM-TRIGGER X X TLLIGMM-TRIGGER X X TLLI, Cell IdGMM-SUSPEND X X X TLLIGMM-SUSPEND X X TLLI, PageGMM-RESUME X X X TLLIGMM-PAGE X X TLLIGMM-WINDOW X X TLLI, V(R)sGMM-WINDOW X X TLLIGMM-WINDOW X X X TLLI, V(R)sGMM-STATUS X X X TLLI, CauseGMM ↔ LL, SNDCP ↔ LL, and SMS ↔ LLLL-ESTABLISH X X X TLLI, XID ReqLL-ESTABLISH X X X TLLI, XID Req, N201LL-ESTABLISH X X X TLLI, XID NegLL-ESTABLISH X X X TLLI, XID Neg, N201LL-RELEASE X X X TLLI, LocalLL-RELEASE X X X X X TLLILL-XID X X X TLLI, XID ReqLL-XID X X X TLLI, XID Req, N201LL-XID X X X TLLI, XID NegLL-XID X X X TLLI, XID Neg, N201LL-DATA X X X TLLI, L3-PDU, ReferenceLL-DATA X X X TLLI, L3-PDULL-DATA X X X TLLI, ReferenceLL-UNITDATA X X X TLLI, L3-PDU, Protect, CipherLL-UNITDATA X X X TLLI, L3-PDU, CipherLL ↔ RLC/MACRLC/MAC-DATA X X TLLI, LL-PDU, SAPIRLC/MAC-DATA X X TLLI, LL-PDURLC/MAC-UNITDATA X X TLLI, LL-PDU, SAPIRLC/MAC-UNITDATA X X TLLI, LL-PDURLC/MAC-STATUS X X TLLI, CauseLL ↔ BSSGPBSSGP-UNITDATA X X TLLI, LL-PDU, RLC Confirm,

SAPIBSSGP-UNITDATA X X TLLI, LL-PDU, Cell IdBSSGP-STATUS X X TLLI, CauseThe TLLI parameter shall only be used in service primitives in the SGSN.

7.2.1.2 GMM-TRIGGER

GMM-TRIGGER-REQ shall be used in the MS to order LLC to transmit any single frame. The type of frame to betransmitted and the SAPI is an implementation option, but for optimum performance, a frame that is needed at the peerside should be transmitted, e.g., an I frame if an L3-PDU is available, or a SACK or a NACK frame if I frames aremissing.

NOTE: GMM-TRIGGER-REQ is normally used for cell updates or for page responses.

6

The LLME in the MS shall send GMM-TRIGGER-IND to GMM every time a LL-PDU is transmitted, i.e., every time aRLC/MAC-DATA-REQ or RLC/MAC-UNITDATA-REQ is delivered to the lower layer. The LLME in the SGSN shallsend GMM-TRIGGER-IND to GMM every time a valid LL-PDU is received, i.e., every time a BSSGP-UNITDATA-IND containing a valid LL-PDU is received (see subclause 5.9).

NOTE: GMM-TRIGGER-IND moves the GMM Context to READY state and sets the READY timer in GMM.

7.2.1.3 GMM-SUSPEND

GMM-SUSPEND-REQ shall be used to order LLC to suspend operation for a MS until GMM-RESUME-REQ isreceived. While suspended, LLC shall:

- save L3-PDUs if any are buffered;

- save unacknowledged I frames;

- save the state of the state variables (e.g., the transmit and receive counters);

- reset timer T200; and

- stop frame transmission.

Frame reception shall still be possible. For SAPI = 1, ADM procedures including UI frame transmission shall still bepossible. The Page parameter controls whether GMM-PAGE-IND shall be sent to GMM or not (see subclause 7.2.1.5).

7.2.1.4 GMM-RESUME

GMM-RESUME-REQ shall be used to order LLC to resume a suspended operation for a MS without loss of theL3-PDUs or I frames that were saved when GMM-SUSPEND-REQ was received. If timer T200 was reset uponreception of GMM-SUSPEND-REQ then timer T200 shall be set.

7.2.1.5 GMM-PAGE

If the Page parameter received in the GMM-SUSPEND-REQ primitive is set to true, GMM-PAGE-IND shall be sent toGMM in the SGSN whenever LLC has a LL-PDU ready for transmission and LLC operation is suspended. The LL-PDUshall not be transmitted until GMM-RESUME-REQ has been received from GMM.

If the Page parameter is set to false, GMM-PAGE-IND shall not be sent, and the LL-PDU shall not be transmitted untilGMM-RESUME-REQ has been received from GMM.

NOTE: GMM-PAGE-IND causes GMM to initiate paging of the MS.

7.2.2.2 LL-RELEASE

The LL-RELEASE primitives shall be used to request, indicate, and confirm termination of a previously establishedABM operation. The Local parameter indicates whether the termination shall be local, i.e., a DISC frame shall not betransmitted, or not local, i.e., a DISC frame shall be transmitted.

7.2.2.5 LL-UNITDATA

LL-UNITDATA-REQ shall be used to request the unconfirmed transmission of a L3-PDU to the peer. The Protectparameter indicates whether the UI frame carrying the L3-PDU shall be transmitted in protected or unprotected mode.The Cipher parameter indicates whether the UI frame shall be ciphered or not.

LL-UNITDATA-IND shall be used to deliver a L3-PDU received in an UI frame to layer 3. The Cipher parameterindicates whether the received UI frame was ciphered or not.

7

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 a MS.

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

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

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

In the case of persistent lower layer deactivation the LLE shall discard all I queues and deliver to layer 3 a LL-RELEASE-CNF primitive if a LL-RELEASE-REQ primitive is outstanding, or otherwise a LL-RELEASE-INDprimitive.

8.5.2.2 Release procedure

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

A LLE receiving a DISC command while in ABM or Timer Recovery state shall transmit a UA response with the F bitset to the same binary value as the P bit in the received DISC command. A LL-RELEASE-IND primitive shall be passedto 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.

ReceiverOriginator

LL-RELEASE-CNF

LL-RELEASE-REQ

Layer 3 LLC Layer 3LLC

UA or DM

LL-RELEASE-IND

DISC

Figure 3: 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 DISCcommand shall:

- retransmit the DISC command as defined in subclause 8.5.2.2;

- set timer T200; and

- increment the retransmission counter.

8

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











Subject: NACK / SACK procedure


Reason for change:

In the current version of the LLC specification, the supervisory frames NACK and SACK are described. The NACK andSACK functionality is not completely defined, and is left open for implementation. The LLC specification should becomplete and guarantee compatibility between two communicating LLC entities. The LLC specification should alsominimise the risk for unnecessary transmissions and retransmissions on the shared radio interface resource. There aretwo major problems that should be solved in order to make the NACK and SACK frames efficient:

The first problem occurs when a NACK or SACK frame is lost, or when the requested I frame(s) is(are) lost. It shouldbe described how this situation is discovered and resolved.

The second problem is that the description of SACK may lead to unnecessary retransmissions since in the SACK frameall missing I frames are indicated, including frames that were just requested in a previous NACK or SACK frame andthat may already have been retransmitted. GSM 04.64 should more clearly define the actions to take place in thetransmitter to avoid unnecessary retransmissions over the air interface.


All affected sections are included in the following pages.



See GSM 10.60.

Affects(possibly):


Attached CRs?:




Other comments:

2

3.1 DefinitionsFor the purposes of this specification the following definitions apply. Additional applicable definitions can be found inGSM 02.60 [3].

frame rejection condition: a condition that results from the receipt of an undefined or incorrect frame.

inquiry process: a process performed in the peer receiver busy condition in which the LLE checks that the peer LLE isstill in the own receiver busy condition.

logical link connection: the logical connection between two LLE peers. A logical link connection is identified with aData Link Connection Identifier (DLCI). A logical link connection is always in one of three states: TLLI Unassigned,TLLI Assigned / ADM, or ABM.

logical link control layer: the protocol layer between a MS and a SGSN consisting of one or more logical linkmanagement entities, one or more logical link entities, and a multiplex procedure.

logical link entity: the LLC layer protocol state machine controlling one logical link connection.

N(R) sequence error exception condition: an exception condition that occurs in the transmitter upon reception of avalid supervisory frame or I frame that contains an invalid N(R) value.

N(S) sequence error exception condition: an exception condition that occurs in the receiver upon reception of a valid Iframe that contains an N(S) value that is not equal to the V(R) at the receiver.

own receiver busy condition: a condition that results from the inability to accept additional I frames from the peerlogical link entity.

peer receiver busy condition: a condition that results from the reception in of a RNR frame from the peer logical linkentity.

SACK or NACK exception condition: an exception condition that occurs in the receiver when an N(S) sequence errorexception condition has occurred, and a SACK or NACK frame has been transmitted, but the requested I frames havenot yet been received.

timer recovery condition: a condition that results from the timeout of timer T200 in the transmitter when a previouslytransmitted I frame with the P bit set to 1 has not been acknowledged.

timer T201 recovery condition: a condition that results from the timeout of timer T201 in the receiver when none ofthe I frames that were previously requested for retransmission have been received.







3


In the case of a collision of XID commands, all XID commands shall be ignored. The MS shall restart the parameternegotiation on expiry of timer T200, while the SGSN shall do so on expiry of twice the value of timer T200. Anunsuccessful XID exchange shall be repeated on expiry of timer T200. After N200 times of unsuccessful repetition, thelink may be terminated (e.g., TLLI may be released by the SGSN).


2

1

Octet8 7 6 5 4 3 2 1

Length

Bit

XL

Length

Parameter Type

High-order octet

Low-order octet

…

n

…

2 or 3

X X







0 1 0000bbbb 0-15 - down



1 - 4 095

0.1 seconds up

T201 (NACK and SACKprotection timer)


2 -4 095

0.1 seconds up

N200 (maximum numberof retransmissions)

32 1 0000bbbb 1 - 15 - down



500 - 1 500

octets down








T200, T201, and N200 can be negotiated in ADM and ABM. The new value of T200 and T201 shall only apply totimers set after the negotiation has been completed.

N201, kD, and kU can be negotiated to any value in Range in ADM. In ABM, N201, kD, and KU can only benegotiated to the same or higher value as previously used.

4

6.5.3.2 Negative Acknowledgement (NACK) command / response

The NACK supervisory frame shall be used by a LLE to request retransmission ofindicate that in numbered informationtransfer a single I frame has not been correctly received. Frames up to and including N(R) - 1 have been receivedcorrectly, and frame N(R) is requested to be retransmitted. The procedures associated with the NACK information fieldare defined in subclause 8.6.4. The N(S) sequence error exception condition is cleared (reset) upon the receipt of a validI frame with an N(S) equal to the N(R) of the NACK frame.

The transmission of a NACK frame shall also indicate the clearance of any busy condition within the sending LLE thatwas reported by the earlier transmission of a RNR frame by the same LLE.

6.5.3.3 Selective Acknowledgement (SACK) command / response

The SACK supervisory frame shall be used by a LLE to request retransmission of a single or multiple I frames. Framesup to and including N(R) - 1 have been received correctly. The format of the SACK information field is shown inError! Reference source not found.. The procedures associated with the SACK information field are defined insubclause 8.6.4. The N(S) sequence error exception condition is cleared (reset) upon the receipt of all the requested Iframes.

The transmission of a SACK frame shall also indicate the clearance of any busy condition within the sending LLE thatwas reported by the earlier transmission of a RNR frame by the same LLE.

8.2 Procedure for the use of the P/F bitTimer T200 shall be set when a command frame with the P bit set to 1 is transmitted. A LLE receiving a commandframe with the P bit set to 1 shall set the F bit to 1 in the next response frame it transmits.

8.6.1 Transmitting I frames

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

Timer T200 shall be set. If timer T200 expires, the procedures defined in subclause 8.6.7 shall be followed.

If V(S) = is equal to V(A) + plus k (where k is the maximum number of outstanding I frames - see subclause 8.9.65),the LLE shall not transmit any new I frames, but may retransmit I frames as a result of the error recovery procedures asdescribed in subclauses 8.6.4 and 8.6.7.

An I frame shall be transmitted with the P bit set to 1, and timer T200 shall be set, if:

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

- there are no pending LL-DATA-REQ primitives nor additional I frames waiting to be transmitted; or

- the I frame is the last I frame pending retransmission.

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

Any LL-DATA-REQ primitives received whilst in the timer recovery condition shall be queued.

5

ReceiverOriginator

LL-DATA-CNF

LL-DATA-REQ


S or I+S

LL-DATA-IND

I+S

Figure 2: Transmitting and receiving I frames

8.6.2 Receiving I frames

Independent of a timer recovery condition, when a LLE is not in an own receiver busy condition and receives a valid Iframe 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 act as indicated in subclauses 8.6.2.1 and 8.6.2.2;

- if the P bit of the received I frame was set to 1, then the LLE shall respond to its peer with a RR, RNR, SACK, orNACK response with the F bit set to 1 (see subclause 8.6.5.1); and

- if the P bit of the received I frame was set to 0, and if, on receipt of this I frame, the LLE is now in an ownreceiver busy condition, then the LLE shall transmit a RNR response with the F bit set to 0. When the LLE is inan own receiver busy condition, it shall process any received I frame according to subclause 8.6.6.

When a LLE receives a valid I frame whose N(S) is less than the current V(R), the LLE shall discard the frame as aduplicate.

When a LLE receives a valid I frame where V(R) < N(S) < V(R) + k, the LLE shall request retransmission of missing Iframes as described in subclause 8.8.1. The LLE shall store the I frame until all frames from V(R) to N(S) - 1 inclusiveare correctly received. 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.

If the received I frame was previously requested for retransmission with a NACK or SACK frame, then timer T201 shallbe reset.

8.6.2.1 P bit set to 1

If the P bit of the received I frame was set to 1, the LLE shall respond to its peer in one of the following ways:

- if the LLE receiving the I frame is still not in an own receiver busy condition, it shall send a RR, SACK, orNACK response with the F bit set to 1;

- if the LLE receiving the I frame enters the own receiver busy condition upon receipt of the I frame, it shall send aRNR response with the F bit set to 1.

8.6.2.2 P bit set to 0

If the P bit of the received I frame was set to 0 and:

a) if the LLE is still not in an own receiver busy condition:

- if no frame is available for transmission, or if an I frame is available for transmission but a peer receiver busycondition exists, the LLE shall transmit a RR, SACK, or NACK response with the F bit set to 0, eitherimmediately, or, to allow more than one I frame to be acknowledged by the same RR, SACK, or NACK, aftera delay not greater than timer T200 minus the LLC round-trip delay; or

6

- if an I frame is available for transmission and no peer receiver busy condition exists, the LLE shall transmitthe I frame with the value of N(R) set to the current value of V(R) as defined in subclause 8.6.1.

b) if, on receipt of this I frame, the LLE is now in an own receiver busy condition, it shall transmit a RNR responsewith the F bit set to 0.

When the LLE is in an own receiver busy condition, it shall process any received I frame according to subclause 8.6.6.

8.6.3 Sending and receiving acknowledgements

8.6.3.1 Sending acknowledgements

Whenever a LLE transmits an I frame or a supervisory frame, N(R) shall be set equal to V(R). Timer T201 shall be setwhen a NACK or SACK frame is transmitted.

8.6.3.2 Receiving acknowledgements

On receipt of a valid I frame or supervisory frame (RR, RNR, SACK, or NACK), even in the own receiver busy or timerrecovery conditions, the LLE shall treat the N(R) contained in this frame as an acknowledgement for all the I frames ithas transmitted with an N(S) up to and including the received N(R) - 1. V(A) shall be set to N(R).

The LLE shall reset timer T200 on receipt of a valid I frame or supervisory frame with the F bit set to 1N(R) higher thanV(A) (actually acknowledging some I frames), or a NACK or SACK frame with an N(R) equal to V(A).

If a supervisory frame with the P bit set to 1 has been transmitted and not acknowledged, timer T200 shall not be reset.

Upon receipt of a valid I frame, tTimer T200 shall not be reset if the LLE is in the peer receiver busy condition.

If timer T200 has been reset by the receipt of an I, RR, or RNR frame, and if there are outstanding I frames stillunacknowledged, the LLE shall set timer T200. If timer T200 then expires, the LLE shall follow the recovery procedureas defined in subclause 8.6.7 with respect to the unacknowledged I frames.

If timer T200 has been reset by the receipt of a NACK or SACK frame, the LLE shall follow the retransmissionprocedures in subclause 8.6.4.

8.6.4 Receiving NACK and SACK frames

8.6.4.1 NACK control field

Retransmission of a single I frame shall be requested by sending a NACK frame. On receipt of a valid NACK frame, theLLE shall place in the retransmission queue the I frame previously transmitted with an N(S) value equal to the N(R) inthe control field of the received NACK frame. The I frame shall not be placed in the retransmission queue if, upon orafter the previous retransmission of the I frame,:

- the LLE has not yet transmitted an I+S or S frame with the P bit set to 1; and

- the LLE has not yet received an I+S or S frame with the F bit set to 1 as a response to the I or S frame transmittedwith the P bit set to 1.

8.6.4.2 SACK control field

Retransmission of one or more I frames shall be requested by sending a SACK frame. On receipt of a valid SACKframe, the LLE shall retransmit the I frames identified by the control field of the SACK frame, see Error! Referencesource not found.. The SACK control field contains a bitmap R(0) to R(31) that shall be interpreted as follows:

- For each value n, where 0 ≤≥ n <> k, where k is the window size:

- if R(n) = 1 then the I frame previously transmitted with value N(S) = N(R) + n shall be considered to beacknowledged;

7

- if R(n) = 0 then the I frame previously transmitted with value N(S) = N(R) + n shall be placed in theretransmission queue. R(0) shall always have a value of 0, indicating that the frame with sequence numberN(R) has not been received. The I frame shall not be placed in the retransmission queue if, upon or after theprevious retransmission of the I frame,:

- the LLE has not yet transmitted an I+S or S frame with the P bit set to 1; and

- the LLE has not yet received an I+S or S frame with the F bit set to 1 as a response to the I or S frametransmitted with the P bit set to 1.

8.6.4.3 NACK and SACK procedures

On receipt of a valid NACK or SACK frame, the LLE shall act as follows:

a) if it is not in the timer recovery condition:

- clear an existing peer receiver busy condition;

- set its V(A) to the value of the N(R) contained in the NACK or SACK frame control field;

- reset timer T200 if the NACK or SACK frame is a response with the F bit set to 1;

- retransmit the requested I frames as soon as possible, taking into account the items 1) to 4) below and theparagraph following items 1) to 4); and

- if it was a NACK or SACK command frame with the P bit set to 1, then the first I frame shall be retransmittedas an appropriate supervisory response with the F bit set to 1 (see subclause 8.6.5.1); and

- the last retransmitted I frame shall have the P bit set to 1 if the P bit is not already in use. If the P bit is in use,then the P bit shall be set in the next possible frame. If no I frames are pending retransmission when it ispossible to set the P bit to 1 again (i.e., after a response frame with the F bit set to 1 has been received), thenan appropriate supervisory frame with the P bit set to 1 shall be transmitted (see subclause 8.6.5.1).

b) if it is in the timer recovery condition and it was a NACK or SACK response frame with the F bit set to 1:


- set its V(A) to the value N(R) contained in the NACK or SACK frame control field;

- reset timer T200;

- enter the ABM state; and

- retransmit the requested I frames as soon as possible, taking into account the items 1) to 4) below and theparagraph following items 1) to 4).

c) if it is in the timer recovery condition and it was a NACK or SACK frame other than a NACK or SACK responseframe with the F bit set to 1:


- set its V(A) to the value of the N(R) contained in the NACK or SACK frame control field; and

- if it was a NACK or SACK command frame with the P bit set to 1, transmit an appropriate supervisoryresponse frame with the F bit set to 1 (see subclause 8.6.5.1).

Transmission of I frames shall take account of the following:

1) if the LLE is transmitting a supervisory frame when it receives the NACK or SACK frame, it shall complete thattransmission before commencing transmission of the requested I frames;

2) if the LLE is transmitting a SABM command, a DISC command, a UA response, or a DM response when itreceives the NACK or SACK frame, it shall ignore the request for retransmission;

8

3) if the LLE is not transmitting a frame when the NACK or SACK is received, it shall immediately commencetransmission of each of the requested I frames, unless the I frame was recently retransmitted as the result of aprevious NACK or SACK frame, in which case it is an implementation option as to if and when to retransmit theI frame again; and

4) timer T200 shall be set every time an I frame is (re-)transmitted with the P bit set to 1.

Only the I frames identified in the received NACK or SACK frame shall be retransmitted. Other I frames not yettransmitted may be transmitted following the retransmitted I frames.

8.6.8 Timer T201 expiry

The LLE shall maintain an internal T201 retransmission count variable.

If timer T201 expires, the LLE shall:

- if it is not yet in the timer T201 recovery condition, enter the timer T201 recovery condition and reset the T201retransmission count variable; or

- if it is already in the timer T201 recovery condition, add one to its T201 retransmission count variable.

The LLE shall then:

a) if the value of the T201 retransmission count variable is less than N200:


- transmit a NACK or SACK frame to request retransmission of all missing I frames; or

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

The timer T201 recovery condition is cleared when the LLE receives an I frame that was requested for retransmissionwith a NACK or SACK frame.

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 a LL-ESTABLISH-REQ primitive from layer 3 (see subclause 8.5.1.1);

- the occurrence of N200 retransmission failures while in the timer recovery condition (see subclause 8.6.7);

- the occurrence of N200 retransmission failures while in the timer T201 recovery condition (see subclause 8.6.8);

- the occurrence of a frame rejection condition as identified in subclause 8.8.5;

- the receipt, while in the multiple-frame mode of operation, of a FRMR response frame (see subclause 8.8.6);

- the receipt, while in the multiple-frame mode of operation, of an unsolicited DM response with the F bit set to 0(see subclause 8.8.7);

- the receipt, while in the timer recovery condition, of a DM response with the F bit set to 1.

8.8.1 N(S) sequence error

An N(S) sequence error exception condition occurs in the receiver upon reception of a valid I frame that contains anN(S) value that is not equal to the V(R) at the receiver. The information field of all I frames withV(R) < N(S) < V(R) + k shall be stored by the receiving LLE until all frames between the current V(R) and the value ofN(S) are received correctly. All other I frames whose N(S) does not equal V(R) shall be discarded.

9

The receiver shall transmit a NACK or SACK frame indicating all missing I frames that have not been receivedcorrectly and enter the SACK or NACK exception condition. In the SACK or NACK exception condition, NACK orSACK frames shall not be transmitted unless it is detected that additional I frames are missing, or unless a S or an I+Scommand frame with the P bit set to 1 is received.

A LLE that receives one or more I frames having sequence errors but otherwise error-free, or subsequent supervisoryframes (RR, RNR, NACK, and SACK), shall use the control field information contained in the N(R) field and the P or Fbit to perform LLC control functions; for example, to receive acknowledgement of previously transmitted I frames andto cause the LLE to respond if the P bit is set to 1. Therefore, the retransmitted I frame may contain an N(R) field valueand P bit that are updated from, and therefore different from, the ones contained in the originally transmitted I frame.

The NACK and SACK frames are used by a receiving LLE to initiate an exception condition recovery (retransmission)following the detection of an N(S) sequence error.

A SACK or NACK exception condition is cleared when all of the requested I frames are received, or when a SABM orDISC command is received.

8.9.3 NACK and SACK protection timer (T201)

The NACK and SACK protection timer (T201) is a LLC layer parameter. Upon expiry of timer T201, transmission of aNACK or SACK frame may be initiated according to the procedures described in subclause 8.6.8. The default value oftimer T201 for each SAPI is given in Table 2. The value of timer T201 shall be greater than the value of timer T200.

8.9.43 Maximum number of retransmissions (N200)

The maximum number of retransmissions of a frame (N200) is a LLC layer parameter. The default value of N200 foreach SAPI is given in Table 2.

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

The maximum number of octets in an information field (N201) is a LLC layer parameter. See also subclause 5.5. Thedefault value of N201 for each SAPI is given in Table 2. The minimum value of N201 shall be 200 octets, and themaximum value shall be 1 600 octets.

8.9.65 Maximum number of outstanding I frames (k)

The maximum number (k) of sequentially-numbered I frames that may be outstanding (i.e., unacknowledged) at anygiven time is a LLC layer parameter that shall not exceed 32. k is also denoted window size. The default values of k aregiven in Table 2.

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

Table 2: LLC layer parameter default values

SAPI Layer 3 Version T200 T201 N200 N201 kD kU1 GMM 5 s Note 2 3 200 Note 2 Note 23 QoS1 5 s 6 s 3 1 600 16 165 QoS2 0 10 s 11 s 3 1 600 8 87 SMS 20 s Note 2 3 1 600 Note 2 Note 29 QoS3 60 s 21 s 3 1 600 4 4

11 QoS4 120 s 41 s 3 1 600 2 2NOTE 1: The proper operation of the procedure requires that timer T200 be greater than the maximum time between

transmission of command frames and the reception of their corresponding response or acknowledgementframes.

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

10

Editor's. NOTE: The T201 default values for SAPIs 9 and 11 shall be set to one second longer than thecorresponding T200 default values. The values in the table assume that the separate CR A003 on T200values is approved. If the separate CR is not approved, then the T201 default values shall be 61 and 121seconds, respectively.


CHANGE REQUEST No. A003









Subject: T200 default values


Reason for change:

In 04.64 version 5.0.0 is a timer called T200 used. A simplified explanation of T200 is that it is used to determine whenretransmission of a frame may be started. The default values for T200 are defined in Table 9. The values used forGMM, QoS1, QoS2 and SMS are all in the range 5-20s, while QoS3 has 60s and QoS4 has 120 s.

The application protocols used on top of the GPRS protocols will in many cases retransmit data after less than 60s onthe application level. If the application will retransmit data faster than LLC will we get duplicated frames on the radio,which is inefficient.

It is therefore proposed that the T200 default values are changed to 20s for QoS3 and 40s for QoS4.


Table 9 in subsection 8.9.5



See GSM 10.60.

Affects(possibly):


Attached CRs?:




Other comments:

2





SAPI Layer 3 Version T200 N200 N201 kD kU1 GMM 5 s 3 200 Note 2 Note 23 QoS1 5 s 3 1 600 16 165 QoS2 0 10 s 3 1 600 8 87 SMS 20 s 3 1 600 Note 2 Note 29 QoS3 2060 s 3 1 600 4 4

11 QoS4 40120 s 3 1 600 2 2

NOTE 1: The proper operation of the procedure requires that timer T200 be greater than the maximum timebetween transmission of command frames and the reception of their corresponding response oracknowledgement frames.

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









Proposed change affects: SIM [ ] ME [ ] Network [x]

Source: SMG3 Date: 8 December, 1997

Subject: Introduction of new primitive


Reason for change:

In order to handle Inter SGSN RA Update it has been described in 03.60 that the N-PDUs that has already been sent tothe MS but are not acknowledged, are forwarded from the old SGSN to the new SGSN containing the last used LLCsend sequence number for that N-PDU. But there is no way to connect N-PDUs with these sequence numbers. LLC isonly aware of the sequence numbers and in the case of Inter SGSN RA Update the LLC layer only gives the value ofV(R) to the upper layer. And SNDCP does not know anything about the sequence numbers at the LLC layer. SNDCP isonly aware of the N-PDU numbers. So in order to connect N-PDUs and sequence numbers it is here proposed that a newprimitive LL-DATASENT.indication is introduced in the SGSN. The primitive is sent from LLC to SNDCP every timean I-frame is sent. This primitive contains information about the N(S) sequence number that the I-frame headercontained, and the reference parameter that SNDCP sent to LLC in the LL-DATA.req primitive. This way SNDCP willbe able to connect each send sequence number with a N-PDU and the Inter SGSN RA Update is possible to perform asdescribed in 03.60.


• Subclause 7.1, table 7. The new primitive must be introduced in the table.

• Subclause 7.2.2. A new subclause describing the new primitive is added.

• Subclause 8.6.1. Addition of the primitive in the text and in fig. 21.



See GSM 10.60.

Affects(possibly):


Attached CRs?:




2

Other comments:

7.1 Definition of service primitives and parametersCommunications between layers and between entities within the logical link control layer are accomplished by means ofservice primitives. Service primitives represent, in an abstract way, the logical exchange of information and controlbetween the logical link control layer and adjacent layers. They do not specify or constrain implementations.

Service primitives consist of commands and their respective responses associated with the services requested of anotherlayer. The general syntax of a primitive is:

XXX - Generic name - Type (Parameters)

where XXX designates the layer providing or using the service. For this specification XXX is:

- "GMM" for the GPRS mobility management function;

- "LL" for the logical link entities;

- "RLC/MAC" for the radio link control and media access control layers; and

- "BSSGP" for the BSSGP layer.

7.1.1 Generic names

The generic name specifies the activity that the identified layer should perform. Table 1 lists the primitives defined inthis specification.

7.1.2 Primitives types

The primitives types defined in this specification are:

NOTE: For the action sequence of these primitive types, see GSM 04.01 [7].

7.1.2.1 Request

The Request primitive type is used when a higher layer is requesting a service from the next lower layer.

7.1.2.2 Indication

The Indication primitive type is used by a layer providing a service to notify the next higher layer of activities related tothe Request primitive type of the peer.

7.1.2.3 Response

The Response primitive type is used by a layer to acknowledge receipt, from the next lower layer, of the Indicationprimitive type.

7.1.2.4 Confirm

The Confirm primitive type is used by the layer providing the requested service to confirm that the activity has beencompleted (successfully or unsuccessfully).

3




RAND, Ciphering AlgorithmGMM-TRIGGER X XGMM-TRIGGER X XGMM-TRIGGER X X TLLI, Cell IdGMM-SUSPEND X X X TLLIGMM-RESUME X X X TLLIGMM-PAGE X X TLLIGMM-WINDOW X X TLLI, V(R)sGMM-WINDOW X X TLLIGMM-WINDOW X X X TLLI, V(R)sGMM-STATUS X X X TLLI, CauseGMM ↔ LL, SNDCP ↔ LL, and SMS ↔ LLLL-ESTABLISH X X X TLLI, XID ReqLL-ESTABLISH X X X TLLI, XID Req, N201LL-ESTABLISH X X X TLLI, XID NegLL-ESTABLISH X X X TLLI, XID Neg, N201LL-RELEASE X X X X X TLLILL-XID X X X TLLI, XID ReqLL-XID X X X TLLI, XID Req, N201LL-XID X X X TLLI, XID NegLL-XID X X X TLLI, XID Neg, N201LL-DATA X X X TLLI, L3-PDU, ReferenceLL-DATA X X X TLLI, L3-PDULL-DATA X X X TLLI, ReferenceLL-DATASENT X X TLLI, Reference, V(S)LL-UNITDATA X X X TLLI, L3-PDU, Protect, CipherLL-UNITDATA X X X TLLI, L3-PDULL ↔ RLC/MACRLC/MAC-DATA X X LL-PDU, SAPIRLC/MAC-DATA X X LL-PDURLC/MAC-UNITDATA X X LL-PDU, SAPIRLC/MAC-UNITDATA X X LL-PDURLC/MAC-STATUS X X CauseLL ↔ BSSGPBSSGP-UNITDATA X X TLLI, LL-PDU, RLC Confirm,


7.2.2 Layer 3 - LL primitives

7.2.2.1 LL-ESTABLISH

The LL-ESTABLISH primitives shall be used to request, indicate, respond to, and confirm establishment of ABMoperation. XID Req and XID Neg are used to negotiate layer-3 XID parameters between the layer-3 peers, seeGSM 04.65.

7.2.2.2 LL-RELEASE

The LL-RELEASE primitives shall be used to request, indicate, and confirm termination of a previously establishedABM operation.

4

7.2.2.3 LL-XID

The LL-XID primitives shall be used to request, indicate, respond to, and confirm negotiation of layer-3 XIDparameters.

7.2.2.4 LL-DATA

The LL-DATA primitives shall only be used for LLEs in ABM. The following operations are defined:

- LL-DATA-REQ shall be used to request the confirmed transmission of a L3-PDU to the peer;

- LL-DATA-IND shall be used to deliver a correctly received L3-PDU to layer 3; and

- LL-DATA-CNF shall be used to confirm the successful reception of a L3-PDU in the peer LLE. The Referenceparameter shall be set to the same value as the Reference parameter received in the corresponding LL-DATA-REQ.

7.2.2.5 LL-DATASENT

LL-DATASENT-IND shall be used to indicate to layer 3 the V(S) assigned to an I frame. The Reference parameter shallbe set to the same value as the Reference parameter received in the corresponding LL-DATA-REQ primitive.

7.2.2.65 LL-UNITDATA

LL-UNITDATA-REQ shall be used to request the unconfirmed transmission of a L3-PDU to the peer. The Protectparameter indicates whether the UI frame carrying the L3-PDU shall be transmitted in protected or unprotected mode.The Cipher parameter indicates whether the UI frame shall be ciphered or not.

LL-UNITDATA-IND shall be used to deliver a L3-PDU received in an UI frame to layer 3.

8.6.1 Transmitting I frames

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

Timer T200 shall be set. If timer T200 expires, the procedures defined in subclause 8.6.7 shall be followed.

If V(S) is equal to V(A) plus k (where k is the maximum number of outstanding I frames - see subclause 8.9.5), the LLEshall not transmit any new I frames, but may retransmit I frames as a result of the error recovery procedures as describedin subclauses 8.6.4 and 8.6.7.

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

NOTE: Any LL-DATA-REQ primitives received whilst in the timer recovery condition shall be queued.

5

ReceiverOriginator

LL-DATA-CNF

LL-DATA-REQ


S or I+S

LL-DATA-IND

I+S

ReceiverOriginator

LL-DATA-CNF

LL-DATA-REQ


S or I+S

LL-DATA-IND

I+S LL-DATASENT-IND

NOTE: LL-DATASENT-IND is returned to layer 3 if Originator is a SGSN.

Figure 1: Transmitting and receiving I frames










Source: SMG3 WPA Date: 28 November 1997

Subject: Frame Reject Response


Reason for change:

Frame Reject Response should be adjusted to handle error cases for the SACK frame also.


• Subclause 6.5.1.5. Figure 11 should include the possibility that the rejected frame is a SACK. The error cases for SACKshould also be in the list of error cases.

• Subclause 8.8.5. The error case for SACK is added.



See GSM 10.60.

Affects(possibly):


Attached CRs?:




Other comments:

Page 2

6.5.1.5 Frame Reject (FRMR) Response

The FRMR unnumbered response may be received by a LLE as a report of a frame rejection condition not recoverable byretransmission of the identical frame:

1)- receipt of a command or response control field that is undefined or not implemented (see subclause 6.5, secondparagraph);

2)- receipt of a supervisory or unnumbered frame with incorrect length;

3)- receipt of an invalid N(R); or

4)- receipt of an I frame with an information field that exceeds the maximum established length; or

5) receipt of a SACK frame with a control field that requests retransmission of an I frame that was previouslyacknowledged by a previous SACK frame.

An undefined control field is any of the control field encodings that are not identified in Figure 8, Figure 9, or Table 4.

A valid N(R) is one that is in the range V(A) ≤ N(R) ≤ V(S).

An information field that immediately follows the control field and consists of five octets nine octets shall be returned withthis response to provide the reason for the FRMR response. This information field format is given in Figure 1. If the controlfield of the rejected frame is not 6 octets, then the unused octets shall be set to 0.

2

1

Octet8 7 6 5 4 3 2 1Bit

control field

V(S)

W

V(R)

5

4

3

XYZ0000

0

0 0

C/R

Rejected frame

2

1

Octet8 7 6 5 4 3 2 1Bit

control field

V(S)

V

V(R)

5

4

3

WXYZ000

0

0 0

C/R

Rejected frame

6

7

8

9

Figure 1: FRMR frame information field format

Page 3

The information fields defined for the FRMR response are listed in Table 1.

Table 1: FRMR frame fields

Field DescriptionRejected frame control field The control field of the received frame that caused the frame reject.V(S) The current send state variable value of the LLE reporting the rejection condition.V(R) The current receive state variable value of the LLE reporting the rejection condition.C/R Set to 1 if the frame rejected was a response and set to 0 if the frame rejected was a

command.X Set to 1 to indicate that the control field received and returned in octets 1 and 2 was

considered invalid because the frame contained an information field that is not permittedwithin this frame or is a supervisory or unnumbered frame with incorrect length. Bit Wshall be set to 1 in conjunction with this bit.

Y Set to 1 to indicate that the information field received exceeded the maximumestablished information field length (N201) of the LLE reporting the rejection condition.

Z Set to 1 to indicate that the control field received and returned in octets 1 and 2contained an invalid N(R).

W Set to 1 to indicate that the control field received and returned in octets 1 and 2 wasundefined or not implemented.

V Set to 1 to indicate that the SACK frame control field received and returned in octets 1through 6 requests retransmission of an I frame that was previously acknowledged by aprevious SACK frame.

8.8.5 Frame rejection condition

A frame rejection condition results from one of the following conditions described in subclause 6.5.1.5 items 1) to 5).:

- the receipt of an undefined frame (see subclause 6.5, second paragraph);

- the receipt of a supervisory or unnumbered frame with incorrect length;

- the receipt of an invalid N(R); or

- the receipt of a frame with an information field that exceeds the maximum established length.

Upon occurrence of a frame rejection condition whilst in ABM operation, the LLME shall issue an GMM-STATUS-INDprimitive; and the LLE shall initiate re-establishment (see subclause 8.7.2).

Upon occurrence of a frame rejection condition during establishment of or release from ABM operation, or whilst in ADMstate, the LLE shall discard the frame.











Subject: Minimum value for N201


Reason for change:

In 04.64 version 5.0.0 two different minimum N201 values are defined. In table 6 N201 is defined in the range 500-1600octets, but in table 9 the default value for N201 for SAPI 1 is 200 octets. So one value must be defined as the minimumvalue for N201.

Some traffic will be transferred in small packets. Examples of this is signalling and X.25 packets. Signalling has alreadybeen noticed in 04.64. But also X.25 is usually sending data in small packets. The default maximum packet data size forX.25 is 128 bytes. In order to utilise the buffers in an optimum way it would be an advantage to be able to negotiate N201to be matched to these packet sizes. Then the sending window could be larger and still have the same amount of bufferspace. That would lead to less overhead over the air interface.

It is here proposed that the minimum value for N201 is adjusted to the default maximum X.25 packet size plus SNDCPlayer overhead. The minimum value for N201 is therefore proposed to be 140 octets.


Table 6 in subclause 6.5.1.6, and subclause 8.9.4


See GSM 10.60.

Affects(possibly):


Attached CRs?:




Other comments:

Page 2





0 1 0000bbbb 0-15 - down



1 - 4 095 0.1 seconds up


2 1 0000bbbb 1 - 15 - down



140500 -1 500

octets down
















Proposed change affects: SIM [ ] ME [X] Network [X]


Subject: Cipher parameter Input


Reason for change:

In the LLC specification, 04.64 v. 5.0.0, the calculation and usage of the cipher parameter Input is explained. It hashowever been found that four repetition scenarios are possible: “Reuse of RAND”, “Reuse of OC due to usage by bothacknowledged and unacknowledged operation”, “Reuse of OC due to link resets except inter-SGSN RA Updates” and“Reuse of OC due to inter-SGSN RA Updates”.

It has been discussed in SMG10 that these four repetition scenarios are to be avoided. A solution is therefore proposedthat utilises an offset value for Input instead of RAND. This offset value is transferred in the XID frame in the LLCprotocol between MS and SGSN.

The proposed functionality is described in annex 1 after the Change Request.


The subsections 6.5.1.6, 7.1.2.4, 7.2.1.1, new 7.2.1.7, 8.9, 8.9.1, new 8.9.2, A.2 and A.2.1 are affected. See annex 1 foran explanation of the proposed functionality.



See GSM 10.60.

Affects(possibly):


Attached CRs?:




Other comments: The text below in annex 1 explains the background for the CR in more detail.

2

Annex 1

IntroductionThe current version of 04.64 includes a description of how the ciphering parameter Input shall be used. There have beenfound that there are possibilities for re-use of the ciphering parameter, and therefore is a new solution suggested.

This Change Request has introduced a number of new rules connected to the Input handling. This annex will describethe complete solution and why these changes are necessary.

Problems

Reuse of RANDThe 32 least significant bits of RAND are currently used as part of the Input value. Solution:

To avoid reuse of RAND in the calculation of Input, a new parameter Input Offset Value (IOV) is introduced. IOV shallbe a 32-bit random value determined by the SGSN, and is transferred to the MS by usage of the LLC-frame XID.

Reuse of OC due to usage by both acknowledged andunacknowledged operation

The usage of both acknowledged and unacknowledged operation on the same SAPI may result in repetition of the Input.Solution:

To avoid this reuse, separate IOV for acknowledged (IOV-I) and unacknowledged (IOV-UI) operation is proposed.

The procedure for the unacknowledged links is that an XID-negotiation of IOV-UI is made on the signalling SAPIbefore ciphering is started. For any other LLC links in unacknowledged mode is the IOV-UI for the signalling SAPIused with a modification with the SAPI-value.

An LLC link in unacknowledged mode can never be restarted, only started. The LLC link for the signalling SAPI canonly be started for two reasons:

• An Attach Request is sent from the MS and received by the SGSN. In this case takes the XID-negotiation placebefore a ciphered Attach Response is sent by the SGSN to the MS.

• A Routing Area Update Request is sent from the MS to the SGSN, and results in an Inter-SGSN Routing AreaUpdate. In this case takes the XID-negotiation place before a ciphered Routing Area Update Response is sent by theSGSN to the MS.

The impact on the radio is that one LLC XID-frame is sent in each direction. The LLC XID-frame fit into one block onthe RLC/MAC interface.

The procedure for the acknowledged link is described below.

Reuse of OC due to link resets except inter-SGSN RA UpdatesAfter each link reset will the LLC frame numbers start from 0 for an LLC link in acknowledged operation. If few framesare sent between each link reset, this will result in repetition of the Input value. Solution:

Link resets are only possible for LLC links in acknowledged operation. To avoid having the same Input value before andafter a link reset, the IOV-I is changed. This is achieved by always having the SABM and UA frames contain a piggy-backed XID-frame with the IOV-I value to be used for this SAPI on the acknowledged LLC link. The LLC specification

3

already contain the possibility to piggy-back an XID frame onto an SABM or UA frame, and the change introduced hereis to define IOV-I as one of the parameters allowed in an XID-frame.

The impact on the radio is that 6 bytes are added to each SABM and UA frame, but they will still fit into one block onthe RLC/MAC interface if no other XID-parameters are negotiated.

Reuse of OC due to inter-SGSN RA UpdatesAt inter-SGSN RA update will LLC link in both acknowledged and unacknowledged mode be restarted. If few framesare sent between inter-SGSN RA updates, there is a risk of repetition of an Input value. Solution:

For unacknowledged LLC links is the same procedure as after an Attach used.

For acknowledged LLC links is the same procedure as for link reset used.

SOLUTIONThe proposed solution to these four problems are in short:

• For LLC links in acknowledged mode is an XID-frame with the IOV-I value always supplied in each SABM and UAframe. The IOV-I will be negotiated for each LLC link/SAPI. The LLC layer shall randomly select the value of IOV-I. Each IOV is valid only until the next SABM/UA is exchanged. If the SGSN sends the SABM frame, SGSN shallsupply the XID-parameter IOV-I to MS and MS shall always return the same IOV-I as an XID-parameter in the UAframe sent as a response. If the MS sends the SABM frame, the MS shall supply any value as the XID-parameterIOV-I, and the SGSN shall supply the correct IOV-I as an XID-parameter in the UA frame sent as a response.

• For LLC links in unacknowledged mode is an XID-frame with the IOV-UI value exchanged between MS and SGSNon the signalling SAPI. The exchange is needed after attach and after inter-SGSN RA update, which are the onlyinstances where the frame numbers of the UI-frames used on an unacknowledged link are reset. The IOV-UInegotiated for this SAPI will be used for all other LLC links in unacknowledged mode by use of modification withthe SAPI value for that LLC link.

•







Negotiated XID parameters shall apply to the LLE identified by the DLCI of the XID frames used, except Version andIOV-UI that applies to a LLME (i.e., a TLLI), and except Layer 3 Parameters that apply to the layer 3 above the LLE.


4


2

1

Octet8 7 6 5 4 3 2 1

Length

Bit

XL

Length

Parameter Type

High-order octet

Low-order octet

…

n

…

2 or 3

X X







0 1 0000bbbb 0-15 - down

IOV-UI (ciphering Inputoffset value for UIframes)

1 4 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

0-4294967

295

- -

IOV-I (ciphering Inputoffset value for I frames)

2 4 bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

0-4294967

295

- -



1 - 4 095 0.1 seconds up


42 1 0000bbbb 1 - 15 - down



500 -1 500

octets down








IOV-UI shall only be negotiated in ADM, and only before ciphering is enabled. IOV-I shall only be negotiated withXID parameters carried in SABM and UA frames.


N201, kD, and kU can be negotiated to any value in Range in ADM. In ABM, N201, kD, and KU can only benegotiated to the same or higher value as previously used.

5

7.1.2.4 Confirm





RAND, Ciphering AlgorithmGMM-TRIGGER X XGMM-TRIGGER X XGMM-TRIGGER X X TLLI, Cell IdGMM-SUSPEND X X X TLLIGMM-RESUME X X X TLLIGMM-PAGE X X TLLIGMM-WINDOW X X TLLI, V(R)sGMM-WINDOW X X TLLIGMM-WINDOW X X X TLLI, V(R)sGMM-IOV X X X TLLIGMM-STATUS X X X TLLI, CauseGMM ↔ LL, SNDCP ↔ LL, and SMS ↔ LLLL-ESTABLISH X X X TLLI, XID ReqLL-ESTABLISH X X X TLLI, XID Req, N201LL-ESTABLISH X X X TLLI, XID NegLL-ESTABLISH X X X TLLI, XID Neg, N201LL-RELEASE X X X X X TLLILL-XID X X X TLLI, XID ReqLL-XID X X X TLLI, XID Req, N201LL-XID X X X TLLI, XID NegLL-XID X X X TLLI, XID Neg, N201LL-DATA X X X TLLI, L3-PDU, ReferenceLL-DATA X X X TLLI, L3-PDULL-DATA X X X TLLI, ReferenceLL-UNITDATA X X X TLLI, L3-PDU, Protect, CipherLL-UNITDATA X X X TLLI, L3-PDULL ↔ RLC/MACRLC/MAC-DATA X X LL-PDU, SAPIRLC/MAC-DATA X X LL-PDURLC/MAC-UNITDATA X X LL-PDU, SAPIRLC/MAC-UNITDATA X X LL-PDURLC/MAC-STATUS X X CauseLL ↔ BSSGPBSSGP-UNITDATA X X TLLI, LL-PDU, RLC Confirm,


7.2.1.1 GMM-ASSIGN

The GMM-ASSIGN primitive shall be used by the GPRS mobility management entity to assign, change, or unassign theTLLI, the ciphering key (Kc), the random value (RAND) and the ciphering algorithm.

The TLLI Old and TLLI New parameters shall be interpreted as follows:

- If TLLI Old = all 1's and TLLI New ≠ all 1's then TLLI New shall be assigned and used when transmitting LLCframes. If a TLLI Old ≠ all 1's was associated with TLLI New then TLLI Old is unassigned. Only TLLI Newshall be accepted when received from the peer.

6

- If TLLI Old ≠ all 1's and TLLI New ≠ all 1's then TLLI Old and TLLI New are assigned and associated, andTLLI New shall be used when transmitting LLC frames. Both TLLI Old and TLLI New shall be accepted whenreceived from the peer.

- If TLLI Old ≠ all 1's and TLLI New = all 1's then TLLI Old shall be unassigned, and all DLCIs related to TLLIOld shall be reset without transmission of any LLC frames.

A LLC frame received with a DLCI belonging to an unassigned TLLI shall be discarded without any further actions,with the following exception: UI and XID frames with TLLI = unassigned and SAPI = 1 received in the SGSN shall behandled according to the LLC protocol.

Kc, RAND, and Ciphering Algorithm are associated with TLLI New (and TLLI Old if associated with TLLI New):

- If Ciphering Algorithm indicates no ciphering, then the ciphering function shall be disabled.

- Otherwise, the ciphering function shall be enabled. If a Ciphering Algorithm was already associated with TLLINew or TLLI Old, then the new Kc shall replace the previous Kc, RAND shall replace the previous RAND, andCiphering Algorithm shall replace the previous algorithm selection. All I frames, and UI frames with the E bit setto 1, shall use the new Kc, RAND, and algorithm for ciphering. All unacknowledged I frames shall be cipheredusing the new Kc, RAND, and algorithm before retransmission. As an implementation option, the previous Kc,RAND, and algorithm may be used to decipher received frames.

7.2.1.7 GMM-IOV

GMM-IOV-REQ shall be used to order LLC in the SGSN to perform an XID negotiation of IOV-UI. The LLC layershall randomly select the value of IOV-UI.

GMM-IOV-CNF shall be used to inform GMM in the SGSN that a successful XID negotiation of IOV-UI has beenmade.

7.2.1.87 GMM-STATUS

GMM-STATUS-IND shall be used to inform GMM when an LLC error that cannot be corrected by the LLC layer hasoccurred, or when LLC cannot continue its operation due to errors at the RLC/MAC or BSSGP layers as indicated withRLC/MAC-STATUS-IND or BSSGP-STATUS-IND.

8.9 List of LLC layer parametersThe LLC layer parameters listed in this subclause are associated with each DLCI, except the LLC version number andIOV-UI that areis associated with a TLLI.

A method of assigning these parameters is defined in subclause 6.5.1.6.

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

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

8.9.1 LLC version number (Version)

The LLC version number (Version) is a 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 a LLC layer parameter used for ciphering. IOV is a random 32 bit value, generated bythe SGSN. See also Annex A. IOV has no default value in the sense that it is not possible to use a default value of IOVinstead of doing an XID negotiation of IOV.

7

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.

8.9.32 Retransmission timer (T200)

The retransmission timer (T200) is a LLC layer parameter. Upon expiry of timer T200, retransmission of a frame maybe initiated according to the procedures described in clause 8. The default value of timer T200 for each SAPI is given inTable 9.

A.2 Ciphering algorithm interfaceThe ciphering algorithm has three input parameters:

- the ciphering key (Kc);

- the frame-dependent input (Input); and

- the transfer direction (Direction).

The ciphering algorithm has one output parameter:

- Output.

The relationship between the input and output parameters and the ciphering algorithm is illustrated in Figure A-1.

CipheringAlgorithmKc

Input

Output

Direction

UncipheredFrame

DecipheredFrameCiphered Frame

MS or SGSN SGSN or MS


Input

Output

Direction

Figure A-1: GPRS ciphering environment

The input and output parameters and the other elements from Figure A-1 are defined in Table A-1.

8

Table A-1: Ciphering parameters and frames

Parameter Length DescriptionKc 64 bits The GMM-ASSIGN-REQ Kc parameter received from GMM.Input 32 bits A modulo counter as defined in subclause A.2.1.Direction 1 bit Set to 0 if the direction of LLC frame transmission is from the MS to the SGSN.

Set to 1 if the direction of LLC frame transmission is from the SGSN to the MS.CipheringAlgorithm

- A GPRS ciphering algorithm as determined by the GMM-ASSIGN-REQ CipheringAlgorithm parameter received from GMM.

Output max. 1 600octets

The output of Ciphering Algorithm.

UncipheredFrame

max. 1 600octets

A LLC layer I or UI frame to be ciphered.

CipheredFrame

max. 1 600octets

A ciphered LLC layer I or UI frame. Only the information field and the FCS fieldshall be ciphered. Ciphered Frame shall be generated by bitwise XOR of Outputand the Information Field and FCS Field of Unciphered Frame.

DecipheredFrame

max. 1 600octets

A deciphered LLC layer I or UI frame. Deciphered Frame shall be generated bybitwise XOR of Output and the ciphered part of Ciphered Frame. When transmittinga LLC frame, Deciphered Frame shall be identical to Unciphered Frame if notransmission errors have occurred.

It is an implementation option to optimise the ciphering algorithm by for example producing only as many Output octetsas is needed to cipher Unciphered Frame.

A.2.1 Generation of InputThe Input parameter shall be generated according to the following algorithm if the frame is a UI frame:

Input = ( ( IOV-UIRV + LFN + OC ) modulo 232 ) ⊗ SX

The Input parameter shall be generated according to the following algorithm if the frame is an I frame:

Input = ( IOV-I + LFN + OC ) modulo 232

where:

- IOV-UI is a 32 bit random value generated by the SGSN.

- IOV-I is a 32 bit random value generated by the SGSN.

- RV is a binary random value that is set equal to the 32 least significant bits of RAND. RAND is received fromGMM in the GMM-ASSIGN-REQ primitive.

- LFN is the LLC frame number in the LLC frame header. LFN is a binary value with a length of six bits. For Iframes and I+S frames, N(S) shall be used as the LFN. For UI frames, N(U) shall be used as the LFN.

- OC is a binary overflow counter that is calculated and maintained independently at the sending and receivingsides. The length of OC is 32 bits. There are two OC counters associated with each DLCI; one forunacknowledged information transfer, and one for acknowledged information transfer. OC for unacknowledgedinformation transfer shall be set to zero whenever ADM state is entered. OC for acknowledged operation shall beset to zero whenever ABM operation is (re-)established. OC shall be incremented by 64 every time when thecorresponding LFN rolls over, i.e., when LFN exhausts its modulo and restarts counting from zero, so that OCand LFN when added together in effect is a 32 bit modulo 232 counter.

- SX is a 32 bit SAPI XOR mask. The 28 least significant bits shall be set to zero. The four most-significant bitsshall be set according to the SAPI of the LLC frame.

- + is the binary addition operation.

- ⊗ is the bitwise XOR operation.










Source: SMG3 Date: 8 December 1997

Subject: Introduction of Data Mode parameter in LLC


Reason for change:

There is a pending CR A030 to 03.60 that proposes that the parameter Data Mode also gives the possibility to select LLCand RLC/MAC transmission mode. If the CR A030 to 03.60 is approved, changes are needed in 04.64. These changes aredescribed in this document.

Changes are also required to introduce Data Mode parameter in 04.65. and they are described in CR A006.


• 7.1, table 7. Data Mode parameter is introduced in the primitives LL-UNITDATA-REQ.

• 7.2.2.5. Data Mode parameter and the additional functionality is introduced.

• 7.2.3.1, 7.2.3.2 and 7.2.4.1. The restriction of which SAPIs that were allowed to ask for UI frames to be transferred inRLC/MAC acknowledged mode is taken out of 04.64.


If the CR A030 to 03.60 is approved, then this CR regarding Data Mode Parameter in LLC is required. Also CR A006 to04.65 regarding Data Mode Parameter in SNDCP will then be required.

Affects(possibly):


Attached CRs?:




Other comments:

Page 2

7.1 Definition of service primitives and parametersCommunications between layers and between entities within the logical link control layer are accomplished by means ofservice primitives. Service primitives represent, in an abstract way, the logical exchange of information and control betweenthe logical link control layer and adjacent layers. They do not specify or constrain implementations.



where XXX designates the layer providing or using the service. For this specification XXX is:

- "GMM" for the GPRS mobility management function;

- "LL" for the logical link entities;

- "RLC/MAC" for the radio link control and media access control layers; and

- "BSSGP" for the BSSGP layer.

7.1.1 Generic names

The generic name specifies the activity that the identified layer should perform. Table 1 lists the primitives defined in thisspecification.




7.1.2.1 Request


7.1.2.2 Indication

The Indication primitive type is used by a layer providing a service to notify the next higher layer of activities related to theRequest primitive type of the peer.

7.1.2.3 Response


7.1.2.4 Confirm


Page 3




RAND, Ciphering AlgorithmGMM-TRIGGER X XGMM-TRIGGER X XGMM-TRIGGER X X TLLI, Cell IdGMM-SUSPEND X X X TLLIGMM-RESUME X X X TLLIGMM-PAGE X X TLLIGMM-WINDOW X X TLLI, V(R)sGMM-WINDOW X X TLLIGMM-WINDOW X X X TLLI, V(R)sGMM-STATUS X X X TLLI, CauseGMM ↔ LL, SNDCP ↔ LL, and SMS ↔ LLLL-ESTABLISH X X X TLLI, XID ReqLL-ESTABLISH X X X TLLI, XID Req, N201LL-ESTABLISH X X X TLLI, XID NegLL-ESTABLISH X X X TLLI, XID Neg, N201LL-RELEASE X X X X X TLLILL-XID X X X TLLI, XID ReqLL-XID X X X TLLI, XID Req, N201LL-XID X X X TLLI, XID NegLL-XID X X X TLLI, XID Neg, N201LL-DATA X X X TLLI, L3-PDU, ReferenceLL-DATA X X X TLLI, L3-PDULL-DATA X X X TLLI, ReferenceLL-UNITDATA X X X TLLI, L3-PDU, Data

ModeProtect, CipherLL-UNITDATA X X X TLLI, L3-PDULL ↔ RLC/MACRLC/MAC-DATA X X LL-PDU, SAPIRLC/MAC-DATA X X LL-PDURLC/MAC-UNITDATA X X LL-PDU, SAPIRLC/MAC-UNITDATA X X LL-PDURLC/MAC-STATUS X X CauseLL ↔ BSSGPBSSGP-UNITDATA X X TLLI, LL-PDU, RLC Confirm,


7.2.2.5 LL-UNITDATA

LL-UNITDATA-REQ shall be used to request the unconfirmed transmission of a L3-PDU to the peer. The DataModeProtect parameter indicates whether the UI frame carrying the L3-PDU shall be transmitted in protected orunprotected mode and whether RCL/MAC acknowledged or unacknowledged mode shall be used. The Cipher parameterindicates whether the UI frame shall be ciphered or not.

LL-UNITDATA-IND shall be used to deliver a L3-PDU received in an UI frame to layer 3.

7.2.3.1 RLC/MAC-DATA

RLC/MAC-DATA-REQ shall be used by a LLE in a MS to request the reliable transmission of a LL-PDU. SAPI indicatesthe SAPI of the LLE.

Page 4

RLC/MAC-DATA-IND shall be used by the RLC/MAC layer in a MS to indicate the successful reception of a LL-PDU.The LL-PDU was completely received without errors detected by the RLC layer.

All LLC frames except UI frames for SAPIs 3, 5, 9, and 11 shall be transferred with RLC/MAC-DATA primitives. All UIframes for SAPIs 3, 5, 9, and 11 shall be transferred with RLC/MAC-DATA or RLC/MAC-UNITDATA primitives.

7.2.3.2 RLC/MAC-UNITDATA

RLC/MAC-UNITDATA-REQ shall be used by a LLE in a MS to request the unreliable transmission of an UI frame. SAPIindicates the SAPI of the LLE.

RLC/MAC-UNITDATA-IND shall be used by the RLC/MAC layer in a MS to indicate the reception of an UI frame.

Only UI frames for SAPIs 3, 5, 9, and 11 canshall be transferred with RLC/MAC-UNITDATA primitives.

7.2.4.1 BSSGP-UNITDATA

BSSGP-UNITDATA-REQ shall be used by a LLE in a SGSN to request the transmission of a LL-PDU. RLC Confirmindicates whether the request shall be mapped into a RLC/MAC-DATA-REQ or RLC/MAC-UNITDATA-REQ primitive inthe BSS. SAPI indicates the SAPI of the LLE.

All LLC frames except UI frames for SAPI 3, 5, 9 and 11 shall be transferred with RLC Confirm indicating mapping intoRLC/MAC-DATA-REQ primitive. All UI frames for SAPIs 3, 5, 9, and 11 shall be transferred with RLC Confirmindicating mapping into a RLC/MAC-DATA-REQ or RLC/MAC-UNITDATA-REQ primitives. All other LLC frames shallbe transferred with RLC Confirm indicating mapping into a RLC/MAC-DATA-REQ primitive.

BSSGP-UNITDATA-IND shall be used by the BSSGP layer in a SGSN to indicate the reception of a LL-PDU. Cell Idindicates the location of the MS when the LL-PDU was transmitted.











Subject: Separate N201 parameter for I and U-UI frames.


Reason for change:

Currently the LLC maximum information size (N201) is defined as one parameter per SAPI. Thismeans that I, UI and U frames belonging to the same SAPI must use the same value of N201. To avoidlarge buffers for I-frames N201 will be negotiated down by the MS. This means that also UI-framesmust be segmented which leads to unnecessary overhead.

This CR suggests that two separate N201 parameters are defined; one for I-frames and one for UI andU-frames. The default value of N201 for UI and U frames are set to the min value since no parameternegotiation is done prior to UI and U-frame transmission.

The N201 min value is currently 500. If the CR that suggests a min value of 140 is accepted theconcerned min and default values in this CR shall be changed to 140 as well.


Changes are made to subsections 6.3.5.4.5, 6.5.1.6, 7.1.2, 8.9.4 and 8.9.5.


See GSM 10.60.

Affects(possibly):


Attached CRs?:




Other comments:

6.3.5.4.5 Other parameters and variables

The only other parameter defined for unacknowledged operation is the number of octets (N201-U) inthe information field of the UI frame. See subclause 8.9.4.


This frame shall be used to negotiate and re-negotiate LLC layer parameters and layer-3 parameters.XID frames can be transmitted in ADM and ABM.

The negotiation procedure is one-step, i.e., one side shall start the process by sending an XIDcommand, offering a certain set of parameters from the applicable parameter repertoire (see Table) thesending entity wants to negotiate, proposing values within the allowed range. In return, the other sideshall send an XID response, either confirming these parameter values by returning the requested values,or offering higher or lower ones in their place. See Table for sense of negotiation. Default values asdefined in subclause 8.9 shall apply to those parameters that are not commented upon by the respondingside. This shall end the negotiation process.

Both entities shall support the negotiated values, however under certain conditions one or moreparameters may need to be re-negotiated (e.g., in the case of a change in SGSN).



Negotiated XID parameters shall apply to the LLE identified by the DLCI of the XID frames used,except Version that applies to a LLME (i.e., a TLLI), and except Layer 3 Parameters that apply to thelayer 3 above the LLE.

In the case of a collision of XID commands, all XID commands shall be ignored. The MS shall restartthe parameter negotiation on expiry of timer T200, while the SGSN shall do so on expiry of twice thevalue of timer T200. An unsuccessful XID exchange shall be repeated on expiry of timer T200. AfterN200 times of unsuccessful repetition, the link may be terminated (e.g., TLLI may be released by theSGSN).

Table lists the negotiable LLC layer parameters. Figure 12 shows the format of the XID informationfield.

2

1

Octet8 7 6 5 4 3 2 1

Length

Bit

XL

Length

Parameter Type

High-order octet

Low-order octet

…

n

…

2 or 3

X X


A parameter item consists of one or two type/length octets followed by the value of that parameter. TheXID Length (XL) bit indicates whether the Length field is 2 bits or 8 bits long. If XL is set to 0, thenLength consists of 2 bits and type/length occupies one octet. If XL is set to 1 then Length consists of 8bits and type/length occupies two octets. The length indicator gives the number of octets that the valueactually occupies. The parameter items can be arranged in arbitrary order. The parameter items shallbegin in the first octet of the XID information field and follow on contiguously.





0 1 0000bbbb 0-15 - down



1 - 4 095 0.1 seconds up


2 1 0000bbbb 1 - 15 - down

N201-U (maximuminformation size for Uand UI frames)


500 -1 500

octets down

N201-I (maximuminformation size for I-frames)


500 -1 500

octets down






FFS: The exact maximum value for N201 is 1 600 - BSSGP protocol overhead - LLC protocoloverhead, and will be calculated later when GSM 08.16 and GSM 08.18 are beingcompleted. This FFS item affects all references to the maximum information size in thisdocument.


T200, andN200 and N201-U can be negotiated in ADM and ABM. The new value of T200 shall onlyapply to timers set after the negotiation has been completed.

N201-I, kD, and kU can be negotiated to any value in Range in ADM. In ABM, N201-I, kD, and KUcan only be negotiated to the same or higher value as previously used.




7.1.2.1 Request

The Request primitive type is used when a higher layer is requesting a service from the next lowerlayer.

7.1.2.2 Indication

The Indication primitive type is used by a layer providing a service to notify the next higher layer ofactivities related to the Request primitive type of the peer.

7.1.2.3 Response

The Response primitive type is used by a layer to acknowledge receipt, from the next lower layer, of theIndication primitive type.

7.1.2.4 Confirm

The Confirm primitive type is used by the layer providing the requested service to confirm that theactivity has been completed (successfully or unsuccessfully).




RAND, Ciphering AlgorithmGMM-TRIGGER X XGMM-TRIGGER X XGMM-TRIGGER X X TLLI, Cell IdGMM-SUSPEND X X X TLLIGMM-RESUME X X X TLLIGMM-PAGE X X TLLIGMM-WINDOW X X TLLI, V(R)sGMM-WINDOW X X TLLIGMM-WINDOW X X X TLLI, V(R)sGMM-STATUS X X X TLLI, CauseGMM ↔ LL, SNDCP ↔ LL, and SMS ↔ LLLL-ESTABLISH X X X TLLI, XID ReqLL-ESTABLISH X X X TLLI, XID Req, N201-I,

N201-ULL-ESTABLISH X X X TLLI, XID NegLL-ESTABLISH X X X TLLI, XID Neg, N201-I,

N201-ULL-RELEASE X X X X X TLLILL-XID X X X TLLI, XID ReqLL-XID X X X TLLI, XID Req, N201-I,

N201-ULL-XID X X X TLLI, XID NegLL-XID X X X TLLI, XID Neg, N201-I,

N201-ULL-DATA X X X TLLI, L3-PDU, ReferenceLL-DATA X X X TLLI, L3-PDULL-DATA X X X TLLI, ReferenceLL-UNITDATA X X X TLLI, L3-PDU, Protect,

CipherLL-UNITDATA X X X TLLI, L3-PDULL ↔ RLC/MACRLC/MAC-DATA X X LL-PDU, SAPIRLC/MAC-DATA X X LL-PDURLC/MAC-UNITDATA X X LL-PDU, SAPIRLC/MAC-UNITDATA X X LL-PDURLC/MAC-STATUS X X CauseLL ↔ BSSGPBSSGP-UNITDATA X X TLLI, LL-PDU, RLC Confirm,



The maximum number of octets in an information field (N201) is a LLC layer parameter. See alsosubclause 5.5. The default value of N201 for each SAPI is given in Table . The minimum value ofN201 shall be 200 octets, and the maximum value shall be 1 600 octets.

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


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

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


SAPI Layer 3 Version T200 N200 N201-U N201-I kD kU1 GMM 5 s 3 200 200 Note 2 Note 2 Note 23 QoS1 5 s 3 500 1 600 16 165 QoS2 0 10 s 3 500 1 600 8 87 SMS 20 s 3 500 1 600 Note 2 Note 2 Note 29 QoS3 60 s 3 500 1 600 4 4

11 QoS4 120 s 3 500 1 600 2 2

NOTE 1: The proper operation of the procedure requires that timer T200 be greater than themaximum time between transmission of command frames and the reception of theircorresponding response or acknowledgement frames.

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









Proposed change affects: SIM [ ] ME [x] Network [ ]


Subject: Cell Update Procedure


Reason for change:

In 04.64 version 5.0.0 it is described how GMM triggers LLC to transmit any single frame to perform Cell Update. It isstated that it is an implementation option which frame to transmit. It is however not a good solution to transmit just anyframe and therefore rules should be defined.


Subclause 7.2.1.2.


See GSM 10.60.

Affects(possibly):


Attached CRs?:




Other comments:

Page 2

7.2.1.2 GMM-TRIGGER

GMM-TRIGGER-REQ shall be used in the MS to order LLC to transmit any single frame. . The type of frame to betransmitted and the SAPI is an implementation option, but for optimum performance, If there is a frame waiting to betransmitted in the MS, this frame shall that is needed at the peer side should be transmitted, e.g., an I frame if an L3-PDU isavailable, or a SACK or a NACK frame if I frames are missing. Otherwise,and if the LLE is in ABM state, a supervisoryframe shall be transmitted according to subclause 8.6.5.1. If the LLE is in ADM state a UI frame with no information fieldshall be transmitted. There is only need to transmit a frame on one SAPI. Which SAPI to choose is implementationdependant.

NOTE: GMM-TRIGGER-REQ is normally used for cell updates.

The LLME in the MS shall send GMM-TRIGGER-IND to GMM every time a LL-PDU is transmitted, i.e., every time aRLC/MAC-DATA-REQ or RLC/MAC-UNITDATA-REQ is delivered to the lower layer. The LLME in the SGSN shallsend GMM-TRIGGER-IND to GMM every time a valid LL-PDU is received, i.e., every time a BSSGP-UNITDATA-INDcontaining a valid LL-PDU is received (see subclause 5.9).

NOTE: GMM-TRIGGER-IND moves the GMM Context to READY state and sets the READY timer in GMM.

8.4.2 Receipt of unacknowledged information

On receipt of an UI command frame with a DLCI that is supported by the receiver, the contents of the information fieldshall be passed to the appropriate layer-3 entity with a LL-UNITDATA-IND (L3-PDU) primitive. If there is no informationfield the UI frame shall be discarded after GMM-TRIGGER-IND is sent to GMM. Otherwise, the UI command frame shallbe discarded without any further actions.











Subject: ABM SAPIs


Reason for change:

ABM mode is not allowed for SAPI 1 and 7. This is however not explicitly stated in 04.64. This CRclarifies that.


Changes are made to subsections 4.3, 4.4, 8.9.5 and 8.5.1.2.


See GSM 10.60.

Affects(possibly):


Attached CRs?:




Other comments:

4.3 Unacknowledged operationWith this type of operation, layer-3 information is transmitted in numbered Unconfirmed Information(UI) frames. The UI frames are not acknowledged at the LLC layer. No error recovery mechanisms aredefined, but transmission and format errors are detected.

Flow control procedures are not defined.

Two modes of unacknowledged operation are defined:

- protected mode in which the FCS field protects the frame header and information field; and

- unprotected mode in which the FCS field protects the frame header but not the information field.

Unacknowledged operation is allowed for all non-reserved SAPIs (see table 2).

4.4 Acknowledged operationWith this type of operation, layer-3 information is transmitted in numbered Information (I) frames, TheI frames are acknowledged at the LLC layer. Error recovery procedures based on retransmission ofunacknowledged I frames are specified. Several I frames may be unacknowledged at the same time. Inthe case of errors that cannot be corrected by the logical link control layer, a report to GPRS mobilitymanagement shall be made.

Flow control procedures are defined.

Acknowledged operation requires that ABM operation has been initiated by an establishment procedureusing the Set Asynchronous Balanced Mode (SABM) command.

Acknowledged operation is not allowed for SAPIs 1 and 7.


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

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



11 QoS4 120 s 3 1 600 2 2

NOTE 1: The proper operation of the procedure requires that timer T200 be greater than themaximum time between transmission of command frames and the reception of theircorresponding response or acknowledgement frames.

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

8.5.1.2 Establishment procedures

A LLE shall initiate a request for the ABM operation to be set by transmitting the SABM command. Allexisting exception conditions shall be cleared, the retransmission counter shall be reset, and timer T200shall 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-REQprimitives and all I frames in queue.

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

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

- upon reception of a LL-ESTABLISH-RES primitive from layer 3 respond with an UA responsewith the F bit set to the same binary value as the P bit in the received SABM command (i.e.,F=1);

- set V(S), V(R) and V(A) 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), and V(A) to 0; and

- enter the ABM state and inform layer 3 using the LL-ESTABLISH-CNF primitive.

ReceiverOriginator

LL-ESTABLISH-CNF

LL-ESTABLISH-REQ

LL-ESTABLISH-RES


UA

LL-ESTABLISH-IND

SABM

Figure 1: ABM establishment procedure

If the receiving LLE is unable to enter the ABM state, it shall respond to the SABM command with aDM 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 theseSAPIs shall be responded with a DM response.

Upon reception of a DM response with the F bit set to 1, the originator of the SABM command shallindicate this to layer 3 by means of the LL-RELEASE-IND primitive, and reset timer T200. It shall thenenter the ADM state. DM responses with the F bit set to 0 shall be ignored in this case.

ETSI STC SMG3 TDoc SMG3 97P473Brentford, England3-5 December, 1997









Source: SMG3 Date: 8 December, 1997

Subject: Update of service primitive names


Reason for change:

Harmonization with CR no. A008 rev. 2 on 04.07 version 5.2.0.


3.2, 4.5.3, 4.7.3, 7.1, 7.1.2, 7.2.1, 7.2.3, 7.2.4.1, 8.3.1, 8.3.2, 8.5.1.3, 8.5.2.3, 8.5.4, 8.6.5, 8.6.7, 8.7.2, 8.8.2, 8.8.5,8.8.6, 8.8.7, 8.8.8, A.2, A.2.1 and B.2.



See GSM 10.60.

Affects(possibly):


Attached CRs?:




Other comments:

2

3.2 AbbreviationsFor the purposes of this specification the following abbreviations apply. Additional applicable abbreviations can befound in GSM 01.04 [1] and GSM 03.60.

ABM Asynchronous Balanced ModeADM Asynchronous Disconnected ModeDLCI Data Link Connection IdentifierGMM GPRS Mobility ManagementGRR GPRS Radio Resources service access pointLL Logical LinkLLC Logical Link ControlLLE Logical Link EntityLLGMM LLC to GPRS Mobility Management service access pointLLM Logical Link ManagementLLME Logical Link Management EntitySAPI Service Access Point IdentifierSGSN Serving GPRS Support NodeSNDC SubNetwork Dependent Convergence

4.5.3 TLLI assignment

TLLI assignment is controlled by GMM. TLLIs are assigned, changed, and unassigned with the LLGMM-ASSIGN-REQ primitive, as described in subclause 7.2.1.1.

4.7.3 Logical Link Management

The Logical Link Management Entity (LLME) manages the resources that have an impact on individual connections.There is one LLME per TLLI. Functions provided by the LLME are:

- parameter initialisation;

- error processing; and

- connection flow control invocation.

3

SGSNMS

GPRS Mobility Management

LogicalLink

ManagementEntity

Multiplex Procedure

QoS 2 QoS 3QoS 1 QoS 4

SNDCP

GMM SMS

SMS

LogicalLink

EntitySAPI=7

RLC/MAC

LogicalLink

EntitySAPI=11

LogicalLink

EntitySAPI=9

LogicalLink

EntitySAPI=5

LogicalLink

EntitySAPI=3

LogicalLink

EntitySAPI=1

RLC/MAC

GMM

RLC/MAC layer

LLC layer

Layer 3

LLC layer

BSSGP

BSSGP

BSSGP layer

Signalling

Signalling and data transfer

4

SGSNMS

GPRS Mobility Management

LogicalLink

ManagementEntity

Multiplex Procedure

QoS 2 QoS 3QoS 1 QoS 4

SNDCP

LLGMM LLSMS

SMS

LogicalLink

EntitySAPI=7

RLC/MAC

LogicalLink

EntitySAPI=11

LogicalLink

EntitySAPI=9

LogicalLink

EntitySAPI=5

LogicalLink

EntitySAPI=3

LogicalLink

EntitySAPI=1

GRR

LLGMM

RLC/MAC layer

LLC layer

Layer 3

LLC layer

BSSGP

BSSGP

BSSGP layer

Signalling

Signalling and data transfer

Figure 1: Functional model of the LLC layer

The RLC/MAC layer functions are described in GSM 03.64 [6]. BSSGP is specified in GSM 08.18. SNDCP is specifiedin GSM 04.65.

7.1 Definition of service primitives and parametersCommunications between layers and between entities within the logical link control layer are accomplished by means ofservice primitives. Service primitives represent, in an abstract way, the logical exchange of information and controlbetween the logical link control layer and adjacent layers. They do not specify or constrain implementations.



where XXX designates the service access point between the LLC layer and the layer providing or using the service. Forthis specification XXX is:

- "LLGMM" for the SAP between the LLC layer and the GPRS mobility management function;

- "LL" for the SAPs between the LLEs and layer 3logical link entities;

- "GRRRLC/MAC" for the SAP between the LLC layer and the RLC/MAC layerradio link control and mediaaccess control layers; and

5

- "BSSGP" for the SAP between the LLC layer and the BSSGP layer.




7.1.2.1 Request


7.1.2.2 Indication

The Indication primitive type is used by a layer providing a service to notify the next higher layer of activities related tothe Request primitive type of the peer.

7.1.2.3 Response


7.1.2.4 Confirm


6



GMM ↔ LLMLLGMM-ASSIGN X X X TLLI Old, TLLI New, Kc,

RAND, Ciphering AlgorithmLLGMM-TRIGGER X XLLGMM-TRIGGER X XLLGMM-TRIGGER X X TLLI, Cell IdLLGMM-SUSPEND X X X TLLILLGMM-RESUME X X X TLLILLGMM-PAGE X X TLLILLGMM-WINDOW X X TLLI, V(R)sLLGMM-WINDOW X X TLLILLGMM-WINDOW X X X TLLI, V(R)sLLGMM-STATUS X X X TLLI, CauseGMM ↔ LL, SNDCP ↔ LL, and SMS ↔ LLLL-ESTABLISH X X X TLLI, XID ReqLL-ESTABLISH X X X TLLI, XID Req, N201LL-ESTABLISH X X X TLLI, XID NegLL-ESTABLISH X X X TLLI, XID Neg, N201LL-RELEASE X X X X X TLLILL-XID X X X TLLI, XID ReqLL-XID X X X TLLI, XID Req, N201LL-XID X X X TLLI, XID NegLL-XID X X X TLLI, XID Neg, N201LL-DATA X X X TLLI, L3-PDU, ReferenceLL-DATA X X X TLLI, L3-PDULL-DATA X X X TLLI, ReferenceLL-UNITDATA X X X TLLI, L3-PDU, Protect, CipherLL-UNITDATA X X X TLLI, L3-PDULL ↔ RLC/MACGRRRLC/MAC-DATA X X LL-PDU, SAPIGRRRLC/MAC-DATA X X LL-PDUGRRRLC/MAC-UNITDATA X X LL-PDU, SAPIGRRRLC/MAC-UNITDATA X X LL-PDUGRRRLC/MAC-STATUS X X CauseLL ↔ BSSGPBSSGP-UNITDATA X X TLLI, LL-PDU, RLC Confirm,


7.2.1 GMM - LLC primitives

7.2.1.1 LLGMM-ASSIGN

The LLGMM-ASSIGN primitive shall be used by the GPRS mobility management entity to assign, change, or unassignthe TLLI, the ciphering key (Kc), the random value (RAND), and the ciphering algorithm.

The TLLI Old and TLLI New parameters shall be interpreted as follows:

- If TLLI Old = all 1's and TLLI New ≠ all 1's then TLLI New shall be assigned and used when transmitting LLCframes. If a TLLI Old ≠ all 1's was associated with TLLI New then TLLI Old is unassigned. Only TLLI Newshall be accepted when received from the peer.

- If TLLI Old ≠ all 1's and TLLI New ≠ all 1's then TLLI Old and TLLI New are assigned and associated, andTLLI New shall be used when transmitting LLC frames. Both TLLI Old and TLLI New shall be accepted whenreceived from the peer.

7

- If TLLI Old ≠ all 1's and TLLI New = all 1's then TLLI Old shall be unassigned, and all DLCIs related to TLLIOld shall be reset without transmission of any LLC frames.

A LLC frame received with a DLCI belonging to an unassigned TLLI shall be discarded without any further actions,with the following exception: UI and XID frames with TLLI = unassigned and SAPI = 1 received in the SGSN shall behandled according to the LLC protocol.

Kc, RAND, and Ciphering Algorithm are associated with TLLI New (and TLLI Old if associated with TLLI New):

- If Ciphering Algorithm indicates no ciphering, then the ciphering function shall be disabled.

- Otherwise, the ciphering function shall be enabled. If a Ciphering Algorithm was already associated with TLLINew or TLLI Old, then the new Kc shall replace the previous Kc, RAND shall replace the previous RAND, andCiphering Algorithm shall replace the previous algorithm selection. All I frames, and UI frames with the E bit setto 1, shall use the new Kc, RAND, and algorithm for ciphering. All unacknowledged I frames shall be cipheredusing the new Kc, RAND, and algorithm before retransmission. As an implementation option, the previous Kc,RAND, and algorithm may be used to decipher received frames.

7.2.1.2 LLGMM-TRIGGER

LLGMM-TRIGGER-REQ shall be used in the MS to order LLC to transmit any single frame. The type of frame to betransmitted and the SAPI is an implementation option, but for optimum performance, a frame that is needed at the peerside should be transmitted, e.g., an I frame if an L3-PDU is available, or a SACK or a NACK frame if I frames aremissing.

NOTE: LLGMM-TRIGGER-REQ is normally used for cell updates.

The LLME in the MS shall send LLGMM-TRIGGER-IND to GMM every time a LL-PDU is transmitted, i.e., everytime a GRRRLC/MAC-DATA-REQ or GRRRLC/MAC-UNITDATA-REQ is delivered to the lower layer. The LLMEin the SGSN shall send LLGMM-TRIGGER-IND to GMM every time a valid LL-PDU is received, i.e., every time aBSSGP-UNITDATA-IND containing a valid LL-PDU is received (see subclause 5.9).

NOTE: LLGMM-TRIGGER-IND moves the GMM Context to READY state and sets the READY timer inGMM.

7.2.1.3 LLGMM-SUSPEND

LLGMM-SUSPEND-REQ shall be used to order LLC to suspend operation for a MS until LLGMM-RESUME-REQ isreceived. While suspended, LLC shall:

- save L3-PDUs if any are buffered;

- save unacknowledged I frames;

- save the state of the state variables (e.g., the transmit and receive counters);

- reset timer T200; and

- stop frame transmission.

Frame reception shall still be possible. For SAPI = 1, ADM procedures including UI frame transmission shall still bepossible.

7.2.1.4 LLGMM-RESUME

LLGMM-RESUME-REQ shall be used to order LLC to resume a suspended operation for a MS without loss of theL3-PDUs or I frames that were saved when LLGMM-SUSPEND-REQ was received. If timer T200 was reset uponreception of LLGMM-SUSPEND-REQ then timer T200 shall be set.

8

7.2.1.5 LLGMM-PAGE

LLGMM-PAGE-IND shall be sent to GMM in the SGSN whenever LLC has a LL-PDU ready for transmission and LLCis suspended. The LL-PDU shall not be transmitted until LLGMM-RESUME-REQ has been received from GMM.

NOTE: LLGMM-PAGE-IND causes GMM to initiate paging of the MS.

7.2.1.6 LLGMM-WINDOW

LLGMM-WINDOW shall be used by GMM to fetch the receive state variable V(R) of the DLCIs in ABM. In the MS,LLGMM-WINDOW-REQ shall additionally be used to deliver V(R) values received from the SGSN via GMMprocedures. The LLEs shall treat the V(R) values received as acknowledgements for all the I frames transmitted with anN(S) up to and including the received V(R) - 1.

7.2.1.7 LLGMM-STATUS

LLGMM-STATUS-IND shall be used to inform GMM when an LLC error that cannot be corrected by the LLC layerhas occurred, or when LLC cannot continue its operation due to errors at the RLC/MAC or BSSGP layers as indicatedwith GRRRLC/MAC-STATUS-IND or BSSGP-STATUS-IND.

7.2.3 LL - RLC/MAC primitives

Although the GRRRLC/MAC-DATA or GRRRLC/MAC-UNITDATA primitives are used in all LLC frame transferoperations, for simplicity reasons they are not included in the procedure descriptions in clause 8.

7.2.3.1 GRRRLC/MAC-DATA

GRRRLC/MAC-DATA-REQ shall be used by a LLE in a MS to request the reliable transmission of a LL-PDU. SAPIindicates the SAPI of the LLE.

GRRRLC/MAC-DATA-IND shall be used by the RLC/MAC layer in a MS to indicate the successful reception of aLL-PDU. The LL-PDU was completely received without errors detected by the RLC layer.

All LLC frames except UI frames for SAPIs 3, 5, 9, and 11 shall be transferred with GRRRLC/MAC-DATA primitives.

7.2.3.2 GRRRLC/MAC-UNITDATA

GRRRLC/MAC-UNITDATA-REQ shall be used by a LLE in a MS to request the unreliable transmission of an UIframe. SAPI indicates the SAPI of the LLE.

GRRRLC/MAC-UNITDATA-IND shall be used by the RLC/MAC layer in a MS to indicate the reception of an UIframe.

Only UI frames for SAPIs 3, 5, 9, and 11 shall be transferred with GRRRLC/MAC-UNITDATA primitives.

7.2.3.3 GRRRLC/MAC-STATUS

GRRRLC/MAC-STATUS-IND indicates that the RLC/MAC layer is unable to deliver data. The LLC layer shall, ifpossible, continue its operation.

7.2.4.1 BSSGP-UNITDATA

BSSGP-UNITDATA-REQ shall be used by a LLE in a SGSN to request the transmission of a LL-PDU. RLC Confirmindicates whether the request shall be mapped into a GRRRLC/MAC-DATA-REQ or GRRRLC/MAC-UNITDATA-REQ primitive in the BSS. SAPI indicates the SAPI of the LLE.

UI frames for SAPIs 3, 5, 9, and 11 shall be transferred with RLC Confirm indicating mapping into a GRRRLC/MAC-UNITDATA-REQ primitive. All other LLC frames shall be transferred with RLC Confirm indicating mapping into aGRRRLC/MAC-DATA-REQ primitive.

9

BSSGP-UNITDATA-IND shall be used by the BSSGP layer in a SGSN to indicate the reception of a LL-PDU. Cell Idindicates the location of the MS when the LL-PDU was transmitted.

8.3.1 TLLI assignment

GMM shall assign a TLLI by sending a LLGMM-ASSIGN-REQ (TLLI New ≠ all 1's) primitive to LLME. Uponreceiving LLGMM-ASSIGN-REQ, LLME shall enter the TLLI Assigned state and all its LLEs shall enter the ADMstate. TLLI assignment is illustrated in Figure 2.

SGSNMS

LL-UNITDATA-REQ

GMM-TRIGGER-IND

GMM-ASSIGN-REQ

GMM-ASSIGN-REQ

GMM LLC GMMLLC

UI

LL-UNITDATA-IND

SGSNMS

LL-UNITDATA-REQ

LLGMM-TRIGGER-IND

LLGMM-ASSIGN-REQ

LLGMM-ASSIGN-REQ

GMM LLC GMMLLC

UI

LL-UNITDATA-IND

Figure 2: TLLI assignment procedure

8.3.2 TLLI unassignment

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

10

SGSNMS

GMM-ASSIGN-REQ GMM-ASSIGN-REQ

GMM LLC GMMLLC

SGSNMS

LLGMM-ASSIGN-REQ LLGMM-ASSIGN-REQ

GMM LLC GMMLLC

Figure 3: TLLI unassignment procedure


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 frame as above;



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 a LL-RELEASE-IND to layer 3 and enter ADM state.


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

- retransmit the DISC command as defined in subclause 8.5.2.2;



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

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 ofthe received P bit;

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

- on receipt of an unsolicited DM response with the F bit set to 0, the LLE shall, if it is able to, initiate theestablishment procedures by the transmission of a SABM (see subclause 8.5.1.2), otherwise, the DM shall beignored;

- 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 a LLGMM-STATUS-IND primitive indicating a possible multiple-assignment of a TLLI value shall be issued; and

11

- all other frame types shall be discarded.

8.6.5 Receiving RNR frames

After receiving a valid RNR command or response, if the LLE is not engaged in a mode-setting operation, it shall set apeer receiver busy condition and then:

- if it was a RNR command with the P bit set to 1, it shall respond with a RR, RNR, SACK, or NACK responsewith the F bit set to 1 (see subclause 8.6.5.1).; and

- if it was a RNR response with the F bit set to 1, an existing timer recovery condition shall be cleared.

The LLE shall take note of the peer receiver busy condition and not transmit any I frames to the peer that has indicatedthe busy condition.

The LLE shall then:

- 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 inthe RNR frame; and

- set timer T200 unless a supervisory response frame with the F bit set to 1 is still expected, in order to start theinquiry process.


- if it is not yet in a timer recovery condition, enter the timer recovery condition and reset the retransmission countvariable; or

- if it is already in a timer recovery condition, add one to its retransmission count variable; and

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

- transmit an appropriate supervisory command (see subclause 8.6.5.1) with a P bit set to 1;

- set timer T200; or

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

The LLE receiving the supervisory frame with the P bit set to 1 shall respond, at the earliest opportunity, with anappropriate supervisory response frame (see subclause 8.6.5.1) with the F bit set to 1 to indicate whether or not its ownreceiver busy condition still exists.

Upon receipt or the supervisory response with the F bit set to 1, the LLE shall reset timer T200, and:

- if the response is a RR, SACK or NACK response, the peer receiver busy condition shall be cleared and the LLEmay transmit new I frames or retransmit I frames as defined in subclauses 8.6.1 or 8.6.4, respectively; or

- if the response is a RNR response, the LLE receiving the response shall proceed according to subclause 8.6.5,first paragraph.

If a supervisory command (RR, RNR, SACK, or NACK) with the P bit set to 0 or 1, or a supervisory response frame(RR, RNR, SACK, or NACK) with the F bit set to 0 is received during the inquiry process, the LLE shall:

- if the supervisory frame is a RR, SACK, or NACK command frame or a RR, SACK, or NACK response framewith the F bit set to 0, clear the peer receiver busy condition and if the supervisory frame received was acommand with the P bit set to 1, transmit the appropriate supervisory response frame (see subclause 8.6.5.1) withthe F bit set to 1. However, the transmission or retransmission of I frames shall not be undertaken until theappropriate supervisory response frame with the F bit set to 1 is received or until the expiry of timer T200; or

- if the supervisory frame is a RNR command frame or a RNR response frame with the F bit set to 0, retain thepeer receiver busy condition, and if the supervisory frame received was a RNR command with the P bit set to 1,transmit the appropriate supervisory response frame (see subclause 8.6.5.1) with the F bit set to 1.

12

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

8.6.7 Waiting acknowledgement

The LLE shall maintain an internal retransmission count variable.


- if it is not yet in the timer recovery condition, enter the timer recovery condition and reset the retransmissioncount variable; or

- if it is already in the timer recovery condition, add one to its retransmission count variable.

The LLE shall then:

a) if the value of the retransmission count variable is less than N200, set timer T200; and either:

- transmit an appropriate supervisory command (see subclause 8.6.5.1) with the P bit set to 1; or

- retransmit an I frame with the P bit set to 1; or

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

The timer recovery condition is cleared when LLE receives a valid supervisory response frame with the F bit set to 1. Ifthe received supervisory frame N(R) is within the range from its current V(A) to its current V(S) inclusive, it shall set itsV(A) to the value of the received N(R). Timer T200 shall be reset if the received supervisory frame response is a RR,SACK, or NACK response, and then the LLE shall resume with I frame transmission or retransmission, as appropriate.Timer T200 shall be set if the received supervisory response is a RNR response, to proceed with the inquiry processaccording to subclause 8.6.5.

I frames shall only be retransmitted upon expiry of timer T200, or when retransmission is requested with a SACK orNACK frame received from the peer LLE.

8.7.2 Procedures

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

In the case of LLC layer and peer-initiated re-establishment, the LLE shall, if V(S) > V(A) prior to re-establishment,issue a LL-ESTABLISH-IND primitive to layer 3, and discard all I queues, and LLME shall issue an LLGMM-STATUS-IND primitive to GMM.

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

8.8.2 N(R) sequence error

An N(R) sequence error exception condition occurs in the transmitter upon reception of a valid supervisory frame or Iframe that contains an invalid N(R) value. A valid N(R) is one that is in the range V(A) ≤€N(R) ≤€V(S).

The LLME shall inform GMM of this exception condition by means of the LLGMM-STATUS-IND primitive, and LLEshall initiate re-establishment according to subclause 8.7.2.

8.8.5 Frame rejection condition

A frame rejection condition results from one of the following conditions:

- the receipt of an undefined frame (see subclause 6.5, second paragraph);

- the receipt of a supervisory or unnumbered frame with incorrect length;

13

- the receipt of an invalid N(R); or

- the receipt of a frame with an information field that exceeds the maximum established length.

Upon occurrence of a frame rejection condition whilst in ABM operation, the LLME shall issue an LLGMM-STATUS-IND primitive; and the LLE shall initiate re-establishment (see subclause 8.7.2).

Upon occurrence of a frame rejection condition during establishment of or release from ABM operation, or whilst inADM state, the LLE shall discard the frame.

8.8.6 Receipt of a FRMR response frame

Upon receipt of a FRMR response frame whilst in ABM operation, the LLME shall issue an LLGMM-STATUS-INDprimitive; and the LLE shall initiate re-establishment (see subclause 8.7.2).

8.8.7 Unsolicited response frames

The action to be taken on the receipt of an unsolicited response frame is defined in Table 2. Upon the receipt of anunsolicited UA response, the LLE shall assume a possible multiple-TLLI assignment, and LLME shall inform GMM.

Table 2: Actions taken on receipt of unsolicited response frames

Unsolicited StateResponse

FrameTLLI Assigned

/ ADMLocal

EstablishmentLocal

ReleaseABM Timer

RecoveryUA response

F = 1LLGMM-STATUS-

INDSolicited Solicited LLGMM-STATUS-

INDLLGMM-STATUS-

IND

UA responseF = 0

LLGMM-STATUS-IND

LLGMM-STATUS-IND

LLGMM-STATUS-IND

LLGMM-STATUS-IND

LLGMM-STATUS-IND

DM responseF = 1

Ignore Solicited Solicited LLGMM-STATUS-IND

LLGMM-STATUS-IND

Re-establish ABMDM response

F = 0Establish ABM Ignore Ignore LLGMM-STATUS-

INDRe-establish ABM

LLGMM-STATUS-IND

Re-establish ABMSupervisory

responseF = 1

Ignore Ignore Ignore LLGMM-STATUS-IND

Solicited

Supervisoryresponse

F = 0

Ignore Ignore Ignore Solicited Solicited

8.8.8 Multiple-assignment of TLLI value

A LLE shall assume multiple assignment of a TLLI value and initiate recovery upon:

- the receipt of a UA response frame whilst in ABM state;

- the receipt of a UA response frame whilst in the Timer Recovery state; and

- the receipt of a UA response frame whilst in the TLLI Assigned ADM state.

LLME shall then inform GMM by means of the LLGMM-STATUS-IND primitive.




14



- Output.

The relationship between the input and output parameters and the ciphering algorithm is illustrated in Figure A-1.


Input

Output

Direction

UncipheredFrame




Input

Output

Direction

Figure A-1: GPRS ciphering environment

The input and output parameters and the other elements from Figure A-1 are defined in Table A-1.

Table A-1: Ciphering parameters and frames

Parameter Length DescriptionKc 64 bits The LLGMM-ASSIGN-REQ Kc parameter received from GMM.Input 32 bits A modulo counter as defined in subclause A.2.1.Direction 1 bit Set to 0 if the direction of LLC frame transmission is from the MS to the SGSN.


- A GPRS ciphering algorithm as determined by the LLGMM-ASSIGN-REQCiphering Algorithm parameter received from GMM.

Output max. 1 600octets


UncipheredFrame

max. 1 600octets

A LLC frame to be ciphered.

CipheredFrame

max. 1 600octets

A ciphered LLC frame. Only the information field and the FCS field shall beciphered. Ciphered Frame shall be generated by bitwise XOR of Output and theInformation Field and FCS Field of Unciphered Frame.

DecipheredFrame

max. 1 600octets

A deciphered LLC frame. Deciphered Frame shall be generated by bitwise XOR ofOutput and the ciphered part of Ciphered Frame. When transmitting a LLC frame,Deciphered Frame shall be identical to Unciphered Frame if no transmission errorshave occurred.


A.2.1 Generation of InputThe Input parameter shall be generated according to the following algorithm:

Input = ( ( RV + LFN + OC ) modulo 232 ) ⊗ SX

where:

- RV is a binary random value that is set equal to the 32 least significant bits of RAND. RAND is received fromGMM in the LLGMM-ASSIGN-REQ primitive.

15

- LFN is the LLC frame number in the LLC frame header. LFN is a binary value with a length of six bits. For Iframes and I+S frames, N(S) shall be used as the LFN. For UI frames, N(U) shall be used as the LFN.

- OC is a binary overflow counter that is calculated and maintained independently at the sending and receivingsides. The length of OC is 32 bits. There are two OC counters associated with each DLCI; one forunacknowledged information transfer, and one for acknowledged information transfer. OC for unacknowledgedinformation transfer shall be set to zero whenever ADM state is entered. OC for acknowledged operation shall beset to zero whenever ABM operation is (re-)established. OC shall be incremented by 64 every time when thecorresponding LFN rolls over, i.e., when LFN exhausts its modulo and restarts counting from zero, so that OCand LFN when added together in effect is a 32 bit modulo 232 counter.

- SX is a 32 bit SAPI XOR mask. The 28 least significant bits shall be set to zero. The four most-significant bitsshall be set according to the SAPI of the LLC frame.

- + is the binary addition operation.

- ⊗ is the bitwise XOR operation.

B.2 An overview of the peer-to-peer LLC layer statesThe state diagram representation of the peer-to-peer procedures is based on an expansion of the three basic statesidentified in subclause 4.5.2 to 7 states. An overview of the inter-relationship of these states is provided in Figure B-2.

A LLME and its LLEs are conceptually initiated in the TLLI Unassigned state (state 1). LLME interacts with GMM inorder to be assigned a TLLI value. TLLI assignment causes LLME to transition to the TLLI Assigned state (state 2) andeach of its LLEs to transition to the ADM state (state 2).

The receipt of a LL-ESTABLISH-REQ primitive by a LLE in the ADM state (state 2) causes the initiation of the localestablishment procedure and the transition to the Local Establishment state (state 3). Completion of the establishmentprocedure takes the LLE to the ABM state (state 5).

Peer-initiated establishment causes a transition from the ADM state (state 2) to the Remote Establishment state (state 4).The receipt of a LL-ESTABLISH-RES primitive completes the establishment procedure and moves the LLE to theABM state (state 5). In ABM state (state 5), LL-DATA-REQ primitives can be serviced directly subject to therestrictions of the procedures.

Expiry of timer T200, that is used in both the flow control and data transfer aspects of each LLE’s procedures initiatesthe transition to the Timer Recovery state (state 7). Completion of the timer recovery procedures returns the LLE to theABM state (state 5). In states 5 and 7, the following conditions that are identified within the LLC specification areobserved:

- peer receiver busy;

- SACK or NACK exception; and

- own receiver busy.

A peer-initiated release takes the LLE directly to the ADM state (state 2), whilst a LL-RELEASE-REQ returns the LLEstate to the ADM state via the Local Release state (state 6).

TLLI Unassignment causes a transition to the TLLI Unassigned state (state 1) from any other state (states 2-7).

In addition, all states should observe the suspended operation (reception of LLGMM-SUSPEND-REQ) restrictions,during which LLC frames may not be transmitted.

16

Completionof Timer

Recovery

ReleaseConfirm

TLLIUnassignment

EstablishConfirm

SGSN only:Reception of

XID or UI framewith SAPI=1

TLLIAssignment

EstablishRequest

EstablishIndication

ReleaseRequest

T200Expiry

T200 ExpiryN200 Times

1TLLI

Unassigned

2TLLI Assigned

/ ADM

7Timer

Recovery

3Local

Establishment

6Local

Release

5ABM

ReleaseIndication

Any State

Per TLLI

Per DLCI

4Remote

Establishment

EstablishResponse

ReleaseIndication

Figure B-2: Overview of the states of the peer-to-peer procedures











Subject: Maximum number of octets in an information field, N201


Reason for change:

The maximum number of octets in an information field has been for further study pending further work on the Gbinterface specifications. Since the GSM 08.16 and 08.18 specification work is coming to an end, it is time to select themaximum value for N201. The maximum value for N201 has an upper boundary given by Frame Relay, 08.16 overhead,08.18 overhead, and 04.64 overhead, and a lower boundary given by the maximum N-PDU length and 04.65 overhead.

The upper boundary is calculated as follows: Frame relay payload (1 600 octets) minus worst-case 08.16 overhead(4 octets) minus worst-case 08.18 overhead (39 octets) minus worst-case 04.64 overhead (10 octets). This gives1 547 octets.

The lower boundary is given by the maximum N-PDU length (1 500 octets (this assumes that it shall be possible toavoid segmentation of maximum-length incompressible N-PDUs)) plus worst-case 04.65 overhead (5 octets). This gives1 505 octets.

This means that the maximum value for N201 must be in the range 1 505 through 1 547 octets. When selecting thevalue, the following should be taken into consideration:

- The value should be as large as possible to minimise the probability of SNDCP segmentation if the maximum N-PDU length is expanded beyond 1 500 octets in later versions of the GPRS specifications.

- The value should allow some leeway for additional overhead octets in the various protocols.

- It is more probable that overhead octets will be added to the Gb protocols than to LLC and SNDCP because thelatter protocols' overhead octets are transmitted across the radio interface.

In light of the above, it is suggested that the maximum value for N201 is set to 1 520 octets.


6.5.1.6, 8.9.4, 8.9.5, and A.2.



See GSM 10.60.

Affects MS Test Specifications [ ] BSS Test Specifications [ ] O&M Specifications [ ]

2

(possibly):Attached CRs?:




Other comments:










2

1

Octet8 7 6 5 4 3 2 1

Length

Bit

XL

Length

Parameter Type

High-order octet

Low-order octet

…

n

…

2 or 3

X X



3





0 1 0000bbbb 0-15 - down



1 - 4 095 0.1 seconds up


2 1 0000bbbb 1 - 15 - down



500 -1 5200

octets down









N201, kD, and kU can be negotiated to any value in Range in ADM. In ABM, N201, kD, and kU can only be negotiatedto the same or higher value as previously used.








11 QoS4 120 s 3 1 60520 2 2NOTE 1: The proper operation of the procedure requires that timer T200 be greater than the maximum time between

transmission of command frames and the reception of their corresponding response or acknowledgementframes.

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

4






- Output.

The relationship between the input and output parameters and the ciphering algorithm is illustrated in Figure A.1.


Input

Output

Direction

UncipheredFrame




Input

Output

Direction

Figure A.1: GPRS ciphering environment

The input and output parameters and the other elements from Figure A.1 are defined in Table A.1.

Table A.1: Ciphering parameters and frames

Parameter Length DescriptionKc 64 bits The GMM-ASSIGN-REQ Kc parameter received from GMM.Input 32 bits A modulo counter as defined in subclause A.2.1.Direction 1 bit Set to 0 if the direction of LLC frame transmission is from the MS to the SGSN.


- A GPRS ciphering algorithm as determined by the GMM-ASSIGN-REQ CipheringAlgorithm parameter received from GMM.

Output maximum.1 523600 octets


UncipheredFrame

maximum.1 523600 octets

A LLC frame to be ciphered.

CipheredFrame


A ciphered LLC frame. Only the information field and the FCS field shall beciphered. Ciphered Frame shall be generated by bitwise XOR of Output and theInformation Field and FCS Field of Unciphered Frame.

DecipheredFrame


A deciphered LLC frame. Deciphered Frame shall be generated by bitwise XOR ofOutput and the ciphered part of Ciphered Frame. When transmitting a LLC frame,Deciphered Frame shall be identical to Unciphered Frame if no transmission errorshave occurred.












Subject: Removal of the length indicator field


Reason for change:

The need for the LLC length indicator field is for further study pending further work on the RLC/MAC protocolspecifications. The GSM 04.60 work has now advanced far enough to be able to conclude on this issue.

RLC contains its own length indicator field. This field allows RLC to detect where an LLC frame ends, and wheresubsequent LLC frames start, within an RLC block. RLC procedures segment and reassemble LLC frames by using theRLC length indicator.

It is therefore not necessary to explicitly indicate the length of the LLC information field in each LLC frame. Instead, theRLC segmentation, reassembly, and delimitation procedures should be trusted. Errors not detected by RLC, whichoperates with a 16-bit CRC or a 40-bit fire code, will in most cases be detected by the LLC 24-bit CRC.

Removal of the LLC length indicator field reduces the overhead in each LLC frame with up to two octets.


4.2.1, 5.1, 5.4, 5.5, 5.9, and 6.4.



See GSM 10.60.

Affects(possibly):


Attached CRs?:




Other comments:

2

4.2.1 Services required by the lower layers

LLC requires the following services from the layers below:

- in-order delivery of LLC PDUs per DLCI;

- LLC PDU delimitation to allow the LLC layer to determine the first octet and the last octet in each LLC PDU[FFS: According to TDoc SMG2/3 WPA 97A119 "GPRS RLC/MAC Block Formats (6)" subclause 2.1.4, RLCcan detect the end of a LLC frame. This probably means that RLC/MAC does not deliver octets subsequent to theFCS field, and, if so, there is no need for the Length field in the LLC header.. This point will be left FFS until thework on RLC/MAC is drawn to a conclusion]; and

- transport of the MS address (a TLLI) of each LLC PDU between the MS and the SGSN.

5.1 GeneralAll logical link control layer peer-to-peer exchanges shall be in frames conforming to the format shown in Figure 1. Theframe header shall consist of the address, and control, and length indicator fields, and is a minimum of 23 octets and amaximum of 79 octets long.

8 7 6 5 4 3 2 1Address Field (1 octet)

Control Field(1, 2, or 6 octets)

Length Indicator Field(0, 1, or 2 octets)

Information Field(variable length, max. N201 octets)

Frame Check Sequence Field(3 octets)

Figure 1: LLC frame format

5.4 Length indicator fieldThe length indicator field may consist of a variable number of octets. The format of the field is defined in subclause 6.4.It indicates the length of the information field to follow.

5.45 Information fieldThe information field of a frame, when present, follows the controllength indicator field (see subclause 5.4 above). Themaximum number of octets in the information field (N201) is defined in subclause 8.9.4.

5.89 Invalid framesAn invalid frame is a frame that:

- contains fewer octets than necessary to include the address field, control field, length indicator field, informationfield, and FCS field necessary to constitute a complete frame according to the contents of the control field andthe length indicator field;

- has the PD bit set to 1;

3

- contains a reserved SAPI; or

- contains a FCS error.

An invalid frame shall be discarded without notification to the sender. No action shall be taken as the result of thatframe.

6.4 Length indicator fieldA length indicator field shall be present in all frames that contain an information field. The format of the length indicatorfield is shown in Figure 2.

The length indicator field extension bit, EL, enables extension of the field to span more than one octet.

n

1

Octet8 7 6 5 4 3 2 1

L

Bit

EL

LEL

Figure 2: Length indicator field format

The field consists of the field extension bit, EL, and the length indicator, L.

6.4.1 Length indicator field extension bit (EL)

The length indicator field is extended by reserving bit 8 to indicate the final octet of the field. Presence of a 1 in bit 8signals that it is the final octet of the field.

6.4.2 Length indicator (L)

The length indicator consists of 7 bits or 14 bits and is used to indicate the number of octets contained in the informationfield of I, UI, SABM, UA, or XID frames, i.e., any value from 0 to N201 inclusive.

The length indicator field shall not be present in frames that cannot contain an information field. A one-octet lengthindicator field shall be used in frames containing information fields between L = 0 and L = 127 octets. A two-octetlength indicator field shall be used in frames containing information fields between L = 128 and L = N201 octets.

Documents

ETSI TC SMG TDoc SMG 938/97 Madrid, Spain Agenda item · PDF fileCR # Rev Title Description SMG3 A SMG3 Pl SMG#24 ... Figure 1 in subclause 4.1 contains an incorrect reference to Frame