AVT Working Group Shuaiyu Wang
Internet Draft Xiaodong Duan
Intended status: Standards Track China Mobile
Expires: August 18 2008 Rocky Wang
Ying Zhang
Huawei
February 18, 2008
RTP Payload Format for GSM-HR Speech Codecs
draft-wang-avt-rtp-gsm-hr-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 17 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document registers a media type for the Real-time Transport
protocol (RTP) payload format, which is used for the Group Special
Mobile half-rate speech transcoding.
Duan,Wang Expires August 18, 2008 [Page 1]
Internet-Draft RTP Payload Format for GSM-HR February 2008
Table of Contents
1. Introduction................................................2
1.1. Terminology............................................2
2. Background for GSM HR Speech codes over RTP..................3
2.1. GSM HR Codes...........................................3
2.2. A interface over IP.....................................3
2.3. GSM HR Speech codes over IP Scenarios...................5
3. GSM HR codes RTP Payload Formats.............................6
3.1. Payload Structure.......................................6
3.2. Registration of Media Type GSM-HR.......................9
4. Mapping MIME Parameters into SDP............................10
5. Security Considerations.....................................11
6. IANA Considerations........................................11
7. References.................................................12
7.1. Normative References...................................12
Author's Addresses............................................12
Intellectual Property Statement................................13
Disclaimer of Validity........................................13
1. Introduction
Global System for Mobile Communication (GSM) network has been widely
deployed in the last several years to provide mobile communication
services. GSM half rate codec (GSM-HR) is one of the compressed
speech codecs which are used for the basic speech service in the GSM
mobile networks.
GSM-HR denotes GSM 06.20 half-rate speech transcoding, specified in
ETS 300 969 which is available from ETSI at the address given in RFC
3551 [1] Section 4.5.8. This codec has a frame length of 112 bits.
For transmission in RTP, each codec frame is packed into a 14
octet(112 bit). The packing is specified in ETSI Technical
Specification TS 101 318.
This document registers a media type for the Real-time Transport
protocol (RTP) payload format for the GSM-HR codec to enabling the
use of the codec in the Voice over IP (VoIP) application.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2].
Duan,Wang Expires August 18, 2008 [Page 2]
Internet-Draft RTP Payload Format for GSM-HR February 2008
2. Background for GSM HR Speech codes over RTP
2.1. GSM HR Codes
As defined in the GSM standard, the GSM physical layer is presented
as a combination of FDMA and TDMA. Based on the frequency division
principle, the entire GSM band is divided into several 200-KHz
channels which named as absolute radio frequency channel number in
the Standard (ARFCN for short). Each channel is divided into 8
timeslots according to the time division principle. Hence, a GSM
physical channel in fact corresponds to one timeslot on a certain
channel.
Timeslots are repeated according to specific disciplinarian, bringing
the concepts of frames and multi-frames. In GSM Standard, the
channels bearing voice and data services are repeated in a period of
26 frames. In words, the TDMA multiframe of a traffic channel (TCH)
consists of 26 frames, with the duration of 120 ms.
Among the 26 frames on a full rate speech channel (TCH/FS) or an
enhanced full rate speech channel (TCH/EFS), 24 are used to bear
speech data, one (Frame 13) to transmit the channel associated
signaling on a slow associated control channel (SACCH), and one
(Frame 26) is idle.
When the system adopts half rate speech channel (TCH/HS), no change
will bring to the multi-frame structure of the air interface. In this
case, the odd frames in the multi-frame are allocated to one user and
even frames to another, while the original Frame 13 serves as the
SACCH of the first user and the idle Frame 26 as the SACCH of the
second user. In this way, a channel previously only capable of
bearing one TCH/FS or TCH/EFS can now bear two TCH/HSs. The capacity
of the channel doubles the original.
2.2. A interface over IP
A interface is the interface between MSC and BSC.
+----------+ +----------+
| | A interface | |
| BSC |<----------------------->| MSC |
| | TDM | |
+----------+ +----------+
Figure 1 A interface (Legacy network).
Duan,Wang Expires August 18, 2008 [Page 3]
Internet-Draft RTP Payload Format for GSM-HR February 2008
According to the existing protocol, the A interface user plane is
only based on TDM. A interface over IP is a technique trend in
wireless network evolution, which can construct high bandwidth, high
efficiency and low cost basic networks. For A interface over IP,
control plane signalling over IP (SIGTRAN) has been introduced in
3GPP Release 7 while certain features (e.g. MSC in Pool and Layered
Architecture) require an intermediate signalling network for best
performance. In order to take full advantage of IP based technologies
the protocols of A interface user plane should be adapted for IP
based transport.
A interface over IP can also simplify the implementation of MSCs in a
pool. Furthermore, UTRAN network and more advanced RAN can use a
common IP backhaul with GERAN. One of the main advantages of having
IP based A-interface for the user plane is a much more flexible
network design between the BSS and the CS core.
IP hardware in the nodes and IP site and backbone infrastructure can
be shared by the A-interface control plane and the user plane. A
separation of the signaling network from the user plane can be
achieved by using technologies like VLAN tagging, virtual routing etc.
This will allow the operator to abolish TDM hardware and TDM
infrastructure and by that reduce OPEX and CAPEX.
Further on in most of the current networks, both BSS and CN have
transcoding functionality, i.e. Transcoder in BSS and Media Gateway
(MGW) in CN. Some core networks have been upgraded to convey
compressed speech over IP transport. In this case, removing TC from
BSS and transfer compressed speech over A interface will reduce cost
of transcoder device, reduce cost of transport resource and improve
voice quality by implementing TrFO.
+----------+ +----------+
| | A interface | |
| BSC |<----------------------->| MSC |
| | TDM | |
+----------+ +----------+
+-------------+ +----------+
| | A interface | |
| BSC |<----------------------->| MGW |
| (with TC or | IP | with TC |
| without TC | | |
+-------------+ +----------+
Figure 2 Architecture for A interface over IP.
Duan,Wang Expires August 18, 2008 [Page 4]
Internet-Draft RTP Payload Format for GSM-HR February 2008
2.3. GSM HR Speech codes over IP Scenarios
There is an enormous amount of transcoder resources installed in
today's GSM radio networks. Therefore the "final solution" in the
standard shall be flexible and allow the use of transcoders placed in
the BSS and/or in the CS Core Network. In addition, e.g. for the
purpose of migrating the A interface from a TDM to an IP interface,
both TDM and IP based A interface should be supported concurrently,
at least for the migration phase.
Target solution, the solution yields to align the 2G network
architecture with the 3G CS core network architecture, deviates from
the current BSS architecture, where today transcoders are
functionally integrated into the BSS. Allowing placing transcoders in
the CS core network will impacts the functional division between Base
Station System (BSS) and Core Network. This solution allows carrying
compressed speech in an efficient way across the A-interface. In
contrast to TFO the compressed speech is formatted directly and there
is no PCM stream in parallel. This will reduce the overall need for
transcoders in the solution and it will improve the end-to-end delay.
But it will require additional transcoder resources (e.g. for
transcoding in all Mobile-to-PSTN calls) and possibly new transcoder
types (e.g. GSM_HR) within the Core Network.
In this case, GSM-HR needs to be transferred over IP based A
interface if GSM-HR is applied in the air interface.
+-------------+ +----------+
| | A interface over IP | |
| BSC |<----------------------->| MGW |
| without TC | GSM-HR | with TC |
| | | |
+-------------+ +----------+
Figure 3 Deployment Scenario: compressed speech(such as GSM-HR) is
transferred over IP based A interface.
Duan,Wang Expires August 18, 2008 [Page 5]
Internet-Draft RTP Payload Format for GSM-HR February 2008
3. GSM HR codes RTP Payload Formats
3.1. Payload Structure
The GSM half rate codec has frame length of 112 bits. Every frame
is encoded into one 14 octet (112 bit) buffer. There shall be no
signature.
The complete payload consists of a payload header, a payload
table of contents, and speech data representing one or more
speech frame-blocks. The following diagram shows the general
payload format layout:
+----------------+-------------------+----------------
| payload header | table of contents | speech data ...
+----------------+-------------------+----------------
Figure 4 payload structure.
The bits in RTP buffer are numbered from r1 (the most significant
bit of first octet) to r112 (the least significant bit of last
octet). Within the GSM 06.20 codec parameter bits are numbered in
big-endian manner.
1 Encoding of speech frames
There are two alternative formats of a ETS 300 969 [6] speech
frames. The first form is for codec mode 0 (unvoiced speech), the
second form is for modes 1, 2 and 3 (voiced speech).
Parameter No. of bits Bit No.(MSB-LSB)
-------------------------------------------------
R0 5 r1 - r5
LPC1 11 r6 - r16
LPC2 9 r17 - r25
LPC3 8 r26 - r33
Duan,Wang Expires August 18, 2008 [Page 6]
Internet-Draft RTP Payload Format for GSM-HR February 2008
INT_LPC 1 r34
MODE 2 r35 - r36
CODE1_1 7 r37 - r43
CODE2_1 7 r44 - r50
GSP0_1 5 r51 - r55
CODE1_2 7 r56 - r62
CODE2_2 7 r63 - r69
GSP0_2 5 r70 - r74
CODE1_3 7 r75 - r81
CODE2_3 7 r82 - r88
GSP0_3 5 r89 - r93
CODE1_4 7 r94 - r100
CODE2_4 7 r101 - r107
GSP0_4 5 r108 - r112
Table 1: The order of GSM 06.20 half rate speech codec parameters
in RTP buffer (MODE=0)
Parameter No. of bits Bit No.(MSB-LSB)
-------------------------------------------------
R0 5 r1 - r5
LPC1 11 r6 - r16
LPC2 9 r17 - r25
LPC3 8 r26 - r33
Duan,Wang Expires August 18, 2008 [Page 7]
Internet-Draft RTP Payload Format for GSM-HR February 2008
INT_LPC 1 r34
MODE 2 r35 - r36
LAG_1 8 r37 - r44
CODE1 9 r45 - r53
GSP0_1 5 r54 - r58
LAG_2 4 r59 - r62
CODE2 9 r63 - r71
GSP0_2 5 r72 - r76
LAG_3 4 r77 - r80
CODE3 9 r81 - r89
GSP0_3 5 r90 - r94
LAG_4 4 r95 - r98
CODE4 9 r99 - r107
GSP0_4 5 r108 - r112
Table 2: The order of GSM 06.20 half rate speech codec parameters
in RTP buffer (MODE=1, 2 or 3)
2 Encoding of silence indication frames
The half-rate codec SID frame is encoded according to the ETS 300
971 [7].
A SID frame is identified by a SID codeword consisting of 79 bits
which are all 1. The parameters in table 3 have to be set as
shown in order to mark a frame as a SID frame.
Parameter No. of bits Value (Hex)
-------------------------------------------------
INT_LPC 1 116
Duan,Wang Expires August 18, 2008 [Page 8]
Internet-Draft RTP Payload Format for GSM-HR February 2008
MODE 2 316
LAG_1 8 FF16
CODE1 9 1FF16
GSP0_1 5 1F16
LAG_2 4 F16
CODE2 9 1FF16
GSP0_2 5 1F16
LAG_3 4 F16
CODE3 9 1FF16
GSP0_3 5 1F16
LAG_4 9 1FF16
GSP0_4 5 1F16
Table 3: SID codeword for half rate speech codec
3.2. Registration of Media Type GSM-HR
Type name: audio
Subtype name: GSM-HR
Required parameters: none
Optional parameters:
ptime: the recommended length of time (in milliseconds)
represented by the media in a packet and the default value is20
milliseconds. See Section 6 of RFC 4566 [3].
Encoding considerations:
This media type is framed binary data (see Section 4.8 in RFC4288
[4]).
Duan,Wang Expires August 18, 2008 [Page 9]
Internet-Draft RTP Payload Format for GSM-HR February 2008
Security consideration:
This media type does not carry active content. It does transfer
compressed data.
Interoperability considerations: none
Published specification: RFC XXXX
Applications that use this media type:
Audio and video streaming and conferencing tools
Additional information: none
Person & email address to contact for further information:
Xiaodong Duan duanxiaodong@chinamobile.com
Intended usage: COMMON
Restrictions on usage:
This media type depends on RTP framing, and hence is only defined
for transfer via RTP (RFC 3550 [5]). Transfer within other
framing protocols is not defined at this time.
Author:
Xiaodong Duan duanxiaodong@chinamobile.com
Shuaiyu Wang wangshuaiyu@chinamobile.com
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
4. Mapping MIME Parameters into SDP
The information carried in the MIME media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
[3], which is commonly used to describe RTP sessions. When SDP is
used to specify sessions employing the compact bundled format for GSM
half-rate speech, the mapping is as follows:
Duan,Wang Expires August 18, 2008 [Page 10]
Internet-Draft RTP Payload Format for GSM-HR February 2008
The MIME type ("audio") goes in SDP "m=" as the media name.
The MIME subtype ("GSM-HR") goes in SDP "a=rtpmap" as the
encoding name and the sampling rate for the GSM-HR codec is 8 KHz.
The optional parameters "ptime" goes in the SDP "a=ptime"
attributes, respectively.
The payload type payload type value for GSM-HR is created dynamically
and is used in the PT field of the RTP data header.
5. Security Considerations
RTP packets using the GSM-HR payload format are subject to the
security considerations discussed in the RTP specification [5].
A potential denial-of-service threat exists for data encodings using
compression techniques that have non-uniform receiver-end
computational load. The attacker can inject pathological datagrams
into the stream which are complex to decode and cause the receiver to
be overloaded. However, this encoding does not exhibit
anysignificant non-uniformity.
As with any IP-based protocol, in some circumstances a receiver may
be overloaded simply by the receipt of too many packets, either
desired or undesired. Network-layer authentication MAY be used to
discard packets from undesired sources, but the processing cost of
the authentication itself may be too high.
6. IANA Considerations
It is requested that one new media subtype (audio/GSM-HR) is
registered by IANA. For details, see Section 2.
Duan,Wang Expires August 18, 2008 [Page 11]
Internet-Draft RTP Payload Format for GSM-HR February 2008
7. References
7.1. Normative References
[1] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", RFC 3551, July 2003.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[4] Freed, N. and J. Klensin, " Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[5] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003.
[6] ETS 300 969: "Digital cellular telecommunications system (Phase
2+); Half rate speech; Half rate speech transcoding (GSM
06.20)".
[7] ETS 300 971: "Digital cellular telecommunications system; Half
rate speech; Comfort noise aspects for the half rate speech
traffic channels (GSM 06.22)".
Author's Addresses
Xiaodong Duan
China Mobile Communications Corporation
53A, Xibianmennei Ave., Xuanwu District
Beijing, 100053 P.R. China
Email: <duanxiaodong@chinamobile.com>
Shuaiyu Wang
China Mobile Communications Corporation
53A, Xibianmennei Ave., Xuanwu District
Beijing, 100053 P.R. China
Email: <wangshuaiyu@chinamobile.com>
Duan,Wang Expires August 18, 2008 [Page 12]
Internet-Draft RTP Payload Format for GSM-HR February 2008
Rocky Wang
Huawei Technologies
Xibianmennei AveHuawei Industrial Base, Bantian Longgang
Shenzhen, Guangdong Province 518129, P.R.China
Email: <rocky.wang@huawei.com>
Ying Zhang
Huawei Technologies
Huawei Industrial Base, Bantian Longgang
Shenzhen, Guangdong Province 518129, P.R.China
Email: <zhangying67324@huawei.com>
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
Duan,Wang Expires August 18, 2008 [Page 13]
Internet-Draft RTP Payload Format for GSM-HR February 2008
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Duan,Wang Expires August 18, 2008 [Page 14]