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
In the most cases an ARFCN value is stored together with some
flags (e.g. DL/UL flag, DCS flag), so it should be taken into
account e.g. when printing. Let's use the proper naming.
Change-Id: I0b7634c80986dbff9d0da421c6a044cd36c9fd01
There is no need to check the range of timeslot number, which is
decoded from GSM 08.58 channel number (9.3.1) by applying 0x07
mask, because any result of this operation is always within
the correct range.
Change-Id: Ib84417099d303bd3ae3557f48a5c40b812c6cdfc
There is no helptext for the commandline options, which makes it
difficult for new users to use the program.
- Add commandline help
Change-Id: I8d04644342acd64432742f96e32dc9f2e0e91c20
To have bi-directional communication we can pass credentials to the
registry server and now we can register a callback when the registry
is sending data to us.
The callback needs to return if the fd should continue to be selected
as I found no way to push the userdata as parameter on the stack. Lua
code will look like:
local host, port = "www.osmocom.org", 80
local tcp = socket.tcp()
tcp:connect(host, port);
tcp:send("GET / HTTP/1.0\r\n\r\n");
local cb = function()
local s, status, partial = tcp:receive()
print(s)
if status == 'closed' then
tcp:close()
return 0
end
return 1
end
local foo = osmo.register_fd(tcp:getfd(), cb)
Change-Id: I8254bdda1df2f8fe0a5eac894b931e7de5b426df
Address sanitizer triggered when trying to chainload firmware:
==18466==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x631000027850 at pc 0x7f5b94cfb733 bp 0x7ffe33e1ae30 sp 0x7ffe33e1a5d8
READ of size 1014 at 0x631000027850 thread T0
#0 0x7f5b94cfb732 (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x79732)
#1 0x563db4293e6e in memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
#2 0x563db4293e6e in romload_prepare_block osmocom-bb/src/host/osmocon/osmocon.c:473
#3 0x563db429541f in handle_read_romload osmocom-bb/src/host/osmocon/osmocon.c:959
#4 0x563db429541f in serial_read osmocom-bb/src/host/osmocon/osmocon.c:1168
#5 0x7f5b94722c83 in osmo_fd_disp_fds libosmocore/src/select.c:217
#6 0x7f5b94722f84 in osmo_select_main libosmocore/src/select.c:257
#7 0x563db4293b1c in main osmocom-bb/src/host/osmocon/osmocon.c:1525
#8 0x7f5b942b9b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#9 0x563db4293c79 in _start (prefix/sbin/osmocon+0x1c79)
0x631000027850 is located 0 bytes to the right of 77904-byte region [0x631000014800,0x631000027850)
allocated by thread T0 here:
#0 0x7f5b94d60b50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50)
#1 0x563db4294d65 in read_file osmocom-bb/src/host/osmocon/osmocon.c:314
Change-Id: Ie2955e11dd1af75574536774ef7ddf88ddf1fe8b
virtphy uses UDP multicast to communicate with its osmo-bts-virtual
counterpart. At the momemnt SO_REUSEADDR is not applied for those
multicast connections because OSMO_SOCK_F_UDP_REUSEADDR is not set. This
makes prevents the proper function of UDP multicast.
- Make sure OSMO_SOCK_F_UDP_REUSEADDR is set
Change-Id: Ia1014ac5e0522e77178249cdc6398dec2168bffe
Depends: libosmocore I1399a428467ca12f1564a14eb8ffb294d4f59874
Related: OS#3497
osmocon.c: In function ‘read_file’:
osmocon.c:317:3: warning: ‘fd’ may be used uninitialized in this function
Change-Id: If07c58d5b55c18c05345607064eace02748935f8
Use osmo_clock_gettime() to read the monotonic clock instead
of gettimeofday() which could drift backwards.
This requires switching the scheduler clock from struct timeval
to struct timespec. Expand some variables to 64 bits in order
to keep types used in calculations compatible.
The previous implementation unconditionally subtracted microsecond
values from different time measurements, causing overflow if the
current measurement was taken in less of a fraction of a second
than the past measurement. Use timespecsub() for the subtraction
instead which accounts for fractions of a second correctly.
Change-Id: Ic93f90685c6d6dc28dfc4ad48c998e0eac113cf8
Related: OS#3467
This field of the logical channel state structure was not used at
all as there is nothing related to A-bis / RSL in trxcon itself.
Change-Id: Iec1abf777a74cf57deadafa95e2337cba5d02842
Alex Badea
Harald Welte
Philipp Maier