| IP network |
| |
Figure 4: GW to GW scenario (AMR-WB <-> VMR-WB
interoperable interconnection)
During and upon initiation of an interoperable interconnection
between VMR-WB and AMR-WB, only VMR-WB mode 3 can be used. There are
three Frame Types (i.e., FT=0, 1, or 2; see Table 3) within this mode
that are compatible with AMR-WB codec modes 0, 1, and 2,
respectively. If the AMR-WB codec is engaged in an interoperable
interconnection with VMR-WB, the active AMR-WB codec mode set needs
to be limited to 0, 1, and 2.
5.4. GW to GW (between Two VMR-WB-Enabled Terminals)
The fourth example VoIP scenario is composed of a RTP/UDP/IP
transport between two non-IP systems; i.e., IP is originated and
terminated in gateways on both sides of the IP transport, as
illustrated in Figure 5. This is the most likely scenario for
Mobile-Station-to-Mobile-Station (MS-to-MS) Transcoder-Free (TrFO)
interconnection between two 3GPP2/CDMA2000 terminals that both use
VMR-WB codec.
VMR-WB over VMR-WB over
3GPP2/CDMA2000 network 3GPP2/CDMA2000 network
+------+ +------+
| | | |
<------------>| GW |<----------------->| GW |<------------>
| | VMR-WB/RTP/UDP/IP | |
+------+ +------+
| IP network |
| |
Figure 5: GW to GW scenario (a CDMA2000 MS-to-MS VoIP scenario)
6. VMR-WB RTP Payload Formats
For a given session, the payload format can be either header free or
octet aligned, depending on the mode of operation that is established
for the session via out-of-band means and the application.
The header-free payload format is designed for maximum bandwidth
efficiency, simplicity, and low latency. Only one codec data frame
can be sent in each header-free payload format packet. None of the
payload header fields or table of contents (ToC) entries is present
(the same consideration is also made in [11]).
In the octet-aligned payload format, all the fields in a payload,
including payload header, table of contents entries, and speech
frames themselves, are individually aligned to octet boundaries to
make implementations efficient.
Note that octet alignment of a field or payload means that the last
octet is padded with zeroes in the least significant bits to fill the
octet. Also note that this padding is separate from padding
indicated by the P bit in the RTP header.
Between the two payload formats, only the octet-aligned format has
the capability to use the interleaving to make the speech transport
robust to packet loss.
The VMR-WB octet-aligned payload format in the interoperable mode is
identical to that of AMR-WB (i.e., RFC 3267).
6.1. RTP Header Usage
The format of the RTP header is specified in [3]. This payload
format uses the fields of the header in a manner consistent with that
specification.
The RTP timestamp corresponds to the sampling instant of the first
sample encoded for the first frame-block in the packet. The
timestamp clock frequency is the same as the default sampling
frequency (i.e., 16 kHz), so the timestamp unit is in samples.
The duration of one speech frame-block is 20 ms for VMR-WB. For
normal wideband operation of VMR-WB, the input/output media sampling
frequency is 16 kHz, corresponding to 320 samples per frame from each
channel. Thus, the timestamp is increased by 320 for VMR-WB for each
consecutive frame-block.
The VMR-WB codec is capable of processing speech/audio signals
sampled at 8 kHz. By default, the VMR-WB decoder output sampling
frequency is 16 kHz. Depending on the application, the decoder can
be configured to generate 8-kHz output sampling frequency, as well.
Since the VMR-WB RTP payload formats for the 8- and 16-kHz sampled
media are identical and the VMR-WB decoder does not need a priori
knowledge about the encoder input sampling frequency, a fixed RTP
clock rate of 16000 Hz is defined for VMR-WB codec. This would allow
injection or processing of 8-kHz sampled speech/audio media without
having to change the RTP clock rate during a session. Note that the
timestamp is incremented by 320 per frame-block for 8-kHz sampled
media, as well.
A packet may contain multiple frame-blocks of encoded speech or
comfort noise parameters. If interleaving is employed, the frame-
blocks encapsulated into a payload are picked according to the
interleaving rules defined in Section 6.3.2. Otherwise, each packet
covers a period of one or more contiguous 20-ms frame-block
intervals. In case the data from all the channels for a particular
frame-block in the period is missing (for example, at a gateway from
some other transport format), it is possible to indicate that no data
is present for that frame-block instead of breaking a multi-frame-
block packet into two, as explained in Section 6.3.2.
No matter which payload format is used, the RTP payload is always
made an integral number of octets long by padding with zero bits if
necessary. If additional padding is required to bring the payload
length to a larger multiple of octets or for some other purpose, then
the P bit in the RTP header MAY be set, and padding appended, as
specified in [3].
The RTP header marker bit (M) SHALL be always set to 0 if the VMR-WB
codec operates in continuous transmission. When operating in
discontinuous transmission (DTX), the RTP header marker bit SHALL be
set to 1 if the first frame-block carried in the packet contains a
speech frame, which is the first in a talkspurt. For all other
packets, the marker bit SHALL be set to zero (M=0).
The assignment of an RTP payload type for this payload format is
outside the scope of this document and will not be specified here.
It is expected that the RTP profile under which this payload format
is being used will assign a payload type for this encoding or specify
that the payload type is to be bound dynamically (see Section 9).
6.2. Header-Free Payload Format
The header-free payload format is designed for maximum bandwidth
efficiency, simplicity, and minimum delay. Only one speech data
frame presents in each header-free payload format packet. None of
the payload header fields or ToC entries is present. The encoding
rate for the speech frame can be determined from the length of the
speech data frame, since there is only one speech data frame in each
header-free payload format.
The use of the RTP header fields for header-free payload format is
the same as the corresponding one for the octet-aligned payload
format. The detailed bit mapping of speech data packets permissible
for this payload format is described in Section 8 of [1]. Since the
header-free payload format is not compatible with AMR-WB RTP payload,
only non-interoperable modes of VMR-WB SHALL be used with this
payload format. That is, FT=0, 1, 2, and 9 SHALL NOT be used with
header-free payload format.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header [3] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ ONLY one speech data frame +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the mode of operation, using this payload format, is
decided by the transmitting (encoder) site. The default mode of
operation for VMR-WB encoder is mode 0 [1]. The mode change request
MAY also be sent through non-RTP means, which is out of the scope of
this specification.
6.3. Octet-Aligned Payload Format
6.3.1. Payload Structure
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 ...
+----------------+-------------------+----------------
6.3.2. The Payload Header
In octet-aligned payload format, the payload header consists of a
4-bit CMR, 4 reserved bits, and, optionally, an 8-bit interleaving
header, as shown below.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+- - - - - - - -
| CMR |R|R|R|R| ILL | ILP |
+-+-+-+-+-+-+-+-+- - - - - - - -
CMR (4 bits): This indicates a codec mode request sent to the speech
encoder at the site of the receiver of this payload. CMR value 15
indicates that no mode request is present, and other unused values
are reserved for future use.
The value of the CMR field is set according to the following table:
+-------+----------------------------------------------------------+
| CMR | VMR-WB Operating Modes |
+-------+----------------------------------------------------------+
| 0 | VMR-WB mode 3 (AMR-WB interoperable mode at 6.60 kbps) |
| 1 | VMR-WB mode 3 (AMR-WB interoperable mode at 8.85 kbps) |
| 2 | VMR-WB mode 3 (AMR-WB interoperable mode at 12.65 kbps) |
| 3 | VMR-WB mode 2 |
| 4 | VMR-WB mode 1 |
| 5 | VMR-WB mode 0 |
| 6 | VMR-WB mode 2 with maximum half-rate encoding |
| 7-14 | (reserved) |
| 15 | No Preference (no mode request is present) |
+-------+----------------------------------------------------------+
Table 2: List of valid CMR values and their associated VMR-WB
operating modes
R: This is a reserved bit that MUST be set to zero. The receiver
MUST ignore all R bits.
ILL (4 bits, unsigned integer): This is an OPTIONAL field that is
present only if interleaving is signaled out-of-band for the session.
ILL=L indicates to the receiver that the interleaving length is L+1,
in number of frame-blocks.
ILP (4 bits, unsigned integer): This is an OPTIONAL field that is
present only if interleaving is signaled. ILP MUST take a value
between 0 and ILL, inclusive, indicating the interleaving index for
frame-blocks in this payload in the interleave group. If the value
of ILP is found greater than ILL, the payload SHOULD be discarded.
ILL and ILP fields MUST be present in each packet in a session if
interleaving is signaled for the session.
The mode request received in the CMR field is valid until the next
CMR is received, i.e., until a newly received CMR value overrides the
previous one. Therefore, if a terminal continuously wishes to
receive frames in the same mode, x, it needs to set CMR=x for all its
outbound payloads, and if a terminal has no preference in which mode
to receive, it SHOULD set CMR=15 in all its outbound payloads.
If a payload is received with a CMR value that is not valid, the CMR
MUST be ignored by the receiver.
In a multi-channel session, CMR SHOULD be interpreted by the receiver
of the payload as the desired encoding mode for all the channels in
the session, if the network allows.
There are two factors that affect the VMR-WB mode selection: (i) the
performance of any CDMA link connected via a gateway (e.g., in a GW
to IP terminal scenario), and (ii) the congestion state of an IP
network. The CDMA link performance is signaled via the CMR field,
which is not used by IP-only end-points. The IP network state is
monitored using, for example, RTCP. A sender needs to select the
operating mode to satisfy both these constraints (see Section 7).
The encoder SHOULD follow a received mode request, but MAY change to
a different mode if the network necessitates it, for example, to
control congestion.
The CMR field MUST be set to 15 for packets sent to a multicast
group. The encoder in the speech sender SHOULD ignore mode requests
when sending speech to a multicast session but MAY use RTCP feedback
information as a hint that a mode change is needed.
If interleaving option is utilized, interleaving MUST be performed on
a frame-block basis, as opposed to a frame basis, in a multi-channel
session.
The following example illustrates the arrangement of speech frame-
blocks in an interleave group during an interleave session. Here we
assume ILL=L for the interleave group that starts at speech frame-
block n. We also assume that the first payload packet of the
interleave group is s and the number of speech frame-blocks carried
in each payload is N. Then we will have
Payload s (the first packet of this interleave group):
ILL=L, ILP=0,
Carry frame-blocks: n, n+(L+1), n+2*(L+1),..., n+(N-1)*(L+1)
Payload s+1 (the second packet of this interleave group):
ILL=L, ILP=1,
Carry frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1),..., n+1+
(N-1)*(L+1)
...
Payload s+L (the last packet of this interleave group):
ILL=L, ILP=L,
Carry frame-blocks: n+L, n+L+(L+1), n+L+2*(L+1), ..., n+L+
(N-1)*(L+1)
The next interleave group will start at frame-block n+N*(L+1). There
will be no interleaving effect unless the number of frame-blocks per
packet (N) is at least 2. Moreover, the number of frame-blocks per
payload (N) and the value of ILL MUST NOT be changed inside an
interleave group. In other words, all payloads in an interleave
group MUST have the same ILL and MUST contain the same number of
speech frame-blocks.
The sender of the payload MUST only apply interleaving if the
receiver has signaled its use through out-of-band means. Since
interleaving will increase buffering requirements at the receiver,
the receiver uses MIME parameter "interleaving=I" to set the maximum
number of frame-blocks allowed in an interleaving group to I.
When performing interleaving, the sender MUST use a proper number of
frame-blocks per payload (N) and ILL so that the resulting size of an
interleave group is less than or equal to I, i.e., N*(L+1)<=I.
The following example shows the ToC of three consecutive packets,
each carrying 3 frame-blocks, in an interleaved two-channel session.
Here, the two channels are left (L) and right (R), with L coming
before R, and the interleaving length is 3 (i.e., ILL=2). This makes
the interleave group 9 frame-blocks large.
Packet #1
---------
ILL=2, ILP=0:
+----+----+----+----+----+----+
| 1L | 1R | 4L | 4R | 7L | 7R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame Frame Frame
Block 1 Block 4 Block 7
Packet #2
---------
ILL=2, ILP=1:
+----+----+----+----+----+----+
| 2L | 2R | 5L | 5R | 8L | 8R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame Frame Frame
Block 2 Block 5 Block 8
Packet #3
---------
ILL=2, ILP=2:
+----+----+----+----+----+----+
| 3L | 3R | 6L | 6R | 9L | 9R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame Frame Frame
Block 3 Block 6 Block 9
6.3.3. The Payload Table of Contents
The table of contents (ToC) in octet-aligned payload format consists
of a list of ToC entries where each entry corresponds to a speech
frame carried in the payload, i.e., when interleaving is used, the
frame-blocks in the ToC will almost never be placed consecutive in
time. Instead, the presence and order of the frame-blocks in a
packet will follow the pattern described in 6.3.2.
+---------------------+
| list of ToC entries |
+---------------------+
A ToC entry for the octet-aligned payload format is as follows:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |Q|P|P|
+-+-+-+-+-+-+-+-+
The table of contents (ToC) consists of a list of ToC entries, each
representing a speech frame.
F (1 bit): If set to 1, indicates that this frame is followed by
another speech frame in this payload; if set to 0,
indicates that this frame is the last frame in this
payload.
FT (4 bits): Frame type index whose value is chosen according to
Table 3.
During the interoperable mode, FT=14 (SPEECH_LOST) and
FT=15 (NO_DATA) are used to indicate frames that are
either lost or not being transmitted in this payload,
respectively. FT=14 or 15 MAY be used in the non-
interoperable modes to indicate frame erasure or blank
frame, respectively (see Section 2.1 of [1]).
If a payload with an invalid FT value is received, the
payload MUST be discarded. Note that for ToC entries
with FT=14 or 15, there will be no corresponding speech
frame in the payload.
Depending on the application and the mode of operation
of VMR-WB, any combination of the permissible frame
types (FT) shown in Table 3 MAY be used.
Q (1 bit): Frame quality indicator. If set to 0, indicates that
the corresponding frame is corrupted. During the
interoperable mode, the receiver side (with AMR-WB
codec) should set the RX_TYPE to either SPEECH_BAD or
SID_BAD depending on the frame type (FT), if Q=0. The
VMR-WB encoder always sets Q bit to 1. The VMR-WB
decoder may ignore the Q bit.
P bits: Padding bits MUST be set to zero and MUST be ignored by
a receiver.
+----+--------------------------------------------+-----------------+
| FT | Encoding Rate |Frame Size (Bits)|
+----+--------------------------------------------+-----------------+
| 0 | Interoperable Full-Rate (AMR-WB 6.60 kbps) | 132 |
| 1 | Interoperable Full-Rate (AMR-WB 8.85 kbps) | 177 |
| 2 | Interoperable Full-Rate (AMR-WB 12.65 kbps)| 253 |
| 3 | Full-Rate 13.3 kbps | 266 |
| 4 | Half-Rate 6.2 kbps | 124 |
| 5 | Quarter-Rate 2.7 kbps | 54 |
| 6 | Eighth-Rate 1.0 kbps | 20 |
| 7 | (reserved) | - |
| 8 | (reserved) | - |
| 9 | CNG (AMR-WB SID) | 40 |
| 10 | (reserved) | - |
| 11 | (reserved) | - |
| 12 | (reserved) | - |
| 13 | (reserved) | - |
| 14 | Erasure (AMR-WB SPEECH_LOST) | 0 |
| 15 | Blank (AMR-WB NO_DATA) | 0 |
+----+--------------------------------------------+-----------------+
Table 3: VMR-WB payload frame types for real-time transport
For multi-channel sessions, the ToC entries of all frames from a
frame-block are placed in the ToC in consecutive order. Therefore,
with N channels and K speech frame-blocks in a packet, there MUST be
N*K entries in the ToC, and the first N entries will be from the
first frame-block, the second N entries will be from the second
frame-block, and so on.
6.3.4. Speech Data
Speech data of a payload contains one or more speech frames as
described in the ToC of the payload.
Each speech frame represents 20 ms of speech encoded in one of the
available encoding rates depending on the operation mode. The length
of the speech frame is defined by the frame type in the FT field,
with the following considerations:
- The last octet of each speech frame MUST be padded with zeroes at