8 Evolution of Iu UP Protocol

25.4153GPPRelease 17TSUTRAN Iu interface user plane protocols

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

8.1 Principles for Protocol Evolution

8.1.1 Unknown field value

The Iu UP protocol may be evolved by taking into use field values that have been specified to be reserved for future use or have been specified as spare values. When a UP protocol entity receives an unknown field value, it can react differently depending whether the unknown value is reserved for future use or if it is a spare value. The following principles are recommended for receiver reactions:

– If a spare value is used by the sender, but not understood by the receiver, there should be a default action for the receiver. This default action should be defined on a field basis;

– If a value that is reserved for future use is used by the sender, but not understood by the receiver, the value should be rejected by the receiver. This should be done by sending a Negative Acknowledgement to the peer entity, if possible. Otherwise an Error Event should be generated in order to inform the upper layers and the peer entity;

– A received ERROR EVENT control frame shall not trigger another ERROR EVENT control frame back to the sender, even though e.g. the Cause value in the received ERROR EVENT control frame would not be understood.

In the following the recommended actions of the receiver are handled field by field when an unknown field value is received.

PDU Type

Recommended action if reserved values used: Generate Error Event, i.e. the upper layers and the peer entity are informed about the error event with Cause: "PDU type unknown".

FQC

Recommended action if spare values used: Ignore the field and pass it onwards.

ACK/NACK

Proposed action if reserved values used: Generate an Error Event, i.e. the upper layers and the peer entity are informed about the error event with Cause: "Unknown reserved value".

Procedure Indicator

Recommended action if reserved values used: Generate an Error Event, i.e. the upper layers and the peer entity are informed about the error event with Cause: "Unknown procedure".

Error Cause value

Value "49" is reserved for "Iu UP Mode version not supported" whatever the Iu UP Mode version.

Recommended action if reserved values used: Generate Error Event, i.e. the upper layers and the peer entity are informed about the error event with Cause: "Unknown reserved value".

Recommended action if spare values used: Ignore the field and pass it onwards.

8.1.2 Adding a new field to an existing frame

If there is a need to add a new field to an existing procedure, the following principles shall be applied:

– The PDU type defines the header mask. Therefore, a new field shall not be added to the header part of an existing frame and possible spare bits in the header shall not be taken into use since these would be violations of the header mask;

– The Procedure Indicator shall define the fields that should be in a control frame;

– There shall be only one Procedure Indicator for each procedure;

– If a new field needs to be introduced to an existing procedure (i.e. existing procedure that is defined in an existing UP version), the new field shall not be added to the payload part. Instead, the new field may be introduced by placing it to a spare field in the payload part of the frame, if possible;

– However, if a new field needs to be introduced to an existing procedure, but spare fields(s) in the payload part cannot be used to introduce the new field, then a new procedure shall be created and hence a new Procedure Indicator value shall be allocated for the new procedure;

– To enable simple protocol evolution, when a new Procedure Indicator will be introduced, the new frame shall include both the new fields and the fields of the old frame;

– When an implementation receives an unknown Procedure Indicator it may use the ERROR EVENT control frame with Cause: "Unknown procedure" to report this. This indicates to the sender that the procedure was not understood and it may try with an older procedure.

8.1.3 Adding a new PDU type

In the future, the Iu UP protocol may evolve so that there is a need to add a new PDU type. The criteria for introducing a new PDU type could be e.g.:

– The Procedure Indicators may run out and there is a need to have more;

– There is a need to change the header mask, e.g. the Frame Number field may need to be increased or the CRC field needs to be modified.

While the PDU Type 15 is reserved for future PDU type extensions, there may be ‘subtypes’ under PDU Type 15 in the future and there also may be new procedures in these ‘subtypes’.

Thus it has to be ensured that if the same Procedure Indicator value is used under several PDU types, it should be made clear e.g. in the Error Event cause element, which PDU type it concerns.

The maximum length of the Spare Extension field is defined per PDU type. Thus when a new PDU type is added, an appropriate length for the Spare Extension field (if any) has to be defined. For Release ’99, a length of 4 octets has been used for data PDUs, and 32 octets for control PDUs.

8.1.4 Protocol version handling

In the future, new versions of the Iu UP protocol may be introduced. A reason for a new version of the protocol could be, e.g.:

– The earlier introduced new features or functions are required to be mandatory in the new version;

– Due to technical development, the new version of the protocol could be totally different (and incompatible) from the earlier version.

The following principles shall be applied to version handling of Iu UP protocol:

– It shall be possible to introduce additional modes of operation;

– It shall be possible to evolve the operation modes independently of each other;

– There shall be independent version numbers for each mode of operation;

– The mode of operation of an Iu UP protocol instance is decided by the CN. Further, the CN shall indicate those versions that are required to support certain features, e.g. TrFO. The version of the mode among the required ones shall be negotiated between the CN and UTRAN during Initialisation procedure;

– The version number of a UP operation mode may change or be unchanged between different releases;

– When the protocol is evolved it shall be made clear in the specification, which features belong to which versions;

– A new version may be an evolution (i.e. compatible) of the old version or the new version may be totally different from the old version.

