Project

General

Profile

Feature #2557

extend osmo-bts-virtual + GSMTAP with voice frame (TCH) support

Added by laforge over 3 years ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Urgent
Assignee:
Category:
osmo-bts-virtual
Start date:
10/06/2017
Due date:
% Done:

100%

Spec Reference:

Description

In order to have actual voice call user plane between osmo-bts-virt and virt_phy, we need to extend GSMTAP with a way to transport voice codec frames, and implement scheduling of rx/tx of such frames in osmo-bts-virtual.


Related issues

Related to Cellular Network Infrastructure - Feature #2558: Scripts to manage thousands of "mobile" and hundreds of osmo-bts-virtual instancesStalled10/06/2017

Precedes OsmocomBB - Feature #2556: Extend virt_phy and "mobile" with support for voice framesResolved10/09/201710/09/2017

Associated revisions

Revision 1d3e9de2 (diff)
Added by laforge about 1 year ago

gsmtap.h: Add definitions for voice inside GSMTAP

We so far are only able to transmit signalling data inside GSMTAP,
but not actual voice / user plane payload data.

we cannot use the existing TCHF/TCHH sub-types, as those are already
used [without further discrimination] for FACCH + SACCH Data on those
channels.

Instead, we will introduce a new GSMTAP_CHANNEL_VOICE sub-type, which
then will have the first byte for a sub-sub-type specifying the payload
format in detail.

Change-Id: If223020933b083fe359a2e8ff5fab1ce64a363d8
Related: OS#2557

Revision 20618cab (diff)
Added by laforge about 1 year ago

Add GSMTAP_CHANNEL_VOICE to gsmtap_gsm_channel_names[] value_string

In Change-Id If223020933b083fe359a2e8ff5fab1ce64a363d8 we introduced
GSMTAP_CHANNEL_VOICE, but we didn't add it to gsmtap_gsm_channel_names[]

Change-Id: I7ab696d3e0edb13632e048a9e05be03612d3d28c
Related: OS#2557

Revision 6773304d (diff)
Added by laforge about 1 year ago

gsmtap: Solve TCH / FACCH confusion once and for all

  • What we used to call TCH/F and TCH/H in gsmtap are actually only
    FACCH/F and FACCH/H, i.e. the signaling part of Bm/Lm channels
  • Give them proper names with backwards compatibility #define
  • Split VOICE into VOICE_F and VOICE_H. If we don't differentiate this,
    a receiver is not able to determine the RSL channel ID of a frame
    without looking at external state/context. That in turn has been a
    design feature of GSMTAP Um format so far, and programs like
    osmo-bts-virtual rely on it.

Change-Id: I952044a17334f35712e087dc41781805000aebc1
Related: OS#2557

History

#1 Updated by laforge over 3 years ago

  • Related to Feature #2556: Extend virt_phy and "mobile" with support for voice frames added

#2 Updated by laforge over 3 years ago

  • Related to Feature #2558: Scripts to manage thousands of "mobile" and hundreds of osmo-bts-virtual instances added

#3 Updated by laforge over 3 years ago

  • Target version set to Virtual GSM Load Testing

#4 Updated by laforge over 3 years ago

  • Assignee set to laforge

#5 Updated by laforge over 3 years ago

  • Priority changed from Normal to High

#6 Updated by laforge about 3 years ago

  • Priority changed from High to Normal

reducing priority as trxcon + osmo-bts-trx support voice.

#7 Updated by laforge almost 2 years ago

  • Priority changed from Normal to Low

#8 Updated by laforge about 1 year ago

There are already GSMTAP channel type enum values for TCHF and TCHH. They have just not been used so far in any of the related programs (Osmocom, wireshark, ...) - at least not that I know of.

We could simply put the RTP codec payload in those frames and use the length to determine the type (33 bytes for FR, 31 bytes for EFR, ...). However, I think that's a bit ugly.

So I'd vote for using the first octet as "sub-sub-type" field, which would then tell us
  • HR
  • FR
  • AMR (including AMR frame type like SID_FIRST, SID_UPDATE, ...)

followed by the actual payload in exactly the same order/length as we would have it in the payload of RTP frames. This way we can easily convert between RTP and GSMTAP-voice frames by siply stripping the GSMTAP header and pushing the RTP header or vice-versa.

I was wondering a bit if it made sense to include other parts of the RTP header, but sequence number or timestamp are already expressed in some form as the GSM frame number...

#9 Updated by laforge about 1 year ago

  • Category set to osmo-bts-virtual

