L1CTL implementation (i.e. l1ctl.c) is not a good place for the
SIM specific stuff. Let's move it to the proper place (i.e. sim.c).
As a bonus, this change fixes a possible problem of loosing the
cached APDUs if two or more L2&3 applications are using a single
LAPDm connection. The APDU buffer is dedicated per MS now.
Change-Id: I564c610e45aa3b630ca5d1ec6bc1cace0dc9c566
Previously the wildcard address (i.e. '0.0.0.0') was hard-coded
as the bind address of TRX interface. Let's make it configurable
by introducing a command line option.
Note that the '--trx-ip' option was deprecated by '--trx-remote',
because it isn't clean whether it is remore or local address. It
still can be used, but was removed from help message.
Change-Id: Ic2f43632cc57bb6f722eba05219e438f97fecb95
Since FakeTRX is a proxy, it basically emulates transceiver for
both osmo-bts-trx and trxcon, hence there are two separate and
independent control interfaces (usually, ports 6701 and 5701).
All simulation commands (see 'FAKE_*') are usually implemented
on both interfaces separately:
- ctrl_if_bb.py - simulation commands affecting Uplink,
- ctrl_if_bts.py - simulation commands affecting Downlink.
This change introduces the 'FAKE_RSSI' command for both CTRL
interfaces in two variations:
- absolute: CMD FAKE_RSSI <BASE> <THRESH>
- relative: CMD FAKE_RSSI <+-BASE_DELTA>
where 'THRESH' affects optional value randomization.
Change-Id: Ic01c31fb0304345dd7337c3ee1c7ee3c2d3e8460
Almost all handlers for received L1CTL messages are also affected
by the bug fixed in I7fe2e00bb45ba07c9bb7438445eededfa09c96f3. In
short, they do verify the length of 'msg->l2h' or 'msg->l3h', but
not the 'msg->l1h'. Let's fix this, and also add missing checks.
Change-Id: I866bb5d97a1cc1b6cb887877bb444b9e3dca977a
As we assign the payload following L1CTL header to 'msg->l1h',
it makes sense to avoid possible naming confusion.
Change-Id: I5d21ca8664b3445f472d3ffde90d0e11805dcb16
The actual L1CTL header is pointed by 'msg->l1h', not 'l2h'!
Since msg->l2h is NULL (because nobody set it), the result of
msgb_l2len() would always be bigger than size of L1CTL header,
as it is calculated in the following way:
return msgb->tail - (uint8_t *)msgb_l2(msgb);
So, in case if 'msg->l2h' is NULL, it turns into:
return msgb->tail - 0;
Change-Id: I7fe2e00bb45ba07c9bb7438445eededfa09c96f3
In l1ctl_recv() we actually expect to 'see' the L1CTL header
instead of the DL info header. Let's fix this.
Change-Id: Ic7d017bef04f3c186565d5dade36959df1019bd8
There is no need to keep the L1CTL header in messages being sent
towards the upper layers, but the L1 info header can be used by
L2&3 to obtain some information, e.g. TDMA frame number.
Change-Id: Id64249f1b7a1c2be578263ba62aa195c452ab7e8
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
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
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
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
The 'normal' math operations, such as addition and substraction,
are not applicable for TDMA frame numbers because they may result
in out-of-range values.
Having TDMA frame math helpers in a single place would allow
one to avoid possible out-of-range result mistakes.
Change-Id: Ibb66ba846cc3d6c2eaa88414569e5f3751128047
GSM48_CMODE_SIGN means 'signaling only', so we shall not send
bad frame indications in this state. Instead, it makes sense
to send dummy L2 frames like we do for xCCH channels.
Change-Id: Ie39d53522cafab265099076b3194fa96aff217ba
Despite the correct range of Timing Advance value is [0..63],
there is a special feature in OsmocomBB which allows one to
simulate the distance between both MS and a BTS by playing
with the signal delay.
So, let's drop the range limitation.
Change-Id: I8fd2a2ab7784b38bde5ebcfd0359b7e2cb53f5a7
Despite the correct range of Timing Advance value is [0..63],
there is a special feature in OsmocomBB which allows one to
simulate the distance between both MS and a BTS by playing
with the signal delay.
This is why a signed 'int8_t' type is used in L1CTL protocol.
No need to limit the range, just forward it to TRX.
Change-Id: I06774b315b8451bf14083da6b2849d6e8594abc8
Despite the correct range of Timing Advance value is [0..63],
there is a special feature in OsmocomBB which allows one to
simulate the distance between both MS and a BTS by playing
with the signal delay.
It was discovered that l1ctl_tx_param_req() is using an unsigned
'uint8_t' type for Timing Advance value, while other code and
L1CTL protocol is using signed 'int8_t'. This may result in
distortion of negative values, so let's fix this!
Change-Id: I6ee42b5fa2ca9ebe187f0b933465c49f840a55c2
I am not sure we need the both control commands, as every burst
on DATA interface has a header that includes TX power.
Change-Id: Id14603e71df6dedb5a843bb3e20a320192dbca3d
Let's differentiate between 'expected' unimplemented messages
like L1CTL_NEIGH_PM_REQ and truly unknonw message types.
Change-Id: Id76993056fb514e6fb0242d505205316c61bb965
A BSC may allocate a dedicated channel on any ARFCN, not necessary
on the same one where a mobile station has requested this channel.
For some reason, the ARFCN info of L1CTL_DM_EST_REQ message was
not handled by trxcon. Let's fix this.
Related: OS#3526
Change-Id: I16ed5c64236c159bfa39002b05094c1f6c171f6b
We don't need to hand-code unix domain socket initialization but
can simply use our library function for it. As an added benefit,
the library code already contains corner case handling for non-NUL
terminated unix domain socket path.
Change-Id: I57c724c78dbbbce0546ebe914e370f32c8c89703
We don't need to hand-code unix domain socket initialization but
can simply use our library function for it. As an added benefit,
the library code already contains corner case handling for non-NUL
terminated unix domain socket path.
Change-Id: Iedcec4591cf0fcbd6f956ed022169eae10a9b16e
We don't need to hand-code unix domain socket initialization but
can simply use our library function for it. As an added benefit,
the library code already contains corner case handling for non-NUL
terminated unix domain socket path.
Change-Id: I3ab69a971be555c9f9b5b7a7e5da53008a119504
Vadim Yanitskiy
Pau Espin
Harald Welte