ETSI TR 183 068 V3.1.1 (2009-08)

Technical Report
Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN);
Guidelines on using Ia H.248 profile for
control of Border Gateway Functions (BGF);
Border Gateway Guidelines
2 ETSI TR 183 068 V3.1.1 (2009-08)

Reference
DTR/TISPAN-03202-NGN-R3
Keywords
gateway, H.248, SIP
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2009.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TR 183 068 V3.1.1 (2009-08)
Contents
Intellectual Property Rights . 6
Foreword . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Abbreviations . 9
4 Structure of this Technical Report . 9
Annex A: Illustration of Gate/Pinhole Concept. 10
A.1 General . 10
A.2 Relationships between gates and H.248 Streams . 10
Annex B: Void . 11
Annex C: Void . 12
Annex D: Illustration of an IP processing model for an H.248 (IP, IP) Context . 13
D.1 Example model . 13
D.2 Aspects of filter interaction . 15
D.2.1 Interaction between address latching and address policing . 15
Annex E: Guidelines for Ia-to-Gq' mapping . 17
E.1 Guidelines for Ia-to-Gq' mapping with regards to session-independent procedures . 17
E.1.1 Introduction . 17
E.1.2 Mapping guidelines . 17
E.1.2.1 Session-dependent procedures . 17
E.1.2.2 Session-independent procedures . 18
E.2 Guidelines for Ia-to-Gq' mapping with regards to bearer-specific events . 18
E.2.1 Introduction . 18
E.2.2 Mapping guidelines . 19
E.2.2.1 Guidelines for Specific Action AVPs . 19
E.2.2.2 Other AVPs . 19
Annex F: Bandwidth Reservation - Examples for Bandwidth Estimations . 20
F.1 Introduction . 20
F.1.1 Bitrate B in general. 21
F.1.1.1 Before service admission . 21
F.1.1.1a After service completion . 21
F.1.1.2 Transport efficiency . 21
F.1.2 Some important RACS principles . 22
F.1.2.1 Independence of layer 2 and layer 1 . 22
F.1.2.2 Awareness of IP version . 22
F.1.3 VPN Identifiers . 22
F.1.4 SDP "b=" line semantic in H.248 Ia profile versions . 22
F.1.5 Conclusion: ideal resource management model for resource "bitrate" . 22
F.2 Traffic aspects . 23
F.2.1 Quality of bitrate reservation . 23
F.3 Examples . 23
ETSI
4 ETSI TR 183 068 V3.1.1 (2009-08)
F.3.1 Examples for media-aware streams . 23
F.3.1.1 Example for G.711 . 23
F.3.2 Examples for media-agnostic streams . 24
Annex G: Illustration of BGF modes of operation . 26
G.1 Major SDP Information Elements for Media/Bearer/Resource Control in the BGF. 26
G.1.1 Example . 27
G.2 BGF modes driven by particular SDP lines . 27
G.2.1 SDP "c=" line . 27
G.2.2 SDP "m=" line . 28
G.3 BGF modes driven by configuration management . 28
G.3.1 Media-related modes . 28
G.3.2 Transport-related modes . 28
Annex H: Illustration of NAPT modes of operation . 29
H.1 NAPT types . 29
H.1.1 Remote NA(P)T devices . 29
H.1.2 MG-local NA(P)T function . 30
H.2 NAPT-full modes . 30
H.2.1 General case: non-symmetrical remote network addresses . 30
H.2.1.1 "Double" NAPT mode without explicit Local Source settings . 30
H.2.1.2 "Double" NAPT mode with explicit Local Source settings . 32
H.2.2 Special case: symmetrical remote network addresses . 32
H.2.2.1 "Double" NAPT mode without explicit Local Source settings . 33
H.2.2.2 "Double" NAPT mode with explicit Local Source settings . 34
H.3 NAPT-less . 34
H.3.1 Definition . 34
H.3.2 BGF (MG) behaviour for NAPT-less . 34
H.3.2.1 Handling of source transport address values {SA, SP} . 35
H.3.2.2 Handling of destination transport address values {DA, DP} . 35
H.3.3 Control methods of NAPT-less mode . 35
H.3.3.1 Method 1: mirrored H.248 LD and RD between the two H.248 IP terminations (stream endpoints) . 35
H.3.3.2 Method 2: omitted address information in H.248 LD and RD . 35
H.3.3.3 Method 3: explicit indication via H.248 Context Attribute . 35
H.3.4 NAPT-less examples . 36
H.3.4.1 "Double" NAPT-less mode, controlled via method 1 . 36
H.4 Mixed NA(P)T-full/NA(P)T-less modes . 36
H.4.1 Example of combination of Double-NAPT and NAPT-less . 36
H.4.2 Profile limitations . 37
Annex I: Illustration of "Protocol Layer Lx"-based Packet Processing BGF modes . 38
I.1 BGF modes - Technological Framework . 39
I.2 BGF modes - Control Framework . 40
I.3 Example BGF modes - RTP-based Applications . 43
I.3.1 Example application . 43
I.3.2 Transport-agnostic modes . 44
I.3.3 L4-port aware and transport-protocol agnostic modes . 46
I.3.4 Transport aware (= L4-port aware and transport-protocol aware) modes . 49
I.3.5 Media framing aware (= media-type aware, media-format agnostic, L4-port aware and transport-
protocol aware) modes . 52
I.3.5.1 Open items . 55
I.3.6 Media aware "RTP Transport Translator" (= media-type aware, media-format aware) modes . 55
I.3.7 Media aware "RTP Media Translator" (= media-type aware, media-format aware) modes . 58
I.4 Example BGF modes - TCP-based Applications . 61
I.4.1 Example application . 61
ETSI
5 ETSI TR 183 068 V3.1.1 (2009-08)
I.4.1.1 Mode discrimination . 62
I.4.2 TCP relay modes . 62
I.4.2.1 Unencrypted transport layer . 62
I.4.2.2 Encrypted transport layer using TLS . 64
I.4.3 TCP proxy modes . 65
I.5 Summary . 67
Annex J: Illustration of BGF Reporting of Protocol Layer Lx based Performance
Measurements . 68
History . 70

