6.6 Elements for Iu UP communication in Support mode

25.4153GPPRelease 17TSUTRAN Iu interface user plane protocols

6.6.1 General

In the present document the structure of frames will be specified by using figures similar to figure 18.

Bits

Number of Octets

7

6

5

4

3

2

1

0

Field 1

Field 2

1

Octet 1

Header part

Field 3

Field 4

2

Octet 2

Field 4 continue

Spare

Octet 3

Field 6

2

Octet 4

Octet 5

Payload part

Field 6 continue

Padding

Spare extension

0-m

Figure 18: Example frame format

Unless otherwise indicated, fields which consist of multiple bits within an octet will have the more significant bit located at the higher bit position (indicated above frame in figure 18). In addition, if a field spans several octets, more significant bits will be located in lower numbered octets (right of frame in figure 18).

On the Iu interface, the frame will be transmitted starting from the lowest numbered octet. Within each octet, the bits are sent according decreasing bit position (bit position 7 first).

Spare bits should be set to "0" by the sender and should not be checked by the receiver.

The header part of the frame is always an integer number of octets. The payload part is octet rounded (by adding ‘Padding’ when needed).

The receiver should be able to remove an additional spare extension field that may be present at the end of a frame. See description of Spare extension field.

6.6.2 Frame Format for predefined size SDUs

6.6.2.1 PDU Type 0

PDU Type 0 is defined to transfer user data over the Iu UP in support mode for pre-defined SDU sizes. Error detection scheme is provided over the Iu UP for the payload part.

The following shows the Iu frame structure for PDU TYPE 0 data frame of the Iu UP protocol at the SAP towards the transport layers (TNL-SAP).

Bits

Number of Octets

7

6

5

4

3

2

1

0

PDU Type (=0)

Frame Number

1

Frame Control Part

FQC

RFCI

1

Header CRC

Payload CRC

2

Frame Check Sum Part

Payload CRC

Payload Fields

0–n

Frame Payload part

Payload Fields

Padding

Spare extension

0-4

Figure 19: Iu UP PDU Type 0 Format

The Iu UP PDU TYPE 0 data frame is made of three parts:

1) Iu UP Frame Control part (fixed size);

2) Iu UP Frame Check Sum part (fixed size);

3) Iu UP Frame Payload part (pre-defined SDU sizes rounded up to octets [Note: this does not consider the usage of spare extension field]).

The Iu UP Frame Control Part and the Iu UP Frame Check Sum Part constitute the Iu UP PDU Type 0 Frame Header.

6.6.2.2 PDU Type 1

PDU Type 1 is defined to transfer user data over the Iu UP in support mode for pre-defined SDU sizes when no payload error detection scheme is necessary over Iu UP (i.e. no payload CRC).

The following shows the Iu frame structure for PDU TYPE 1 data frame of the Iu UP protocol at the SAP towards the transport layers (TNL-SAP).

Bits

Number of Octets

7

6

5

4

3

2

1

0

PDU Type (=1)

Frame Number

1

Frame Control Part

FQC

RFCI

1

Header CRC

Spare

1

Frame Check Sum Part

Payload Fields

0-n

Frame Payload part

Payload Fields

Padding

Spare extension

0-4

Figure 20: Iu UP PDU Type 1 Format

The Iu UP PDU TYPE 1 data frame is made of three parts:

1) Iu UP Frame Control part (fixed size);

2) Iu UP Frame Check Sum part (fixed size);

3) Iu UP Frame Payload part (pre-defined SDU sizes, rounded up to octets [Note: this does not consider the usage of spare extension field]).

The Iu UP Frame Control Part and the Iu UP Frame Check Sum Part constitute the Iu UP PDU Type 1 Frame Header.

6.6.2.3 PDU Type 14

6.6.2.3.1 General

PDU Type 14 is defined to perform control procedures over the Iu UP in support mode for pre-defined SDU sizes. The control procedure is identified by the procedure indicator. The Frame Payload contains the data information related to the control procedure.

Figure 21 shows the Iu frame structure for PDU Type 14 of the Iu UP protocol at the SAP towards the transport layers (TNL-SAP).

