Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-01-26T22:03:21ZOpen Source Mobile Communications
Redmine OsmocomBB - Feature #6348 (New): virtphy: add Circuit Switched Data (CSD) supporthttps://osmocom.org/issues/63482024-01-26T22:03:21Zfixeria
<p>Since recently, Calypso PHY and trxcon support data traffic channels needed for CSD:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/34694">https://gerrit.osmocom.org/c/osmocom-bb/+/34694</a> firmware/layer1: handle CSD related channel modes<br /><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/32922">https://gerrit.osmocom.org/c/osmocom-bb/+/32922</a> trxcon/l1sched: implement CSD scheduling support</p>
<p>For the sake of completeness, let's add data traffic channel support to virtphy.</p> OsmocomBB - Feature #6347 (New): mobile: support data calls @ 300 bps and 1200/75 bps (TCH/[FH]2.4)https://osmocom.org/issues/63472024-01-26T21:54:56Zfixeria
<p>Currently we implement data rates starting from <code>2400 bps</code> and higher, but not <code>300 bps</code> and <code>1200/75 bps</code>.<br />The problem is that those rates are not specified in ITU-T Rec. V.110, which defines <code>600 bps</code> as the minimum synchronous data rate.</p>
<p>According to 3GPP TS 44.021, section 4.1, the <code>300 bps</code> user data signalling rate shall be adapted to a synchronous <code>600 bps</code> stream.<br />Also, "Incoming asynchronous data is padded by the addition of stop elements" -- this means that we pad bits after stop bit(s):</p>
<pre>
pad bits = ((600 / 300) - 1) * (start + data + parity + stop)
</pre>
<p>This logic most likely needs to be implemented in the soft-UART module of libosmocore.git.</p> OsmocomBB - Feature #6346 (New): mobile: support data calls @ 14400 bps (TCH/F14.4)https://osmocom.org/issues/63462024-01-26T21:44:42Zfixeria
<p>Currently we implement <code>TCH/[FH]2.4</code>, <code>TCH/[FH]4.8</code>, and <code>TCH/F9.6</code>, but not <code>TCH/F14.4</code>. Calypso PHY should be capable of doing <code>TCH/F14.4</code>, as well as trxcon. However, the rate adaptation functions for <code>TCH/F14.4</code> are different from those we implemented so far. According to 3GPP TS 48.020, chapter 10, we would need to implement <code>RA1'/RAA'</code> and <code>RA1'/RAA"</code>. Other relevant specs: 3GPP TS 44.021 and 3GPP TS 48.060.</p> OsmoMSC - Bug #6330 (New): Incorrect handling of V.120 data callshttps://osmocom.org/issues/63302024-01-18T15:02:29Zfixeria
<p>Current osmo-msc (8236184ef05e5b10505bbb3189357d2050bbdc5d) fails to connect a V.120 data call, see the attached PCAP.</p>
<p>How to reproduce:</p>
<ul>
<li>find phone(s)/modem(s) supporting V.120 data calls
<ul>
<li>the result of <code>AT+CBST=?</code> should contain one of V.120 rates: 39, 43, 47, 48</li>
<li>most Sony Ericsson phones/modems can do V.120: <code>+CBST: (0,7,12,14-17,39,43,47-51,71,75,79-84),(0,4),(1)</code></li>
</ul>
</li>
<li>configure phone(s)/modem(s) to use V.120, for example: <code>AT+CBST=39,0,1</code> for 9600 bps</li>
<li>initiate a data call, for example: <code>ATD15843</code></li>
</ul>
<p>In my case (using SE K800), the call is aborted due to Assignment Failure, because osmo-msc sends weird Assignment Command:</p>
<pre>
GSM A-I/F BSSMAP - Assignment Request
Message Type Assignment Request
Channel Type - (Data)
Element ID: 0x0b
Length: 3
0000 .... = Spare bit(s): 0x00
.... 0010 = Speech/Data Indicator: Data (2)
.000 1010 = Channel rate and type: Full or Half rate TCH channel, Full rate preferred, changes allowed also after first channel allocation as a result of the request (10)
0... .... = Extension: Last Octet
.0.. .... = Service: Transparent
..01 0010 = Rate: 2.4kbit/s
...
</pre>
<p><code>2.4kbit/s</code> / <code>Transparent</code> is definitely not what the calling phone requested, it should be <code>9.6kbit/s</code> / <code>Non-transparent</code>.</p>
<p>Below is how the Bearer Capability looks like for <code>AT+CBST=39,0,1</code>:</p>
<pre>
Bearer Capability 1 - (Full rate support only MS)
Element ID: 0x04
Length: 12
Octet 3
1... .... = Extension: No Extension
.01. .... = Radio channel requirement: Full rate support only MS
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .001 = Information transfer capability: Unrestricted digital information (0x1)
Octet 4
1... .... = Extension: No Extension
.1.. .... = Compression: Allowed
..00 .... = Structure: Service data unit integrity (0)
.... 1... = Duplex mode: Full
.... .0.. = Configuration: Point-to-point
.... ..0. = NIRR: No meaning is associated with this value
.... ...0 = Establishment: Demand
Octet 5
0... .... = Extension: Extended
.00. .... = Access Identity: Octet identifier (0)
...1 1... = Rate Adaption: Other rate adaption (see octet 5a) (3)
.... .001 = Signalling Access Protocol: According to ITU-T Rec. Q.920 and ITU-T Rec. Q.930 (1)
Octet 5a
0... .... = Extension: Extended
.00. .... = Other ITC: Restricted digital information (0)
...0 0... = Other Rate Adaption: According to ITU-T Rec. V.120 (0)
.... .000 = Spare bit(s): 0
Octet 5b
1... .... = Extension: No Extension
.1.. .... = Rate Adaption Header: Included
..1. .... = Multiple frame establishment support in data link: Supported
...1 .... = Mode of operation: Protocol sensitive
.... 0... = Logical link identifier negotiation: Default, LLI=256 only
.... .0.. = Assignor/Assignee: Message originator is default assignee
.... ..0. = In band/Out of band negotiation: Negotiation is done in-band using logical link zero
.... ...0 = Spare bit(s): 0
Octet 6
0... .... = Extension: Extended
.01. .... = Layer 1 Identity: Octet identifier
...0 000. = User information layer 1 protocol: Default layer 1 protocol
.... ...1 = Synchronous/asynchronous: Asynchronous
Octet 6a
0... .... = Extension: Extended
.0.. .... = Number of Stop Bits: 1
..0. .... = Negotiation: In-band negotiation not possible
...1 .... = Number of data bits excluding parity bit if present: 8
.... 0101 = User rate: 9.6 kbit/s (according to ITU-T Rec. X.1 and ITU-T Rec. V.110)
Octet 6b
0... .... = Extension: Extended
.11. .... = V.110/X.30 rate adaptation Intermediate rate: 16 kbit/s (3)
...0 .... = Network independent clock (NIC) on transmission (Tx): does not require to send data with network independent clock
.... 0... = Network independent clock (NIC) on reception (Rx): cannot accept data with network independent clock
.... .011 = Parity information: None (3)
Octet 6c
0... .... = Extension: Extended
.01. .... = Connection element: Non transparent (RLP) (1)
...0 0000 = Modem type: None
Octet 6d
0... .... = Extension: Extended
.00. .... = Other modem type: No other modem type specified in this field (0)
...0 0001 = Fixed network user rate: 9.6 kbit/s (according to ITU-T Rec. X.1 and ITU-T Rec. V.110)
Octet 6e
0... .... = Extension: Extended
.1.. .... = Acceptable channel codings (TCH/F14.4): Acceptable
..0. .... = Acceptable channel codings (Spare): False
...1 .... = Acceptable channel codings (TCH/F9.6): Acceptable
.... 0... = Acceptable channel codings (TCH/F4.8): Not Acceptable
.... .001 = Maximum number of traffic channels: 1 TCH
Octet 6f
1... .... = Extension: No Extension
.000 .... = UIMI, User initiated modification indication: not allowed/required/applicable (0)
.... 0001 = Wanted air interface user rate: 9.6 kbit/s (1)
</pre> OsmoBTS - Feature #6167 (New): csd_v110: implement rate adaptation for TCH/F14.4https://osmocom.org/issues/61672023-09-01T11:58:07Zfixeria
<p>We do implement scheduling of TCH/F14.4 in osmo-bts-trx, however the rare adaptation is missing. This is why current osmo-bts-trx would NACK CHANnel ACTIVation attempts for this data rate. The rate adaptation functions for TCH/F14.4 are different from the ones employed for TCH/F9.6, TCH/F4.8, and TCH/F2.4. According to 3GPP TS 48.020, chapter 10, we would need to implement RA1'/RAA' and RA1'/RAA". Other relevant specs: 3GPP TS 44.021 and 3GPP TS 48.060.</p> OsmoMSC - Bug #6152 (In Progress): built-in MNCC: forward the @Low layer compatibility I@ IE to t...https://osmocom.org/issues/61522023-08-27T18:28:35Zfixeria
<p>The <code>Low layer compatibility I</code> IE is usually present in mobile-originated (CC) Setup messages related to date calls (CSD). According to 3GPP TS 24.008, section 9.3.23.1.7, this IE shall be included in the mobile-terminated (CC) Setup message if the calling user specified it. Currently this IE is simply ignored by the built-in osmo-msc's MNCC and not forwarded to the called party.</p>