The underlying L1 implementation uses both chan_nr and link_id to
determine a logical channel for sending an Access Burst. If not
set (both 0x00), RSL_CHAN_RACH is assumed. Indicate it implicitly.
Change-Id: Ia40f67920bd712e572b8ea5219eb83064106bd5d
For more information, see 3GPP TS 44.014, sections:
- 5.1 "Single-slot TCH loops", and
- 8 "Message definitions and contents".
This feature has nothing to do with the Mobility Management, so
let's handle GSM48_PDISC_TEST messages in the Radio Resources
layer implementation (gsm48_mm.c -> gsm48_rr.c).
Change-Id: If8efc57c7017aa8ea47b37c472d1bbb1914389ca
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
Previously, the L1CTL_CRYPTO_REQ message contained only a ciphering
algorithm and actual Kc key to be used. The key length was
calculated manually using the MSGB API.
Let's avoid manual calculations here, as it may cause unexpected
behavior if the message structure is changed. Also, let's fill
the UL header with minimal information about a channel, which
is going to be encrypted.
Change-Id: I5fab079907c5276322d3ec2b46cab81f10c7ed09
As Dieter points out, this drastically improves the resiliance to high
receive levels on the C155. We cannot blindly assume a received signal
level of -85 dBm if the BTS is 2m away and we actually receive -40 dBm.
This patch extends the L1CTL_FBSB_REQ data structure in layer 1 with the
respective field, as well as the l1ctl_tx_fbsb_req() API function called
from the various layer23 apps.
"mobile" and "bcch_scan" already did a PM request and thus know the
expected signal power. "ccch_scan" and "cbch_sniff" apparently don't
do, so the -85 dBm constant is now hardcoded into the host-side source
code there, and should probably be fixed in a follow-up patch.
This patch changes include paths to get osmocom-bb working with
the current libosmocore tree.
Among all these renames, you can notice several tweaks that I
added on purpose, and that require some explanation, they are:
* hexdump() in osmocon.c and osmoload.c has been renamed to avoid
clashing with hexdump() defined in libosmocore.
* gsmmap now depends on libosmogsm. Actually I had to cleanup
Makefile.am because I was experiencing weird linking problems,
probably due to a bug in the autotools. With the change included
in this patch, I got it compiled and linked here correctly.
This patch has been tested with the phone Motorola C123 and the
following images files:
* firmware/board/compal_e88/hello_world.compalram.bin
* firmware/board/compal_e88/layer1.compalram.bin
Using the osmocon, bcch_scan and mobile tools.
Signed-off-by: Pablo Neira Ayuso <pablo@gnumonks.org>
The SIM client is now complete. Because it usefull for multiple
applications, i moved it to the layer23/src/common directory.
The SIM reader works together with mobile process. Fixes were made.
Thanx to all for testing, finding bugs, and making it work as it is
supposed to do.
The current version uses special L1CTL messages to send and receive APDUs.
This will change in the future, when BTSAP interface is completed.
Please note that this client will not work until the layer1 SIM reader
fixes and extensions are committed.
The layer23 will now set crypto mode and key when CIPHERING MODE COMMAND is
received. After crypto mode has been set, CIPHERING MODE COMPLETE is sent.
NOTE: Layer1 implements only the interface, there is no functionality to it
yet.
This split the headers and adapt the source.
We use osmocom/bb as a prefix because libosomore also
uses osmocom and generic names such as misc & common could
conflict in the future.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>