A.11 Iuh Framing Protocol Interworking Function (IuhUPIF)

25.4673GPPRelease 17Stage 2TSUTRAN architecture for 3G Home Node B (HNB)

A.11.1 Introduction

The CS user plane traffic on the Iuh interface (between HNB and HNB-GW) carried using the Iu UP framing protocol as defined in the TS 25.415 [17] UTRAN Iu interface user plane protocols. The HNB Iu UP entity follows the procedures and principles defined in the Iu UP framing protocol specification (TS25.415 [17] UTRAN Iu interface user plane protocols). Most of the Iu UP PDUs will be transferred by the HNB-GW without any processing. However, the HNB-GW will perform certain functionalities that could be implemented by an IuhUPIF (Iuh user plane interworking function) in the HNB-GW as described below.

The IuhUPIF is the functional entity responsible for aligning or mapping control procedures (including RFCIs, frame numbers etc) on the separate UP interfaces. The IuhUPIF determines if the two UP configurations (at the HNB and CN) are identical and thus the UP PDUs may be passed transparently. If the IuhUPIF determines that the two UP configurations are not identical it applies the necessary mapping.

Figure A.11.1-1: The Iuh Framing Protocol Interworking Function.

A.11.2 CS User Plane handling during the Initial CS RAB setup

During the CS RAB setup, the HNB allocates the RAB Subflows combination indicator for the SDU formats (SDU formats are sent to the HNB in the RANAP RAB ASSIGNMENT message). The allocation is then sent in the Iu Framing Initialisation PDU by the HNB in the user plane. For further details see TS 25.413 [9] and TS 25.415 [17].

Upon reception of the RFCI values in the Iu UP Initialisaiton Frame (Iu UP PDU type 14 from the HNB ) during the call establishment, the HNB-GW stores “UL RFCI vector”. The first subflow of the initialisation corresponds to the Initial Rate control i.e. indicate the highest rate for the first speech mode to be used in the direction of the Initialisation acknowledgement frame. The HNB-GW forwards the Iu UP Initialisation frame towards the CN according to TS 25.415 [17] without any change to the received Iu UP PDU from the HNB. Upon reception of the Iu UP ACK/NACK PDU, the HNB-GW forwards it towards the HNB.

Figure A.11.2-1: IU UP Handling during the Initial call setup.

A.11.3 CS User Plane handling after the finalisation of SRNS Relocation

During the SRNS Relocation, as part of the RANAP Relocation Resource Allocation procedure, the target HNB performs the user plane initialisation. The (Target) HNB allocates the RAB Subflows combination indicator(s) for the each SDU formats (SDU formats are sent to the HNB in the RANAP RELOCATION REQUEST message). The allocation is then sent in the Iu Framing Initialisation PDU by the HNB in the user plane. For further details see TS 25.413 [9] and TS 25.415 [17].

Figure A.11.3-1. IU UP Handling after SRNS Relocation.

At reception of an IU UP Initialisation Frame (Iu UP PDU type 14) from the Target HNB, the HNB-GW stores received RFCI indexes (per data rate) in the form of ordered sequence (received in the initialisation PDU) as “UL RFCI Vector” and send the Initialisation acknowledgment to the target HNB. The HNB-GW does not perform the forwarding of the IuUP initialisation on the Iu interface. The HNB-GW checks whether the received RFCI allocations match the stored RFCI allocation for the same bearer established with the source HNB. The HNB-GW performs the following functions:

– RFCI Mapping function: If the allocated RFCI index (s) does not match with the existing RFCI index(s) for the corresponding data rates, then the HNB-GW performs the RFCI Mapping function. That is, for every subsequent Iu UP frame upon the relocation, the HNB-GW maps the RFCI indices of the incoming side (from the HNB) to the corresponding RFCI indicates to the outgoing side (towards the MSC that is already stored in the HNB-GW) and vice versa.

– In case Iu UP version 1, if the maximum rate indicated by the target HNB in the Iu UP INIT is different from the current used maximum rate then the HNB-GW initiates a Rate Control PDU indicating the new maximum rate to the MSC.

A.11.4 FQC

The HNB-GW (IuhUP IF) does not handle the FQC included in the UP frames. The value included in the Iu UP frame is passed to the peer not without any modification.

A.11.5 Frame number

The frame number indicated by the peer node (i.e. Iu or Iuh) on the receiving side is forwarded unmodified to lower layer on the sending side.

A.11.6 Time alignment Procedure:

When a HNB-GW (IuhUP IF) entity receives a time Alignment Command over the Iu or Iuh interface, it is relayed unmodified to the other peer node.

A.11.7 Rate Control Procedure

When an HNB-GW (IuhUP IF) entity receives a Rate Control over the Iu or Iuh interface, it forwards to the other peer node) with ‘RFCI Mapping’ where appropriate.

A.11.8 Payload

When a HNB-GW (IuhUP IF) entity receives the payload SDUs, the received SDUs is forwarded unmodified to the either side (HNB or HNB-GW) with ‘RFCI Mapping’ where appropriate.

A.11.9 Iu UP Re-Initialisation

When an HNB-GW (IuhUP IF) entity receives a Iu UP Initialisation from the CN, it stores the “DL RFCI Vector” and then forward it to the HNB without any modification in the RFCIs. Upon reception of the Iu UP ACK/NACK PDU, the HNB-GW forwards it towards the CN.

Figure A.11.9-1: IU UP Re- Initialisation.

Annex B (informative):
Deployment Architecture