Tech-invite3GPPspaceIETF RFCsSIP
Top   in Index   Prev   Next

TS 25.444
UTRAN – Iuh Interface –
Data Transport

V17.0.0 (PDF)  2022/03  11 p.
V16.0.0  2020/06  11 p.
V15.0.0  2018/06  11 p.
V14.0.0  2017/03  11 p.
V13.0.0  2015/12  11 p.
V12.0.0  2014/09  11 p.
V11.0.0  2012/09  11 p.
V10.1.0  2011/06  11 p.
V9.0.3  2011/04  12 p.
Mr. Godin, Philippe

Content for  TS 25.444  Word version:  16.0.0

Here   Top

1  ScopeWord‑p. 5

The present document specifies the standards for user data transport protocols between the HNB and HNB-GW/CN.

2  References

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]  Void
[2]  Void
[3]  Void
TS 25.414: "UTRAN Iu interface data transport and transport signalling".
[5]  Void
[6]  Void
[7]  Void
RFC 768  (1980-08): "User Datagram Protocol".
RFC 1889  (1996-01): "RTP: A Transport Protocol for Real-Time Applications".
[10]  Void
[11]  Void
TR 21.905: "Vocabulary for 3GPP Specifications".

3  Definitions and abbreviations

3.1  Definitions

For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.

3.2  Abbreviations

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
Core Network
Circuit Switched
Home Node B
Home Node B Gateway
Internet Protocol
Packet Switched
Request For Comment
Real-Time Transport Protocol
User Datagram Protocol

4  Data Link LayerWord‑p. 6

Any data link protocol that fulfils the requirements toward the upper layer may be used.

5  Circuit switched domain

5.1  Transport Network User Plane without bandwidth efficiency mechanisms

Defined in Reference TS 25.414, subclause 5.1.3.

5.3  Transport Network User Plane with bandwidth efficiency mechanisms

5.3.1  General

Bandwidth efficient transport of Uplink CS data payload PDUs may be supported over bearer transport mechanisms for the Iuh interface, using a bearer transport multiplexing scheme that allows transporting several RTP PDUs of different user plane connections within one packet.

5.3.2  Transport format

UDP/IP shall be applied on Iuh between HNB and HNB GW as described in TS 25.414, subclause 5.1.3 for Iu between RNC and CN, except as stated below.  UDP

The path protocol used shall be UDP (IETF RFC 768 [8]). If multiplexing is applied the source UDP port number shall indicate the local termination used to combine the multiplexed packet and the destination UDP port number shall indicate the remote port number where PDUs are demultiplexed.  RTP

RTP (IETF RFC 1889[9]) shall be applied as described in TS 25.414, subclause and requirements below.  Transport Format for multiplexing RTP packets
Use of multiplexing shall be negotiated between the HNB and HNB-GW.
Before each multiplexed RTP/codec payload PDU inserted into the UDP/IP packet a Multiplex Header, which identifies the multiplexed packet, shall be inserted.
(not reproduced yet)
Figure 1: UDP/IP Packet with multiplexed RTP payload PDUs
The Multiplex Header includes :
  • T bit.
    The field has two possible values. Value 0 shall be used for an uncompressed RTP header, as decribed in the present sub-clause. Value 1 is FFS.
  • Mux ID, 15 bits.
    For identification of different user plane connections. The value shall be the UDP destination port of the corresponding non-multiplexed RTP PDU packet divided by two (only even numbered ports are used for RTP sessions).
  • Length Indicator (LI), 8 bits, unsigned integer.
    Gives the length of the multiplexed RTP PDU packet (RTP header + RTP) in bytes (the last byte of the RTP PDU is padded to the next byte boundary if necessary). Maximum length is 255 bytes. This LI allows to calculate where the next Multiplex Header for the next multiplexed RTP PDU packet starts.
  • R bit.
    Reserved for future use. Shall be set to 0 by the sending entity and be ignored by the receiving entity.
  • Source ID, 15 bits.
    For identification of the different connections. The value shall be the source UDP port of the corresponding non-multiplexed RTP/codec PDU packet divided by two (only even numbered ports are used for RTP sessions).
The multiplexed RTP PDU shall be inserted in the IP/UDP packet directly after the corresponding Multiplex Header. The multiplexed RTP packet PDU shall follow the rules defined in IETF RFC 1889 [9] and consists of the full RTP header and the RTP payload. If the multiplexed RTP packet PDU does not end at a byte boundary, then the remaining bits of its last byte shall be padded with zeros.
The multiplexing method does not limit the number of packets being multiplexed and it is thus the data link layer protocol that defines the maximum frame size. In order to avoid additional delay in the network the packets should not be delayed more than 1 ms to 2 ms, which also effectively limits the number of multiplexed packets and makes the multiplexing-jitter low.
(not reproduced yet)
Figure 2: Example of multiplexed packet with two RTP frames

6  Packet switched domainWord‑p. 8

6.1  Transport network user plane

Defined in Ref TS 25.414, subclause 6.1.3.

$  Change HistoryWord‑p. 9

Up   Top