Bits

Number of Octets

7

6

5

4

3

2

1

0

PDU Type (=14)

Ack/Nack (=0, i.e. procedure)

PDU Type 14 Frame Number

1

Frame Control Part

Iu UP Mode version

Procedure Indicator

1

Header CRC

Payload CRC

1

Frame Checksum Part

Payload CRC

1

Reserved for procedure data

0-n

Frame payload part

Spare extension

0-32

Figure 21: Iu UP PDU Type 14 Format for procedure sending

The Iu UP PDU Type 14 is made of three parts:

1) Iu UP Frame Control part (fixed size);

2) Iu UP Frame Check Sum part (fixed size);

3) Iu UP Frame Payload part (variable length, rounded up to octet).

The Iu UP Frame Control Part and the Iu UP Frame Check Sum Part constitute the Iu UP PDU Type 14 Frame Header.

6.6.2.3.2 Positive Acknowledgement

When the PDU Type 14 is used to positively acknowledge a control procedure, the PDU Type 14 frame takes the following structure at the TNL-SAP.

Bits

Number of Octets

7

6

5

4

3

2

1

0

PDU Type (=14)

Ack/Nack (=1, i.e. Ack)

PDU Type 14 Frame Number

1

Frame Control Part

Iu UP Mode version

Procedure Indicator

(indicating the procedure being positively acknowledged)

1

Header CRC

Spare

1

Frame Checksum Part

Spare

1

Spare extension

0-32

Frame Payload part

Figure 22: Iu UP PDU Type 14 Format for positive acknowledgement

The Iu UP Frame Control Part and the Iu UP Frame Check Sum Part constitute the Iu UP PDU Type 14 Frame Header for positive acknowledgement.

6.6.2.3.3 Negative Acknowledgement

When the PDU Type 14 is used to negatively acknowledge a control procedure, the PDU Type 14 frame takes the following structure at the TNL-SAP.

Bits

Number of Octets

7

6

5

4

3

2

1

0

PDU Type (=14)

Ack/Nack (=2, i.e. Nack)

PDU Type 14 Frame Number

1

Frame Control Part

Iu UP Mode version

Procedure Indicator

(indicating the procedure being negatively acknowledged)

1

Header CRC

Spare

1

Frame Checksum Part

Spare

1

Error Cause value

Spare

1

Frame payload part

Spare extension

0-32

Figure 23: Iu UP PDU Type 14 Format for negative acknowledgement

The Iu UP Frame Control Part and the Iu UP Frame Check Sum Part constitute the Iu UP PDU Type 14 Frame Header for negative acknowledgement.

6.6.2.3.4 Procedures Coding

6.6.2.3.4.1 Initialisation

Figure 24 specifies how the INITIALISATION control frame is coded.

Bits

Number of Octets

7

6

5

4

3

2

1

0

PDU Type (=14)

Ack/Nack (=0. I.e. Procedure)

PDU Type 14 Frame Number

1

Frame Control Part

Iu UP Mode version

Procedure Indicator (=0)

1

Header CRC

Payload CRC

2

Frame Checksum part

Payload CRC

Spare

TI

Number of subflows per RFCI (N)

Chain Ind

1

Frame payload part

LRI

LI

1st RFCI

1

Length of subflow 1

1 or 2 (dep. LI)

Length of subflow 2 to N

(N-1)x(1 or 2)

LRI

LI

2nd RFCI

1

Length of subflow 1

1 or 2 (dep. LI)

Length of subflow 2 to N

(N-1)x(1 or 2)

…

IPTI of 1st RFCI

…

0 or M/2 (M: Number of RFCIs in frame). Ended by 4 padding bits if M is odd.

…

IPTI of Mth RFCI or Padding

Iu UP Mode Versions supported (bitmap)

2

Data PDU type

Spare

1

Spare extension

0-32

Figure 24: Iu UP PDU Type 14 used for Initialisation

6.6.2.3.4.2 Rate Control

6.6.2.3.4.2.1 Rate Control procedure

Figure 25 specifies how the RATE CONTROL control frame is coded.

