Project

General

Profile

Feature #2557

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

Added by laforge almost 3 years ago. Updated 5 months 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

History

#1 Updated by laforge almost 3 years ago

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

#2 Updated by laforge almost 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 almost 3 years ago

  • Target version set to Virtual GSM Load Testing

#4 Updated by laforge almost 3 years ago

  • Assignee set to laforge

#5 Updated by laforge almost 3 years ago

  • Priority changed from Normal to High

#6 Updated by laforge over 2 years ago

  • Priority changed from High to Normal

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

#7 Updated by laforge about 1 year ago

  • Priority changed from Normal to Low

#8 Updated by laforge 7 months 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 7 months ago

  • Category set to osmo-bts-virtual

#10 Updated by laforge 7 months 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 7 months 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 7 months ago

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

#13 Updated by laforge 7 months ago

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

#15 Updated by neels 5 months 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)