Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I61c058eb1c6a5d2a8acc295367eea51391ec6640
|
|
Using both MNCC_FRAME RECV/DROP messages, an external MNCC
application could enable / disable forwarding of the traffic
frames from L1 through MNCC-socket.
Now it can be done by user from the VTY configuration (see
'io-target' of 'audio' section), so there is no need to
control this from outside.
Change-Id: I41a0c9bc44b3ca6784f4190931773637f9fab40c
|
|
This message is used to negotiate MNCC protocol version, and also
in order to make sure that the sutructure alignment is equivalent
for both sides.
Change-Id: I7c5d8aa17540dd61bbe003a6468d97ecea415636
|
|
Change-Id: I173ca8df6ca3bb8b462b54b4893e382ef0f7d723
|
|
Change-Id: I4e850d2637a338032395cedd5ad540d61899eb75
|
|
Change-Id: If8f391b171155f73da4ed4ba76a49b6ef63bb89f
|
|
This change introduces a new feature of the mobile application -
audio I/O support, which allows one to speak right from PC running
mobile through its ordinary mic and speakers.
The audio I/O is based on GAPK library, which relays on ALSA sound
framework. The API of GAPK implies to use the processing queues
(chains), which basically consist of a source block, several
processing blocks, and a sink block. So, there are two voice
processing chains:
- 'pq_audio_source' (voice capture -> frame encoding),
- 'pq_audio_sink' (frame decoding -> voice playback).
Both of them exchange frames from two dedicated buffers:
- 'tch_fb_ul' - a buffer for to be played DL TCH frames,
- 'tch_fb_dl' - a buffer for encoded UL TCH frames.
In its turn, both buffers are served by a new gapk_io_dequeue()
function, which is being called within the mobile_work() loop.
Change-Id: Ib86b0746606c191573cc773f01172afbb52f33a9
|
|
Change-Id: I37241555cd648a8e2b57fa072c708f93cd1ba5a9
|
|
Change-Id: I024e13c0f66ae1e42b0c8e2ff77874fcb883e85a
|
|
Change-Id: I941899ab27282a495f965ae9a0f41076dceef953
|
|
It was assumed that only FR frames (with magic 0xd) can be carried
by the L1CTL_TRAFFIC messages, but there are also EFR, HR, and AMR
frames, and dropping them is not a good idea.
Change-Id: I4b7b85d94f11deb7525b63f3549a182c6e76da08
|
|
At the moment, both 'l1ctl_traffic_req' and 'l1ctl_traffic_ind'
don't have any fields, but in the near future they may be
modified to carry some important information.
Let's restore this header in the L1CTL_TRAFFIC messages.
Change-Id: I8074527149de63655e33dbe3ad7c413d3f8af2b2
|
|
Unlike the LAPDm messages, traffic frames may have different
length. Instead of having a buffer with fixed length, let's
use flexible array member. This would allow one to calculate
a frame length using the MSGB API (i.e. msgb_l3len()).
Change-Id: I119fa36c84e95c3003d57c19e25f8146ed45c3c6
|
|
Change-Id: I06e84ad47bafd4676af0e136b825e77471587b23
|
|
According to 3GPP TS 04.08, section 3.4.6.1.3 "Abnormal cases"
of "channel mode modify procedure", if the MS doesn't support
the indicated channel mode, it shall retain the old mode and
return the associated channel mode information in the
ACKNOWLEDGE message.
Previously, if an indicated mode is not supported, we used to
indicate the 'CHAN_MODE_UNACCT' RR case without sending the
ACKNOWLEDGE message. Also, the result of gsm48_rr_set_mode()
was ignored. Let's fix this!
Change-Id: I952436ec796273e56341f9d3492b4a3b3a5dc410
|
|
Change-Id: I45212cd02ac50d0d363918709720e997500e45a9
|
|
The CHANNEL MODE MODIFY message only applies to TCH channels,
and in general should not arrive on non-traffic channels. Let's
print error message if this happens in order to facilitate
finding possible bugs.
Change-Id: I4ab63c4ae4262c8166de37e4873fc3f1b8ec6fe7
|
|
The rsl_dec_chan_nr() may fail to decode RSL channel number, so
the 'ch_type' variable would be uninitialized. Let's check rc.
Change-Id: I9ab18bdaf41a29fcd32a7060668ef9db07b8cf7e
|
|
Change-Id: I615e89bdd7e1cc01b3258fefa26f7ab5705ae8cc
|
|
In the prevoius change a new configuration option was introduced
as a part of new 'audio' node - 'io-target'. This change makes it
to take an effect, instructing the L1 to use one of the following
possible TCH frame I/O targets:
- gapk - build-in (WIP) GAPK-based audio back-end (default);
- hardware - L1 hardware (e.g. Calypso DSP);
- socket - External MNCC application (e.g. LCR).
Change-Id: I2a36d9c30da6746995dcea3a33cb13e0d2f6549a
|
|
This change introduces a new node named 'AUDIO', which is intended
to organize some audio related settings, such as:
- io-target - TCH frame I/O back-end (e.g. gapk, hardware);
- alsa-output-dev - ALSA playback (i.e. speakers) device name;
- alsa-input-dev - ALSA recording (i.e. mic) device name.
The last two are actual when 'io-target' is set to 'gapk'.
For now, all introduced parameters don't affect anything.
Change-Id: I62cd5ef22ca2290fcafe65c78537ddbcb39fb8c6
|
|
Change-Id: I5c3e8553f9bca2ca2e1bf17ee5934e04bd12f605
|
|
Since GAPK has became a shared library - libosmogapk, it can be
used for the voice capture / playback directly on the host side.
This change adds the library as a dependency, and links
the mobile application against it.
Change-Id: I47054f32fec6780bdbe6f73b82aa446c4c7c1df4
|
|
Change-Id: I309d94c4a381c21486e5b424c9504ea6d272af05
|
|
Since the mobile application is potentionally able to work with
multiple MS instances, it's better to have a possibility to
choose an MNCC (Call Control) handler per each MS separately.
This change cleans up the code, removing a dedicated command-line
option '-m' intended for enabling extarnal MNCC. Now it's possible
to set an MNCC-handler for each MS via VTY interface and settings.
The following MNCC-handlers are available:
- mobile - build-in MNCC-handler (default);
- socket - external MNCC-handler via UNIX-socket (e.g. LCR);
- dummy - dummy handler without CC support.
Change-Id: I2df91c7a79ba5c39bc6ceae900ef649129dd0346
|
|
Previously the MNCC socket path was generated automatically,
using concatenation of the '/tmp/ms_mncc_' prefix and MS name.
Let's allow user to specify this manually, keeping a similar
generation method for default value.
Change-Id: I643356ac579bc5e765f668265ec803b22a73739c
|
|
This change extends sched_trx_chan_nr2pchan_config() with Osmocom
specific cbits related to CBCH, so now one can to decode
CBCH channels in dedicated mode (see L1CTL_DM_EST_REQ).
Change-Id: I9347c45638223cac34f4b48eb736e51a5055a36f
|
|
According to GSM TS 05.02, there are two ways to enable CBCH:
a) replace sub-slot number 2 of CCCH+SDCCH/4 (comb. V),
b) replace sub-slot number 2 of SDCCH/8 (comb. VII).
Unlike SDCCH/8 (case b), CCCH+SDCCH/4 can be allocated on TS0
only, and shall not use frequency hopping. This means that
implementing CBCH support on SDCCH/8 would require much more
efforts than on combined CCCH+SDCCH/4, as in last case CBCH
messages can be received without the need to switch from
idle to dedicated mode.
This change introduces a new ccch_mode item, which should be
used by the higher layers to indicate presence of CBCH channel
on C0/TS0, so the PHY would enable decoding of CBCH messages
on CCCH+SDCCH/4 (case a) in idle mode.
Regarding to CBCH on SDCCH/8 (case b), it makes sense to
extend the 'l1ctl_dm_est_req', so it would be handled in
dedicated mode on request from the higher layers.
Change-Id: Ia94ebf22a2ec439dfe1f31d703b832ae57b48ef2
|
|
According to GSM TS 05.02, section 3.3.5, Cell Broadcast Channel
(CBCH) is a downlink only channel, which is used to carry the
short message service cell broadcast (SMSCB). CBCH is optional,
and uses the same physical channel as SDCCH. More precisely,
CBCH replaces sub-slot number 2 of SDCCH channels when enabled.
This change introduces the CBCH enabled multi-frame layouts,
and two separate logical channel types:
- GSM_PCHAN_CCCH_SDCCH4_CBCH (lchan TRXC_SDCCH4_CBCH),
- GSM_PCHAN_SDCCH8_SACCH8C_CBCH (lchan TRXC_SDCCH8_CBCH).
Both logical channels are separately identified using
the following Osmocom specific cbits:
- TRXC_SDCCH4_CBCH - 0x18 (0b11000),
- TRXC_SDCCH8_CBCH - 0x19 (0b11001).
The reason of this separation is that we somehow need to
distinguish between CBCH on C0/TS0, and CBCH on CX/TS0.
Unlike TRXC_SDCCH8_CBCH, TRXC_SDCCH4_CBCH is enabled
automatically (TRX_CH_FLAG_AUTO), so CBCH messages
can be decoded on C0 while being in idle mode.
Change-Id: Iad9905fc3a8a012ff1ada26ff95af384816f9873
|
|
According to GSM TS 05.02, section 3.3.5, Cell Broadcast Channel
(CBCH) is a downlink only channel, which is used to carry the
short message service cell broadcast (SMSCB). CBCH is optional,
and uses the same physical channel as SDCCH. More precisely,
CBCH replaces sub-slot number 2 of SDCCH channels when enabled.
This change introduces the following CBCH related tasks:
- MF_TASK_SDCCH4_CBCH (CBCH on C0/TS0 SDCCH/4),
- MF_TASK_SDCCH8_CBCH (CBCH on SDCCH/8),
which are identified using the following Osmocom specific cbits:
- MF_TASK_SDCCH4_CBCH - 0x18 (0b11000),
- MF_TASK_SDCCH8_CBCH - 0x19 (0b11001).
The only way to enable these tasks at the moment is to send
L1CTL_DM_EST_REQ message with required cbits and tn.
Change-Id: I1d7f02cba1cd8f6527360589d2d2747b6426f78b
|
|
The mframe_task2chan_nr() is used to get the channel number
(encoded according to 08.58 Chapter 9.3.1) corresponding to
a given multi-frame task type.
It makes sense to at least print some debug message in cases
when there is no matching channel number for a given task type.
Change-Id: I34587b6c67015513de35d85a7a3291f452ee7f3b
|
|
The 'ccch_mode' enum from 'l1ctl_proto.h' to be extended in the
near future in order to reflect persistence of CBCH. Thus it
should be handled in a switch statement.
Change-Id: I75e3b8deac1da296efb178e65ff6992b5c407b80
|
|
According to GSM TS 08.58, chapter 9.3.1, channel number 0x08
describes sub-slot number 0 of SDCCH/8+ACCH. This is definitely
wrong. In OsmoBTS we use an Osmocom specific extension for packet
switched channels - 0xc0, so let's use it here too.
Change-Id: I11925408d6e63baf1eac880839ecd717843fba6a
|
|
In some conditions it's required to maintain continuous burst
transmission (e.g. on C0). If there is nothing to transmit at
a given moment, either a LAPDm func=UI fill frame,
or a "dummy" Paging Request is used.
In case of 'ccch_scan' application, they are useless.
Let's detect and omit them.
Change-Id: I6ccecb1a78bdac3e467bdc14b7a01afbe17aa53c
|
|
Change-Id: I81d6558525e7f68c4fcd6c6272224d58532e2efb
|
|
Change-Id: Ic88f5d4b263610a376bbb9729e882097393ef2be
|
|
Change-Id: I8c2594920fcad8a3e346b938bd0c20409f4d01c9
|
|
Change-Id: I03da1329501ce9b3c5cca49a1654ba68e9bb6a98
|
|
By definition, 'ccch_scan' application is intended to be used for
monitoring of CCCH channels on C0/TS0. There is no need to send
RACH requests, therefore there is no need to care about the
mobile allocation from SI1 message.
Most likely, this "dead" code was copy-pasted from mobile
application. Let's clean it up!
Change-Id: I7c2f47cbc825a5e5a50863d842729d3d8408b9dd
|
|
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
|
|
Change-Id: I553b4cc39b2efd7b60346160c57f01ee4cf066be
|
|
Enforcing pointer to a 'trx_instance' structure is not flexible,
because it is used as parent talloc context only.
Change-Id: I5ab2ef5cea76f955bf72ef54541b3b75cdc2d23f
|
|
Having access to a logical channel state is required by the
follow-up change, which will introduce a separate function
for dequeuing SACCH primitives.
Change-Id: Ibde0acf8e6be224b1007be707a636eaad68c8d36
|
|
Change-Id: I863fb668500b2010dfef7a63217255fd010c06d7
|
|
Change-Id: I02bc581afb5a76c51fdef50ed40e2669c3eb3f2e
|
|
Same as the "network search" VTY command but implemented as primitive
and exposed to LUA.
Change-Id: I096233a2ca9dd7daa358cebed0523cb8c0dbf593
|
|
Add missing dependencies to make this file be includeable as the
only file.
Change-Id: I05b5f689f389b89deb5ff49507486b246111fc59
|
|
This makes packaging the binary for the gsm tester more easy.
Change-Id: Ibe572a4c17871785b623e70acc7f5da056f945e5
|
|
Change-Id: Ibb2a0850692c5ff86b13b820af10b12085589e67
|
|
Unlike xCCH, TCH/H channels are using block diagonal interleaving,
so every single burst carries 57 bits of one traffic frame, and 57
bits of another one. Moreover, unlike TCH/F where both traffic
and FACCH/F frames are interleaved over 8 bursts, a FACCH/H is
interleaved over 6 bursts, while a traffic frame is interleaved
over 4 bursts.
This is why a TCH/H burst transmission can't be initiated on
an arbitrary TDMA frame number. It shall be aligned as of
stated in GSM 05.02, clause 7, table 1.
This change introduces two basic functions:
- sched_tchh_block_map_fn - checks if a TCH/H block transmission
can be initiated / finished on a given frame number
and a given channel type;
- sched_tchh_block_dl_first_fn - calculates TDMA frame number of
the first burst using given frame number of the last burst;
and some auxiliary wrappers to simplify the usage of
sched_tchh_block_map_fn().
Change-Id: Iaf4cb33f1b79df23f8a90c8b14ebe0cd9907fbb9
|