Bits

Number of Octets

7

6

5

4

3

2

1

0

PDU Type (=14)

Ack/Nack (=0, i.e. Procedure)

PDU Type 14 Frame Number

1

Frame Control Part

Iu UP Mode version

Procedure Indicator (=1)

1

Header CRC

Payload CRC

1

Frame Checksum Part

Payload CRC

1

Spare

Number of RFCI Indicators (P)

1

Frame payload part

RFCI 0 Ind.

RFCI 1 Ind

…

RFCI P-1 Ind

Padding

0–n

Spare extension

0-32

Figure 25: Iu UP PDU Type 14 Format used for Rate Control

6.6.2.3.4.2.2 Rate Control positive acknowledgement

Figure 25a specifies how the RATE CONTROL POSITIVE ACKNOWLEDGEMENT control frame is coded.

Bits

Number of Octets

7

6

5

4

3

2

1

0

PDU Type (=14)

Ack/Nack (=1, i.e. Ack)

PDU Type 14 Frame Number

1

Frame Control Part

Iu UP Mode version

Procedure Indicator

(indicating the procedure being positively acknowledged)

1

Header CRC

Spare

1

Frame Checksum Part

Spare

1

Spare

Number of RFCI Indicators (P)

1

Frame Payload part

RFCI 0 Ind.

RFCI 1 Ind

…

RFCI P-1 Ind

Padding

0-n

Spare extension

0 –

(31-n)

Figure 25a: Iu UP PDU Type 14 Format for positive acknowledgement

6.6.2.3.4.3 Time Alignment

Figure 26 specifies how the TIME ALIGNMENT control frame is coded.

Bits

Number of Octets

7

6

5

4

3

2

1

0

PDU Type (=14)

Ack/Nack(=0)

PDU Type 14 Frame Number

1

Frame Control Part

Iu UP Mode version

Procedure Indicator (=2)

1

Header CRC

Payload CRC

1

Frame Checksum Part

Payload CRC

1

Time alignment

1

Frame payload part

Spare extension

0-32

Figure 26: Iu UP PDU Type 14 Format used for Time Alignment

6.6.2.3.4.4 Error Event

Figure 27 specifies how the ERROR EVENT control frame is coded.

Bits

Number of Octets

7

6

5

4

3

2

1

0

PDU Type (=14)

Ack/Nack(=0)

PDU Type 14 Frame Number

1

Frame Control Part

Iu UP Mode version

Procedure Indicator (=3)

1

Header CRC

Payload CRC

1

Frame Checksum Part

Payload CRC

1

Error distance

Error Cause value

1

Frame payload part

Spare extension

0-32

Figure 27: Iu UP PDU Type 14 Format used for Error Event

6.6.3 Coding of information elements in frames

6.6.3.1 PDU Type

Description: The PDU type indicates the structure of the Iu UP frame. The field takes the value of the PDU Type it identifies: i.e. "0" for PDU Type 0. The PDU type is in bit 4 to bit 7 in the first octet of the frame. PDU type is used in all frames in support mode for predefined SDU sizes.

Value range: {0-1 and 14 in use, 2-13: reserved for future PDU types, 15=reserved for future PDU type extensions}

Field length: 4 bits

6.6.3.2 Ack/Nack

Description: The Ack/Nack field tells if the frame is:

– A control procedure frame;

– A positive acknowledgement (ACK) of a control procedure frame;

– A negative acknowledgement (NACK) of a control procedure frame.

Value range: {0=control procedure frame, 1=ACK, 2=NACK, 3=reserved}

Field length: 2 bits

6.6.3.3 Frame Number

Description: The Iu UP frame numbering is handled by a Frame Number. The frame numbering can be based on either time or sent Iu UP PDU. In case the frame numbering is based on time the purpose of the frame number is to be of help in handling the Time Alignment functionality. When the frame number is based on time, the Frame number set in the PDU header is incremented by one (modulo 16) at each new ITI. The Frame number set in the PDU header shall be based on the timing of the source. The source is where the original payload was created. Two packets that were consecutive at the source shall not have the same frame number assigned. In case the Frame number relates to sent Iu UP PDU the purpose of the Frame Number is to provide the receiving entity with a mechanism to keep track of lost Iu UP frames. When the frame number is based on sent Iu UP PDU, the Frame number is incremented by one (modulo 16) for each sent Iu UP PDU. For a given user data connection, there is no relations between the frame numbers of frames sent in the downlink direction and the frame numbers of frames sent in the uplink direction.