ETSI
6 ETSI TR 183 068 V3.1.1 (2009-08)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
ETSI
7 ETSI TR 183 068 V3.1.1 (2009-08)
1 Scope
The present document defines guidelines for usage and implementation of border gateways (BGW), based on H.248
profile definitions for controlling such IP-to-IP gateways like ETSI TISPAN "H.248 Ia profile" specifications [i.1], [i.2]
and [i.3].
Figure 1 illustrates the architecture assumed in the present document.

Figure 1: Scope
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
Not applicable.
ETSI
8 ETSI TR 183 068 V3.1.1 (2009-08)
2.2 Informative references
The following referenced documents are not essential to the use of the present document but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
[i.1] ETSI ES 283 018 (Release 1): "Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN); Resource and Admission Control: H.248 Profile
for controlling Border Gateway Functions (BGF) in the Resource and Admission Control
Subsystem (RACS); Protocol specification". - also known as "H.248 Ia Profile Version 1".
[i.2] ETSI ES 283 018 (Release 2): "Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN); Resource and Admission Control: H.248 Profile
for controlling Border Gateway Functions (BGF) in the Resource and Admission Control
Subsystem (RACS); Protocol specification". - also known as "H.248 Ia Profile Version 2".
[i.3] ETSI TS 183 018 (Release 3): "Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN); Resource and Admission Control: H.248 Profile
Version 3 for controlling Border Gateway Functions (BGF) in the Resource and Admission
Control Subsystem (RACS); Protocol specification". - also known as "H.248 Ia Profile Version 3".
[i.4] ITU-T Recommendation H.248.1 (2005): "Gateway control protocol: Version 3" including its
Amendment 1 (05/2008).
[i.5] ETSI TS 183 048: "Telecommunications and Internet Converged Services and Protocols for
Advanced Networking (TISPAN); Resource and Admission Control System (RACS); Protocol
Signalling flows specification; RACS Stage 3".
[i.6] ETSI TS 183 017: "Telecommunications and Internet Converged Services and Protocols for
Advanced Networking (TISPAN); Resource and Admission Control: DIAMETER protocol for
session based policy set-up information exchange between the Application Function (AF) and the
Service Policy Decision Function (SPDF); Protocol specification".
[i.7] ETSI TS 181 018 (Release 2): "Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN); Requirements for QoS in a NGN".
[i.8] ETSI TR 182 022 (Release 2): "Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN); Architectures for QoS handling".
[i.9] IEEE 802.3: "Ethernet Working Group".
[i.10] ETSI TR 187 008 (Release 1): "Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN); NAT traversal feasibility study report".
[i.11] IETF RFC 5117 (2008-01): "RTP Topologies".
[i.12] draft-hunt-avt-rtcptrans-00.txt (2007-11): "RTCP Reporting by Translators".
[i.13] ITU-T Recommendation Y.1251 (08/2002): "General architectural model for interworking".
[i.14] Draft ITU-T Recommendation G.IP2IP: "Functionality and Performance of an IP-to-IP Voice
Gateway, optimised for the transport of voice and voiceband data".
[i.15] ITU-T Recommendation Y.1560 (09/2003): "Parameters for TCP connection performance in the
presence of middleboxes".
[i.16] IEEE 802.1: "Local Area Networks: Architecture & Overview".
[i.17] IETF RFC 1812: "Requirements for IP Version 4 Routers".
[i.18] IETF RFC 768: "User Datagram Protocol".
[i.19] IETF RFC 3550: "RTP: A Transport Protocol for Real-Time Applications".
[i.20] IETF RFC 3551: "RTP Profile for Audio and Video Conferences with Minimal Control".
ETSI
9 ETSI TR 183 068 V3.1.1 (2009-08)
[i.21] IETF RFC 4733: "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals".
[i.22] IETF RFC 3142: "An IPv6-to-IPv4 Transport Relay Translator".
[i.23] IETF RFC 4734: "Definition of Events for Modem, Fax, and Text Telephony Signals".
[i.24] ITU-T Recommendation Draft H.248.64.
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AC Admission Control
B2BIH Back-to-Back IP Host (mode)
B2BRE Back-to-Back RTP Endsystem (mode)
B2BTE Back-to-Back TCP Endpoint (mode)
BGF Border Gateway Function
CBR Constant Bit Rate
IP Internet Protocol
IPR IP router (mode)
LCD Local Control Descriptor
LD Local Descriptor (H.248)
LS Local Source
MALG Media Application lLevel Gateway
MG, MGW Media GateWay
MGC Media Gateway Controller
MP Measurement Point
MSRP Message Session Relay Protocol
NA(P)T Network Address (and Port) Translation
NAPT Network Address and Port Translation
NTE Network Telephone Events
PCI Protocol Control Information
PDU Protocol Data Unit
RD Remote Descriptor (H.248)
RFC Request For Comments (IETF)
RP Reporting Point
RS Remote Source
RTCP RTP Control Protocol
RTP Real-time Transport Protocol
RTPMTm RTP Media Translator mode
RTPTTm RTP Transport Translator mode
SDP Session Description Protocol
SDU Service Data Unit
SIP Session Initiation Protocol
SPDF Service Policy Decision Function
StAC Stream Admission Control
TCP Transmission Control Protocol
TLS Transport Layer Security
TRT Transport Relay Translator
UDP User Datagram Protocol
VBR Variable Bit Rate
4 Structure of this Technical Report
The present document inherits a structure based on annexes from the H.248 Ia profile specifications [i.1], [i.2] and [i.3].
The annex numbering was kept in order to be consistent with the old document versions of these specifications.
Any references from the annexes are related to H.248 Ia profile version 3 specification [i.3].
ETSI
10 ETSI TR 183 068 V3.1.1 (2009-08)
Annex A:
Illustration of Gate/Pinhole Concept
The purpose of this annex is the illustration of the H.248 Stream/Termination model by showing exemplary realizations
of gates for uni- versus bidirectional media flows.
A.1 General
Only point-to-point sessions are in scope of this H.248 Profile (see clause 5.4, TS 183 018 [i.3]). Interconnection of
individual H.248 Streams is based on the basic principle described in clause 7.1.6/H.248.1 [i.4]. The H.248 Multiplex
Descriptor is therefore not necessary (see clause 5.6.2, TS 183 018 [i.3]). The H.248 Topology Descriptor definition
includes individual H.248 Streams, but is also not necessary (see
clause 5.7.8, TS 183 018 [i.3]).
It has to be noted that all sessions have unicast media flows. Potential multicast applications are transparent for MG
point of view.
A.2 Relationships between gates and H.248 Streams
The realization of a gate is illustrated in figure A.1. There is a unidirectional media flow in that example, and there is a
single H.248 Stream per Termination. A H.248 Stream covers per definition a single bidirectional media flow
(clause 7.1.6/ITU-T Recommendation H.248.1 [i.4]). In this profile when RTP is used with RTCP, a single H.248
stream represents both RTP media and the corresponding RTCP flow. Media flows are interconnected by using the
same StreamID (here: StreamID equals to S1 for T1 and T2).
Example A1.1
IP H.248 IP H.248
Termination Termination
S1 S1
Gate
⇒
T1 IP H.248 IP H.248 T2
Stream Stream
H.248 Context
H.248 Context
Figure A.1: H.248 Context - Illustration of Gate, Stream and Terminations
The uni- or bidirectional application of an H.248 Streams is controlled via usage of Local Descriptor (LD) and Remote
Descriptor (RD). Figure A.2 shows a bidirectional session. There is again a single H.248 Stream per Termination. Gates
are direction-dependent, there are consequently two gates in this example.
Example A2.1
Gate
⇒
S1 S1
Gate
T1 T2
⇐
H.248 Context
H.248 Context
Figure A.2: H.248 Context Bidirectional Session using single H.248 Streams
ETSI
11 ETSI TR 183 068 V3.1.1 (2009-08)
Annex B:
Void
NOTE: This clause is present to be backwards compatible with the H.248 profile specifications in [i.2] and [i.3].
ETSI
12 ETSI TR 183 068 V3.1.1 (2009-08)
Annex C:
Void
NOTE: This clause is present to be backwards compatible with the H.248 profile specifications in [i.2] and [i.3].
ETSI
13 ETSI TR 183 068 V3.1.1 (2009-08)
Annex D:
Illustration of an IP processing model
for an H.248 (IP, IP) Context
The purpose of this annex is the illustration of a possible IP flow processing model. Such a model is helpful when
considering aspects concerning:
• location of a particular function within the (BGF) processing pipeline; or
• possible interactions between functions (see e.g. clause D.2).
It has to be noted that the model is just an example, not exhaustive concerning all possible functions with regards to
supported capabilities by this profile, and not related to any particular implementation.
D.1 Example model
Figure D.1 provides an example pipeline model, which is only indicating a single H.248 Stream of the (IP, IP) Context.
A H.248 Stream is fundamentally bidirectional, i.e. relates to two unicast IP flows, one per traffic direction. This
example is not considering aspects of RTP/RTCP mapping on a H.248 Stream.
The example model is considering optional and mandatory functions by this profile specification. The example is using
modelling components for filter (F), detector (D), address processing (A) and statistic (S) entities. There might be
further modelling components, e.g. for media-aware specific processing functions. The example model is assuming a
pure serial processing pipeline, real implementations could of course benefit from parallelization.
ETSI
14 ETSI TR 183 068 V3.1.1 (2009-08)

