Commit Graph

6 Commits

Author SHA1 Message Date
Harald Welte a7263b6474 Fix license headers.
We have licensed the code under GNU Afffero Public License,
and state that in the first paragraph as well as in the link
to the license.  However, a paragraph in the middle stated
"see the GNU General Public License", which is somewhat misleading.

Let's fix that.

Change-Id: I37e503b195fe43e1da42c080900504ca8e682e76
2024-02-17 10:21:30 +01:00
Vadim Yanitskiy b33502a39b csd_v110: handle empty/incomplete Uplink frames gracefully
Change-Id: I7cbf868df3ba5d390cea3d529eef26d18dbe55ab
Related: OS#1572
2023-08-26 04:11:33 +07:00
Vadim Yanitskiy 183c088864 csd_v110: properly set E1/E2/E3 for non-transparent data
Change-Id: Ie38c12e462654cd9fe83a0420bc8ea8b476214b8
Related: OS#1572
2023-08-26 03:12:03 +07:00
Vadim Yanitskiy 37e639cb8f csd_v110: fix comments in csd_v110_rtp_{en,de}code()
Change-Id: I6fee665e587bfa76058187e13f0cdafaea991940
Related: OS#1572
2023-08-26 03:10:20 +07:00
Vadim Yanitskiy ca418643b3 csd_v110_rtp_encode(): properly set E1/E2/E3 bits
The E1/E2/E3 bits are set based on out-of-band knowledge of the
current user data rate.  The actual bit values are defined in
3GPP TS 44.021, Figure 4 "Coding of data rates".

TODO: this is only valid for transparent services,
      for non-transparent services see 3GPP TS 48.020.
TODO: lchan->csd_mode is never set to the actual CSD mode...

Change-Id: I1a14597dff746cf975140b294400a2cc05badccd
Related: OS#1572
2023-07-30 20:29:12 +07:00
Vadim Yanitskiy d1f8f3429c l1sap: proper rate adaptation for CSD (RFC4040 'clearmode')
Since 95407f3f osmo-bts-trx supports scheduling all CSD specific
channel rates, however the rate adaptation was missing.

On the radio interface we deal with CSD-modified V.110 frames, which
need to be converted to normal 80-bit V.110 frames (RA1'/RA1), which
in turn need to be batched and sent in RFC4040 "clearmode" 160 octet
RTP payloads (RA1/RA2 as per I.460).

Note that this patch comments out TCH/F14.4 in bts_supports_cm_data(),
so that all channel allocations for this mode would be NACKed.  The
reason for this is that the rate adaptation functions for TCH/F14.4
are different than the RA1'/RA1 and the RA1/RA2.

For more information, see:

* 3GPP TS 44.021, section 8 (functions RA1'/RA1)
* ITU-T I.460, section 1.1 "Rate adaption of 8, 16 and 32 kbit/s streams"

Change-Id: I5e3701ad52d5d428fd02caff037881045f2d0a02
Related: OS#1572
2023-07-30 16:08:01 +07:00