Project

General

Profile

Actions

Feature #2557

closed

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

Added by laforge over 6 years ago. Updated almost 4 years 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

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

Actions
Actions #1

Updated by laforge over 6 years ago

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

Updated by laforge over 6 years ago

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

Updated by laforge over 6 years ago

  • Target version set to Virtual GSM Load Testing
Actions #4

Updated by laforge over 6 years ago

  • Assignee set to laforge
Actions #5

Updated by laforge over 6 years ago

  • Priority changed from Normal to High
Actions #6

Updated by laforge about 6 years ago

  • Priority changed from High to Normal

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

Actions #7

Updated by laforge over 4 years ago

  • Priority changed from Normal to Low
Actions #8

Updated by laforge about 4 years 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...

Actions #9

Updated by laforge about 4 years ago

  • Category set to osmo-bts-virtual
Actions #10

Updated by laforge about 4 years 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,
+};

Actions #11

Updated by laforge about 4 years 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

Actions #12

Updated by laforge about 4 years ago

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

Updated by laforge about 4 years ago

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

Updated by neels almost 4 years ago

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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)