Figure D.1: H.248 Context - Illustration of IP flow processing - Example Overview
There might be dependencies between different processing stages, which impact the order of pipeline stages.
ETSI
15 ETSI TR 183 068 V3.1.1 (2009-08)
D.2 Aspects of filter interaction
Possible filter interactions are already indicated in several package specifications of the
ITU-T Recommendation H.248.x-series of Recommendations. General solutions/recommendations are not yet provided
by the package definitions themselves. This is therefore rather a subject for profile specifications, which using the
correspondent packages.
D.2.1 Interaction between address latching and address policing
This profile version indicates two possible cases for filter interaction, either due to:
• enabled latching plus address policing per H.248 Stream, i.e. application of packages ipnapt v1 and gm v1; or
• the correlation of SDP information from the RD and gm v1 address policing (see clause 5.18.1.1.1,
TS 183 118 [i.3]).
Figure D.2 illustrates the possible interaction: the ingress filter stage F provides explicit source address and port
in,1
policing and is controlled via gm v1 properties (see clause 5.18.1.1.1, TS 183 118 [i.3]). Source address and port
policing could be applied for a single individual address/port, a single address/port range, multiple individual
addresses/ports, multiple address/port ranges, or combinations thereof. Stage F provides implicit source address/port
in,2
policing and is controlled via the (re)latching process (and not controlled via gm v1 properties).
The function address latching/re-latching is provided by stage A .
in,1
possible address
reporting (out of
scope of this Profile)
unicast,
unidirectional
IP flow of an H.248 IP
Stream
F A F .
in,1 in,1 in,2
Explicit Packet Filter: Address Analysis: Implicit Packet Filter:
Address/Port Policing • Address Address Policing
=> Source Address Latching => Source Address
/Port Information /Port Information
=> Address/Port
=> Single Address
Range(s)
=> Single Port
Figure D.2: H.248 Context - Illustration of IP flow processing
- Interaction between address latching and address policing - Example model 1
Package gm v1 controlled filters are independent of the latching process. The latching process could lead to an
adaptation of the implicit source address/port filter (according clause 5.18.1.1.1, TS 183 118 [i.3], and as indicated in
figures D.2, D.3 or D.4).
The interaction and adaptation could affect different filter stages, dependent on the applied model. Figure D.3 illustrates
another example: F filters on some source address and port ranges.
in,1
ETSI
16 ETSI TR 183 068 V3.1.1 (2009-08)
adaptation
unicast,
unidirectional
IP flow of an
H.248 IP Stream
F A F .
in,1 in,1 in,2
Explicit Packet Filter: Address Analysis: Implicit Packet Filter:
Address/Port Policing • Address Address Policing
=> Source Address Latching => Source Address
/Port Information /Port Information
=> Address/Port
=> Single Address
Range(s)
=> Single Port
Figure D.3: H.248 Context - Illustration of IP flow processing
- Interaction between address latching and address policing - Example model 2
Figure D.4 illustrates another example: stage F filters on a specific source address/port range.
in,1
adaptation
unicast,
unidirectional
IP flow of an
H.248 IP Stream
F A F .
in,1 in,1 in,2
Explicit Packet Filter: Address Analysis: Implicit Packet Filter:
Address/Port Policing • Address Address Policing
=> Source Address Latching => Source Address
/Port Information /Port Information
=> Network Address => Single Address
=> L3 filter/single => Single Port
address
=> Port range
Figure D.4: H.248 Context - Illustration of IP flow processing
- Interaction between address latching and address policing - Example model 3
ETSI
17 ETSI TR 183 068 V3.1.1 (2009-08)
Annex E:
Guidelines for Ia-to-Gq' mapping
The purpose of this annex is to provide mapping guidelines in the area of:
• session-independent procedures;
• bearer-specific events (e.g. due to failure detection); or
• unsuccessful session completions.
E.1 Guidelines for Ia-to-Gq' mapping with regards to
session-independent procedures
E.1.1 Introduction
The procedures of the H.248 Ia profile are divided in session-dependent (see clause 5.17.1, TS 183 118 [i.3]) and
session-independent (see clause 5.17.2, TS 183 118 [i.3]) procedures. Figure E.1 depicts the major difference between
both procedure categories when looking at the vertical interfaces Gq' besides Ia.
Gm
(SIP)
AF AF
SIP Session
1) SIP session initiated
Gq’ Gq’
requests …
(Diameter) (Diameter)
Rq Rq
SPDF SPDF
Management
System
(SIP) Session-
2) (SIP) Session-
independent
Ia
dependent
(Ia) procedures
(H.248)
(Ia) procedures
Ia (H.248)
Bearer Bearer
BGF BGF
[IP flow(s)] [IP flow(s)]
A) Session-dependent procedures B) Session-independent procedures