In the case the Frame Number relates to sent Iu UP PDU, the following applies:

– Frame loss is when an incoming PDU frame has a frame number that is equal to (previous PDU frame number + 2) modulo [max. PDU frame number + 1]. This indicates that one and only one PDU frame has been lost.

– Unexpected frame number is when an incoming PDU does not have the expected frame number and is not considered as a Frame Loss.

Value range: {0-15}.

Field length: 4 bits.

6.6.3.4 PDU Type 14 Frame Number

Description: The Iu UP frame numbering is handled by a Frame Number. The purpose of the PDU Type 14 Frame Number is to provide the receiving entity with a mechanism to keep track of lost Iu UP frames. The PDU Type 14 Frame Number shall be managed as one single counter for all control procedure functions of a RAB. The sender shall increment this number by one (modulo 4) for each sent Iu UP Type 14 PDU starting with value 0 for the first PDU Type 14 INITIALISATION control frame sent out of the initialisation procedure. The counter shall be reset to 0 in case a new initialisation takes place. It is also used to relate the acknowledgment frame to the frame being acknowledged i.e. the same PDU Type 14 Frame Number is used in the positive or negative acknowledgement frame as the one used in the frame being acknowledged.

The PDU Type 14 Frame Number shall be handled independently per direction, i.e. control frames other than acknowledgment frames shall be numbered independently per direction.

The following applies for PDU Type14 Frame Number:

– Frame loss is when an incoming PDU frame has a frame number that is equal to (previous PDU frame number + 2) modulo [max. PDU frame number + 1]. This indicates that one and only one PDU frame has been lost.

– Unexpected frame number is when an incoming PDU does not have the expected frame number and is not considered as a Frame Loss.

Upon detection of frame loss or unexpected PDU Type 14 Frame Number in a procedure other than initialisation, the receiving entity shall still consider the frame as valid and handle it normally e.g. treat it and send an acknowledgement frame when appropriate.

Value range: {0-3}.

Field length: 2 bits.

6.6.3.5 Frame Quality Classification (FQC)

Description: Frame Quality Classification is used to classify the Iu UP frames depending on whether errors have occurred in the frame or not. Frame Quality Classification is dependent on the RAB attribute Delivery of erroneous SDU IE.

Value range: {0=frame good, 1=frame bad, 2=frame bad due to radio, 3=spare}.

Field length: 2 bits.

6.6.3.6 RAB sub-Flow Combination Indicator (RFCI)

Description: The RFCI identifies the structure of the payload. This can be used to specify the sizes of the subflows.

Value range: {0-62, 63=RFCI not applicable}.

Field length: 6 bits.

6.6.3.7 Procedure Indicator

Description: The Procedure Indicator identifies the control procedure in the current frame.

Value range: {0=initialisation, 1=rate control, 2=time alignment, 3=error event, 4-15=reserved}.

Field length: 4 bits.

6.6.3.8 Header CRC

Description: This field contains the CRC of all fields in Frame Control Part. The CRC is a 6-bit checksum based on the generator polynom G(D) = D6+D5+D3+D2+D1+1, see subclause 6.7.7. With this CRC all error bursts shorter than 7 bits are detected, as well as all odd number of bits faulty (and two-bit faults) when the protected area is shorter than 24 bits, (max 3 octets).

Field length: 6 bits.

6.6.3.9 Payload CRC

Description: This field contains the CRC of all the fields (including Padding and possible Spare extension) of the Frame Payload Part. The CRC is a 10 bit checksum based on the generator polynom G(D) = D10+ D9+D5+D4+D1+1, see subclause 6.7.7. With this CRC all error bursts shorter than 11 bits are detected, as well as all odd number of bits faulty (and two-bit faults) when the protected area is shorter than 500 bits (max 62 octets).