– The structure of the PDU Type 14 header, up to and including header CRC, shall remain unchanged whatever the Iu UP version.

Annex A (informative):
Illustration of usage of RFCI for AMR speech RAB

This annex contains information related to usage of RFCIs in the context of AMR speech RAB.

The following figure illustrates the RFCI allocation and flow throughout the UTRAN.

1. RAB Attributes: at RAB establishment or reconfiguration, the SDU format information parameter is passed to UTRAN. The SDU information is organised per BER i.e. RAB sub Flow. For instance, 12,2 kbits/s AMR codec is passed as RAB sub flow 1 SDU size: 81 bits –class A bits-, as RAB sub flow 2 SDU size: 103 bits –class B bits-, as RAB sub flow 3 SDU size: 60 bits –class C-, which makes one RAB sub Flow Combination. This is done for all source rates (i.e. all codec modes, DTX also if included). So using the RAB subflows combination set from Table A.1, the SDU Formation Information Parameters for RAB subflow 1 is [81,42,39,0], for RAB subflow 2 is [103,53,0,0], and for RAB subflow 3 is [60,0,0,0]. The Iu UP is used in support mode for predefined SDU size.

2. Allocation of RFCIs: the RNC dynamically allocates an identification (RFCI) to each permitted/possible combinations it can offer. E.g. for 0 kbits/s, the RNC allocates RFCI 0, for the SID, the RNC allocates RFCI 3, for 4,75 kbits/s, the RNC allocates RFCI 2, and for 12,2. kbits/s, the RNC allocates RFCI 1 (according to the example table A.1).

3. Configuration of L2/L3 based on RFCIs: RFCIs are used to configure the L2/L3. RLC (TS 25.322 [11]) is used in transparent mode. MAC (TS 25.321 [10]) configures its co-ordinated DCHs with the RFCIs and associates one RFCI to one TFI.

4. Initialisation of Iu UP: the RNC reports the permitted combinations it can offer to the transcoder using an inband Iu INITIALISATION control frame containing the RFCIs and associated RAB sub Flow sizes.

5. Configuration of L2/L3 based on e.g. TFIs: idem as 3. L2/L3 may use e.g. TFI to communicate with the Codec about the RAB sub-Flow structure of the SDU received or to be sent.

6. RFCIs+ SDU size information: the RFCIs and associated RAB sub Flow sizes received within the Iu INITIALISATION control frame are passed to the Codec for configuration.

7. Example of DL frame transfer:

7.1. The Codec encodes a 12,2 kbits/s frame. It sends down to the Iu UP an SDU with an associated RFCI equals to 1 (in this example).

7.2. The Iu UP packs a frame with a header containing an RFCI set to value "1", and the payload made of the SDU received from the Codec.

7.3. The Iu UP passes to L2/L3, the Iu frame payload (the Codec SDU) and the RFCI. The L2/L3 uses this RFCI to break the Iu frame onto the co-ordinated DCHs corresponding to the different bits protection classes. The corresponding TFI is selected.

7.4. The radio frame is sent with the TFCI chosen by MAC (TS 25.321 [10]).

7.5. The L2/L3 receives the SDUs on the co-ordinated DCHs, combines them back and uses e.g. the TFI to indicate to the codec the structure of the received frame.

Figure A.1

For information on RAB subflow combinations used for AMR speech see TS 26.102 [12].

SRNC allocates one or more possible/available RAB sub-flow combination(s) and generates RAB sub-flow combination set. RAB sub-flow combination number is dynamically generated by SRNC. This RAB sub-flow combination set is signalled towards CN with user plane signalling as described in TS 25.401 [1]. The signalling towards UE is to be defined by TSG-RAN WG2.

RAB sub-flow combination set:

A RAB sub-flow combination indicator, RFCI, indicates which RAB sub flow combination will be used for the Iu user frames. In the communication phase the RFCI is included in the user frame, and the RFCI state the structure of the user frame.

Table A.1 exemplifies the allocation of 4 different RAB sub-flows combinations for 3 sub-flows and generating of RAB sub-flows combination set.

Table A.1: Example of Allocation of RAB sub-flows combination indicator

	RFCI (RAB sub-Flow Combination Indicator)	RAB sub- Flow 1	RAB sub- flow 2	RAB sub- flow 3	Total	Source rate
RAB sub-flows combination set	1	81	103	60	244	Source rate 1
	2	42	53	0	95	Source rate 2
	3	39	0	0	39	Source rate 3
	0	0	0	0	0	Source rate 4
NOTE: In the table above the greyed area shows the part that is sent in the Initialisation procedure in Iu UP. This is what constitutes the RAB subflow combination set.

Annex B (informative):
Illustration of protocol states in the Iu UP

This annex contains information related to possible protocol states for operation of the Iu UP. This annex does not constraint implementation and is for illustration purposes only.

The state model is common for both ends of the Iu UP so that the protocol machines are operating symmetrically. This approach is taken to facilitate state description for all cases including possible future scenarios where the Iu UP could be terminated elsewhere.

NOTE: Primitive Iu-UP-CONFIG-Req is used by upper layers to configure the Iu UP protocol layer. It is used in this annex for illustrative purposes and therefore it is not defined in clause 7.