Figure E.1: RACS architecture - Session-dependent vs Session-independent procedures
from Ia point of view
E.1.2 Mapping guidelines
E.1.2.1 Session-dependent procedures
Mapping rules for Gq'-to-Ia for session-dependent procedures (see (A) in figure E.1) is in scope of TS 183 048 [i.5].
ETSI
18 ETSI TR 183 068 V3.1.1 (2009-08)
E.1.2.2 Session-independent procedures
The scope of session-independent procedures, as defined by this profile, is limited on Ia (see (B) in figure E.1). There
are thus neither guidelines required nor provided for mappings from/towards Gq'.
E.2 Guidelines for Ia-to-Gq' mapping with regards to
bearer-specific events
E.2.1 Introduction
H.248 provides a much wider set of protocol elements for support of bearer-related events as in comparison to other
protocols like Diameter. This means for H.248-to-Diameter mappings, like for Ia-to-Gq' signalling direction, that often
typically more than one H.248 procedure could be mapped on the same Diameter procedure.
The Ia-to-Gq' mapping function is therefore not bijective (at least as long as both protocols providing different
capability sets). Mapping guidelines might be thus beneficial for implementers.
Figure E.2 illustrates the relevant part of RACS.
AF
Gq’ 4) Notification of the AF by
the SPDF
(Diameter)
3) Mapping function
Rq
SPD F
Gq’=f(Ia,…)
2) Notification of the SPDF
Ia
by the BGF
(H.248)
1) Event detected
Bearer
BGF
[IP flow(s)]
Figure E.2: RACS architecture - Vertical event notifications - Ia-to-Gq' mapping
ETSI
19 ETSI TR 183 068 V3.1.1 (2009-08)
E.2.2 Mapping guidelines
E.2.2.1 Guidelines for Specific Action AVPs
Table E.1: Guidelines for Attribute Value Pairs according clause 7.3.23/TS 183 017
Gq' (Diameter) Ia (H.248)
Specific action AVP Possible H.248 Protocol Possible H.248 Ia Profile Recommended for Ia
Elements Procedure Version 2
Ref.: TS 183 017 [i.6],
clause 7.3.23
INDICATION_OF_ H.248.1 Event: g/cause User Plane Failure Yes
LOSS_OF_BEARER (2) (5.19.12/5.20.18).
H.248.1 Event: nt/netfail ditto Yes (but optional
profile element)
H.248.1 Event: nt/qualert ditto Yes (but optional
profile element)
H.248.40 Event: adid/ipstop IP Media Stop (see note 7)
(clause 5.18.4.1).
H.248.36 Event: - -
hangterm/thb
(see note 8)
H.248 ServiceChange: (see note 1) No
{Forced/Graceful, 904}
H.248 ServiceChange: (see note 2) No
{Forced/Graceful, 905}
H.248 ServiceChange: (see note 3) No
{Forced/Graceful, 906}
INDICATION_OF_ H.248.13 Event: Not supported by this profile (see note 6)
RECOVERY_OF_ nt/qac/qualertcease version.
BEARER (3)
H.248 ServiceChange: (see note 4) No
{Restart, 900} Not supported by this profile
version.
INDICATION_OF_ H.248 Subtract.reply Regular H.248 method Yes
RELEASE_OF_ command (see note 5).
BEARER (4)
NOTE 1: Indication of "termination malfunction" for ephemeral termination.
NOTE 2: Indication of "termination taken Out-of-Service" for ephemeral termination.
NOTE 3: Indication of "loss of lower layer connectivity" for ephemeral termination.
NOTE 4: Indication of "service restore" for ephemeral termination.
NOTE 5: The H.248 Media Gateway is not allowed to autonomously "subtract a H.248 Stream/Termination", which
would relate to a "release bearer" event. There is therefore also not any ServiceChange procedure
defined.
NOTE 6: This method might be as closest to the AVP (3) semantic, particularly when nt/qualert would be used for
AVP (2).
NOTE 7: This event could be overlaid with multiple application. Thus, "No" in case that event is already used for
other purposes (e.g. like latching deadlock detection), else "Yes".
NOTE 8: Not applicable here.
E.2.2.2 Other AVPs
The AVPs that are discussed in this annex serve as a guideline and are not meant to be an exhaustive list of the AVPs
that require mapping to/from Ia (H.248). There may well be further AVPs require mapping guidelines to/from Ia
(H.248). Such further mapping is considered to be beyond the scope of this annex.
ETSI
20 ETSI TR 183 068 V3.1.1 (2009-08)
Annex F:
Bandwidth Reservation - Examples for Bandwidth
Estimations
The purpose of this annex is to provide some background in estimation methods for bitrate reservations, illustrated by
some examples. Figure F.1 summarizes the scope of annex F. Protocol layer specific transformation of bandwidth
requests and the aspect of admission control (related to the resource management aspect of resource component
"bandwidth") is discussed besides examples for bandwidth calculation and estimation.