Field length: 10 bits.

6.6.3.10 Chain Indicator

Description: Chain indicator is used to indicate whether the control procedure frame is the last frame related to the control procedure.

Value range: {0=this frame is the last frame for the procedure, 1=additional frames will be sent for the procedure}.

Field length: 1 bit.

6.6.3.11 Number of Subflows per RFCI

Description: Number of Subflows per RFCI field indicates the number of subflows the RAB is made of. It is used to decode the SDU size information data lengths. All RFCs consist of the same number of subflows within a specific RAB.

Value range: {0=reserved, 1-7}.

Field length: 3 bits.

6.6.3.12 Length Indicator (LI)

Description: Length Indicator, indicates if 1 or 2 octets is used for the RAB subflow size information.

Value range: {0=one octet used, 1=two octets used}.

Field length: 1 bit.

6.6.3.13 Number of RFCI Indicators

Description: Number of RFCI indicators indicates the number of RFCI indicators present in the control procedure frame.

Value range: {0-63}.

Field length: 6 bits.

6.6.3.14 RFCI n Indicator

Description: RFCI n Indicator indicates if the RFCI with value n is allowed or barred (n is a value between 0-62). E.g. RFCI 4 Indicator set to "0" indicates that RFCI =4 is allowed, RFCI 5 Indicator set to "1" indicates that RFCI =5 is barred, etc…

Value range: {0=RFCI allowed, 1=RFCI barred}.

Field length: 1 bit.

6.6.3.15 Error distance

Description: Indicates if the error occurred at the error reporting entity (=0) or in a more distant entity. The error distance is incremented by one (or kept at its maximum value) when an error report is forwarded.

0: Reporting local error.
1: First forwarding of error event report.
2: Second forwarding of error event report.
3: Reserved for future use.

Value range: {0: Reporting local error, 1: First forwarding of error event report. 2: Second forwarding of error event, 3: Reserved for future use}.

Field length: 2 bit.

6.6.3.16 Error Cause value

Description: Cause value is used to indicate what kind of error caused the error. Error cause value is used in NEGATIVE ACKNOWLEDGEMENT and ERROR EVENT control frames.

0: CRC error of frame header.
1: CRC error of frame payload.
2: Unexpected frame number.
3: Frame loss.
4: PDU type unknown.
5: Unknown procedure.
6: Unknown reserved value.
7: Unknown field.
8: Frame too short.
9: Missing fields.
10–15: spare.
16: Unexpected PDU type.
17: spare.
18: Unexpected procedure.
19: Unexpected RFCI.
20: Unexpected value.
21–41: spare.
42: Initialisation failure.
43: Initialisation failure (network error, timer expiry).
44: Initialisation failure (Iu UP function error, repeated NACK).
45: Rate control failure.
46: Error event failure.
47: Time Alignment not supported.
48: Requested Time Alignment not possible.
49: Iu UP Mode version not supported.
50–63: spare.

Value range: {0–15 Used for syntactical protocol errors, 16–41 Used for semantical protocol errors, 42–63 Used for other errors}.

Field length: 6 bit.

6.6.3.17 Padding

Description: This field is an additional field used to make the frame payload part an integer number of octets when needed. Padding is set to "0" by the sender and is not interpreted by the receiver.

Value range: {0–127}.

Field length: 0–7 bits.

6.6.3.18 Time alignment

Description: Time alignment indicates the amount the sending time should be advanced or delayed.

0: Reserved.
1: Delay 1*500s.
…
80: Delay 80*500s.
81–127 Reserved.
128: Reserved.
129: Advance 1*500s.
…
208: Advance 80*500s.
209–255 Reserved.

Value range: {0: Reserved, 1–80: used for delay, 81–128: Reserved, 129-208 used for advance, 209–255: Reserved}.

Field length: 8 bit.

6.6.3.19 Spare

Description: The spare field is set to "0" by the sender and should not be interpreted by the receiver.

Value range: (0–2n-1).

Field Length: n bits.

6.6.3.20 Spare extension

