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]