#10 Updated by laforge about 1 year ago

  • Priority changed from Low to Urgent

Actually, we cannot use the exsiting TCHF/TCHH types, as those are already used [without further discrimination] for FACCH + SACCH Data on those channels.

Instead, we will introduce a new GSMTAP_CHANNEL_VOICE type, which then will have the first byte for specifyng the payload. My current proposal looks like this:

diff --git a/include/osmocom/core/gsmtap.h b/include/osmocom/core/gsmtap.h
index 35ba71e5..21b94433 100644
--- a/include/osmocom/core/gsmtap.h
+++ b/include/osmocom/core/gsmtap.h
@@ -82,8 +82,8 @@
 #define GSMTAP_CHANNEL_SDCCH   0x06
 #define GSMTAP_CHANNEL_SDCCH4  0x07
 #define GSMTAP_CHANNEL_SDCCH8  0x08
-#define GSMTAP_CHANNEL_TCH_F   0x09
-#define GSMTAP_CHANNEL_TCH_H   0x0a
+#define GSMTAP_CHANNEL_TCH_F   0x09    /* Actually, it's FACCH/F (signaling) */
+#define GSMTAP_CHANNEL_TCH_H   0x0a    /* Actually, it's FACCH/H (signaling) */
 #define GSMTAP_CHANNEL_PACCH   0x0b
 #define GSMTAP_CHANNEL_CBCH52  0x0c
 #define GSMTAP_CHANNEL_PDTCH   0x0d
@@ -91,6 +91,7 @@
 #define GSMTAP_CHANNEL_PDCH    GSMTAP_CHANNEL_PDTCH
 #define GSMTAP_CHANNEL_PTCCH   0x0e
 #define GSMTAP_CHANNEL_CBCH51  0x0f
+#define GSMTAP_CHANNEL_VOICE   0x10    /* voice codec payload (HR/FR/EFR/AMR) */

 /* GPRS Coding Scheme CS1..4 */
 #define GSMTAP_GPRS_CS_BASE    0x20
@@ -318,3 +319,26 @@ struct gsmtap_osmocore_log_hdr {
                uint32_t line_nr;/*!< line number */
        } src_file;
 } __attribute__((packed));
+
+/*! First byte of type==GSMTAP_TYPE_UM sub_type==GSMTAP_CHANNEL_VOICE payload */
+enum gsmtap_um_voice_type {
+       /*! 1 byte TOC + 112 bits (14 octets) = 15 octets payload;
+        *  Reference is RFC5993 Section 5.2.1 + 3GPP TS 46.030 Annex B */
+       GSMTAP_UM_VOICE_HR,
+       /*! 33 payload bytes; Reference is RFC3551 Section 4.5.8.1 */
+       GSMTAP_UM_VOICE_FR
+       /*! 31 payload bytes; Reference is RFC3551 Section 4.5.9 + ETSI TS 101 318 */
+       GSMTAP_UM_VOICE_EFR,
+       /*! 1 byte TOC + 5..31 bytes = 6..32 bytes payload; RFC4867 octet-aligned */
+       GSMTAP_UM_VOICE_AMR,
+       /* TODO: Revisit the types below; their usage; ... */
+       GSMTAP_UM_VOICE_AMR_SID_BAD,
+       GSMTAP_UM_VOICE_AMR_ONSET,
+       GSMTAP_UM_VOICE_AMR_RATSCCH,
+       GSMTAP_UM_VOICE_AMR_SID_UPDATE_INH,
+       GSMTAP_UM_VOICE_AMR_SID_FIRST_P1,
+       GSMTAP_UM_VOICE_AMR_SID_FIRST_P2,
+       GSMTAP_UM_VOICE_AMR_SID_FIRST_INH,
+       GSMTAP_UM_VOICE_AMR_RATSCCH_MARKER,
+       GSMTAP_UM_VOICE_AMR_RATSCCH_DATA,
+};

#11 Updated by laforge about 1 year ago

  • Assignee changed from laforge to neels

pushed the patch as https://gerrit.osmocom.org/c/libosmocore/+/17289

I doubt I'll have time to work on it any time soon, assigning to neels to take over

#12 Updated by laforge about 1 year ago

  • Related to deleted (Feature #2556: Extend virt_phy and "mobile" with support for voice frames)

#13 Updated by laforge about 1 year ago

  • Precedes Feature #2556: Extend virt_phy and "mobile" with support for voice frames added

#15 Updated by neels about 1 year ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)