Description: The spare extension field shall not be sent. The receiver should be capable of receiving a spare extension. The spare extension should not be interpreted by the receiver. This since in later versions of the present document additional new fields might be added in place of the spare extension. The spare extension can be an integer number of octets carrying new fields or additional information; the maximum length of the spare extension field (m) depends on the PDU type.

Value range: 0–2m*8-1.

Field Length: 0–m octets. For PDU Types in the set {0,1}, m=4. For PDU Types in the set {14}, m=32.

6.6.3.21 LRI, Last RFCI Indicator

Description: The Last RFCI Indicator is used to indicate which is the last RFCI in the current INITIALISATION control frame. This makes it possible for a receiver to detect a spare extension field.

Value range: (0: Not last RFCI, 1: Last RFCI in current frame).

Field Length: 1 bit.

6.6.3.22 Length of subflow

Description: This field indicates the length of the corresponding subflow as number of bits per SDU.

Value range: (0–255 if LI=0, 0–65535 if LI=1).

Field Length: 8 or 16 bits (depending on LI).

6.6.3.23 TI

Description: This field indicates if Timing Information is included in the INITIALISATION control frame.

Value range: {0: IPTIs not present, 1: IPTIs present in frame}.

Field length: 1 bit.

6.6.3.24 IPTI of nth RFCI

Description: This field indicates the IPTI value in number of ITIs for the corresponding RFCI (in the same order as the RFCIs occur in the INITIALISATION control frame).

Value range: {0–15}.

Field length: 4 bits.

6.6.3.25 Iu UP Mode versions supported

Description: This field indicates the Iu UP Mode Versions proposed by the sender for the related RAB for the initialisation procedure. Up to 16 Iu UP Mode versions can be simultaneously indicated.

Value range:

Each bit, in the two octet field, indicates a Iu UP Protocol version: (First octet, bit 7) indicates version 16, (Second octet, bit 0) indicates version 1.

Bit = 0 means "Version not supported, not allowed or not proposed"

Bit = 1 means "Version supported among the required versions and proposed"

Field length: 2 octets

6.6.3.26 Iu UP Mode Version

Description: This field indicates the Iu UP Mode version used for type 14 frames. Up to 16 Iu UP Mode Versions can be available.

Value range: {1-16} The binary coded value is the version number minus 1 (e.g. version 1 is coded "0000", …, version 16 is coded "1111").

Field length: 4 bits

6.6.3.27 Payload fields

Description: This field contains the Subflow SDUs, starting with the Subflow 1 SDU. The MSB of the Subflow 1 SDU is placed in bit 7 of the first octet (see example in figure 27a).

Value range: {any value}.

Field length: Sum of the lengths of the included Subflow SDUs.

Bits

Number of Octets

7

6

5

4

3

2

1

0

Subflow 1 SDU

1

Subflow 1 SDU cont.

Subflow 2 SDU

1

Subflow 2 SDU cont.

Padding
(Not part of ‘Payload fields’)

1

Figure 27a: Example of ‘Payload fields’ with two Subflow SDUs

6.6.3.28 Data PDU type

Description: This field indicates the PDU type that shall be used (in both directions) for transferring user data.

Value range: {0: PDU type 0, 1: PDU type 1, 2–15: Reserved for future use}.

Field length: 4 bits.

6.6.4 Timers

TINIT

This Timer is used to supervise the reception of the initialisation acknowledgement frame from the peer Iu UP instance. This Timer is set by O&M.

TTA

This Timer is used to supervise the reception of the time alignment acknowledgement frame from the peer Iu UP instance. This Timer is set by O&M.

TRC

This Timer is used to supervise the reception of the rate control frame from the peer Iu UP instance. This Timer is set by O&M.

6.6.5 Maximum values of repetition counters

NINIT

Maximum number of repetitions of an INITIALISATION control frame due to failure at the Initialisation procedure.

NRC

Maximum number of repetitions of a RATE CONTROL control frame due to failure at the Rate Control procedure.

NTA

Maximum number of repetitions of a TIME ALIGNMENT control frame due to failure at the Time Alignment procedure.