Figure F.1: Bandwidth Reservation Request - Processing in the BGF
F.1 Introduction
Resource reservation in RACS is just related to the single resource component type "bitrate" B (colloquially also termed
as "bandwidth"). The bitrate B relates to a particular traffic rate, i.e. traffic volume per time unit. The SPDF (or
Application Function, or user equipment) provides an estimate for B for every new or modified H.248 Stream. It is an
estimate (rather than an "exact" stochastically description) due to traffic source abstraction with just a single traffic
parameter.
ETSI
21 ETSI TR 183 068 V3.1.1 (2009-08)
F.1.1 Bitrate B in general
F.1.1.1 Before service admission
As the stationary bitrate (i.e. constant time-average) value is unknown before the communication phase, the SPDF (or
AF, or UE) needs thus an estimation method. There are many possibilities, like e.g. by considering the distribution
functions of the two metrics PDU rate μ and PDU size K . An estimate for an average bitrate could be then
PDU,Lj PDU,Lj,i
calculated, e.g. by:
bit
⎡ ⎤
ˆ ˆ
B = μˆ ⋅ K ⋅ 8 in (F-1)
Lj PDU ,Lj PDU ,Lj
⎢ ⎥
s
⎣ ⎦
NOTE: ^ indicates an estimated value.
ˆ
a) Estimated expected PDU rate μ :
PDU ,Lj
- The PDU rate is often tightly related to the packetization time of media encoder units, in case of media IP
flows. Enabled silence suppression or a muted microphone could reduce temporarily the rate in case of
voice media.
The PDU rate estimation could be more challenging for VBR (Variable Bit Rate) sources (e.g. with a
high burstiness) than for Constant Bit Rate (CBR) sources.
The estimated PDU rate is in any case here time-independent.
ˆ
b) Estimated expected PDU size K :
PDU ,Lj
- The PDU size is generally varying, i.e. K will not be equal to K . A mean value is
PDU,Lj,i PDU,Lj,I-1
supposed in the estimation here.
F.1.1.1a After service completion
The value of B would be known after the completion of an H.248 Stream (Context): the average bitrate relates then to
the time-average for the entire duration of the stream:
Average bitrate B on protocol layer L per H.248 Stream S :
Lx j ν
V
bit
⎡ ⎤
Lj
B = ⋅ 8 in (F-2)
Lj
⎢ ⎥
T s
⎣ ⎦
H ,Sν
The traffic volume V (on protocol layer Lj) is basically given by the sum of all octets of all transferred protocol data
Lj
units (PDUs). The lifetime (or holding time) of the H.248 Stream S is given by T in equation (F-2).
ν H
F.1.1.2 Transport efficiency
Every Protocol Data Unit (PDU) is composed of the Service Data Unit (SDU) and Protocol Control Information (PCI).
The same traffic volume (service data) could be carried with different PDU "rate × size" products (e.g. μ low and
K high, or μ high and K low). Every PDU "rate × size" product has a different transport efficiency concerning the ratio
of service data to control information, or "net bitrate" (for the service data) versus "gross bitrate". This aspect may need
consideration when managing the transport capacity of a BGF interface. Another aspect is discussed in clause F.1.2.
ETSI
22 ETSI TR 183 068 V3.1.1 (2009-08)
F.1.2 Some important RACS principles
F.1.2.1 Independence of layer 2 and layer 1
A RACS is based on an IP infrastructure. The underlying protocol layers below IP are not considered for "resource
admission and control". This IP-centric view allows the consideration of many different transport technologies for IP in
RACS. This is a L2-independent resource management model from network perspective. Such a model does offload the
SPDF from lower layer information.
F.1.2.2 Awareness of IP version
The SPDF is basically aware of the underlying IP version of an H.248 Stream. This is important due to the different
amount of PCI behind the figures for B and B .
IPv4 IPv6
F.1.3 VPN Identifiers
Support of VPNs could lead to increased PCI figures. For instance, Ethernet-based L2VPNs do consume two octets
additional PCI per L2 frame (for the IEEE 802.1 [i.16] Tag Control Information field, which includes the VLAN
identifier).
F.1.4 SDP "b=" line semantic in H.248 Ia profile versions
There are unfortunately different semantics due to historical reasons:
• H.248 Ia Profile Version 1: … defines the l
...