The gsm0503_pdtch_encode() returns negative number on error,
and the amount of encoded bits in case of success.
Change-Id: I7d75141142922909330c5e86be8734bb06cd57a4
During the handover the MS needs to release the existing dedicated
channel(s), establish the new one(s) as indicated by the network,
and then, depending on the synchronisation state, send one or more
HANDOVER ACCESS messages carried by Access Bursts.
In order to implement this, trxcon needs to be able to transmit
Access Bursts on any TDMA timeslot regardless of the logical
channel type and the associated handler, i.e. != TRXC_RACH.
The controlling side on L1CTL (layer23 or TTCN-3) needs to send
one or more L1CTL_RACH_REQ message(s) with properly populated
UL info header. Otherwise a regular RACH on TS0 is assumed.
Change-Id: Ia967820a536c99966ba2c60b63d2ea9edb093f46
Before this patch, prim_dequeue_sacch() used to ignore SACCH primitives
with odd length (e.g. 21, when sender forgot to push 2 octets of L1
SACCH header), so neither they were transmitted, nor rejected.
As a result, they would stay in the Tx queue until a dedicated
connection is released. The only way to notice such problem
was looking at the constantly growing talloc's report.
Instead of ignoring the primitives with odd length and keeping them
in the queue, let's pass them to a logical channel handler, so they
would be dequeued and rejected with a proper logging event.
Also, to simplify further debugging, let's print the final decision
of SACCH prioritization: whether it's a Measurement Report or not.
Change-Id: I3149fa518439470b397953306209eb859c83450a
According to 3GPP TS 05.02, section 6.4.1, CBCH replaces
SDCCH number 2 in both V (BCCH+CCCH+SDCCH/4+SACCH/4) and
VII (SDCCH/8+SACCH/8) logical channel combinations.
Unfortunately it is not clear whether we can use stolen UL slots
for RACH or not. For now, we should mark all of them as IDLE.
Somehow TRXC_SDCCH4_2 slots were left in the definition of
combination V (combined CCCH+BCCH). This is not critical,
but may be looking confusing. Let's fix this.
Change-Id: Id30f2fac3274de3edff4ae59f77d9c9cf8059155
The existing logic unconditionally wants to send a POWERON command
on TRXC whenever L1CTL_FBSB_REQ is received. That may cause some
problems when sending subsequent L1CTL_FBSB_REQ, e.g. due to signal loss.
Sending POWEROFF when transceiver is not powered on is normal though.
This can happen if trxcon is restarted while fake_trx was running.
The existing FSM state could unfortunately not been used, as it's a
mixture between the TRX connection state and the command/response state.
The current solution is just a work around. We definitely need to
introduce separate state machines for transceiver and its TRXC
interface.
Change-Id: I834e8897b95a2490811319697fc7cab6076db480
Both PRIM_IS_RACH() and PRIM_IS_EXT_RACH() macros to be used for
handover RACH detection in the follow up changes, thus we need
have them widely available. Let's also give them better names:
PRIM_IS_EXT_RACH -> PRIM_IS_RACH11
PRIM_IS_RACH -> PRIM_IS_RACH8
and introduce a new generic one for checking whether a given
primitive is RACH in general (either 8-bit or 11-bit) or not.
Change-Id: Ibc39c57fda000647be1829786f6423dcf3f435cd
It makes sense to do this first, before tuning to a different
ARFCN and changing the training sequence. Otherwise, if no
multi-frame configuration is found, trxcon would switch to
a different channel and then remain inactive there.
Change-Id: I274588ce3a9c49372b5da0629930afece46f799c
Having magic pre-calculated hex-masks gives one quite high chances
to shoot oneself in the foot, and decreases readability in general.
Let's do this pre-calculation during the compilation process, so
it's much easier to read, extend and spot potential bugs.
Change-Id: If945b3654e35c83fc0220fdd6d99c1c7a0503386
In I2fc61e1cdca4690a34e2861b9ee3b7c64ea64843 I introduced a regression.
TRXC_SDCCH4_CBCH should have TRX_CH_FLAG_AUTO, because it's a part of
GSM_PCHAN_CCCH_SDCCH4_CBCH multi-frame layout. If the controlling
side on the other end of the L1CTL link requests this particular
multi-frame layout, CBCH channel is expected to be active.
Change-Id: I3ed942106a03220417b5cb9176107af057120fbe
Let's avoid fancy alignment in the description of logical channels
for the benefits of having better readability, the ability to add
more comments and fields without making it look ugly.
Also, let's get rid of field 'chan' of 'trx_lchan_desc' structure
since it's not used anywhere, and not actually needed because the
position of each lchan description is defined by its TRXC_* type.
As a bonus, let's add a human readable description to each
lchan definition, so it can be printed in the VTY some day.
Change-Id: I2fc61e1cdca4690a34e2861b9ee3b7c64ea64843
PDCH channel support was introduced quite a while ago, but there
was no way to activate it via L1CTL so far. Let's fix this.
Change-Id: I3b66cab26108ab999a7fe969365ab57dc661399c
Wherever possible, use #defines from libosmogsm as opposed to magic
numbers. Using magic numbers in several places has the danger of
different programs/repositories having different views on what those
values mean.
Change-Id: I7ab4958801b3422973b67ff0452b90afa8a3f501
Related: OS#4027
Depends: libosmocore Change-Id I93e557358cf1c1b622f77f906959df7ca6d5cb12
OsmoBTS, BSC and TTCN3 used cbits == 0x18 for dynamic PDCH, while
trxcon wanted to use 0x18 for CBCH on SDCCH/4. Let's fix this and
bring everyone in agreement.
Related: OS#4027
Change-Id: Ia9a415628c659cbc2dd5dc65b875b7f935d6e211
sap_fsm.c: In function ‘sap_negotiate_msg_size’: sap_fsm.c:103:15:
warning: passing argument 1 of ‘__bswap_16’ makes integer from pointer
without a cast [-Wint-conversion]:
size = ntohs((uint16_t *) param->value);
^~~~~~~~~~~~~~~~~~~~~~~~~
Change-Id: Ie58af6162c67ae377809b42daa897ca3f3d72af1
According to the man page of recv(), the only difference of this
call from read() is the presence of flags. With a zero flags
argument, recv() is generally equivalent to read().
Change-Id: I6d43bbf8d52c5fbb8ee0592b7d1c1dfd2dd1548e
Since we only set both ARFCN and TDMA frame number of the DL info
header, other fields remain uninitialized. Let's memset() them.
Change-Id: Ib39c333f1724fefa5d8bd8a2315b77a5612f7fa9
This would allow to abstract both L1CTL and TRX interfaces
from each other in the upcoming refactoring.
Change-Id: I74a23c73b03bad822272b9cfe76c2501666912b7
In both gsm48_mm.c and gsm48_rr.c we put / push 'gsm48_rr_hdr'
structure into the message buffers, so then it's retrieved by
the message receivers. The AddressSanitizer complains about
unaligned pointer access and potentially unexpected behaviour.
Change-Id: I8aa2c0074b405afd0e76044ef076b6819fe1083b
In gsm322_l1_signal(), if S_L1CTL_FBSB_ERR is received, we free
stored System Information of the current cell, but cs->si may
still point to it. Let's set it to NULL.
Found with AddressSanitizer:
DL1C ERROR l1ctl.c:96 FBSB RESP: result=255
DCS INFO gsm322.c:2995 Channel sync error, try again
DCS INFO gsm322.c:467 Sync to ARFCN=860(DCS) rxlev=-106
DRR INFO gsm48_rr.c:665 MON: no cell info
DRR INFO gsm48_rr.c:665 MON: no cell info
DRR INFO gsm48_rr.c:665 MON: no cell info
DRR INFO gsm48_rr.c:665 MON: no cell info
DL1C ERROR l1ctl.c:96 FBSB RESP: result=255
DCS INFO gsm322.c:3008 Channel sync error.
DCS DEBUG gsm322.c:3013 free sysinfo ARFCN=860(DCS)
DCS INFO gsm322.c:3020 Unselect cell due to sync error!
DCS INFO gsm322.c:509 Unselecting serving cell.
=================================================================
==6014==ERROR: AddressSanitizer: heap-use-after-free on address
0x61b0000000e6 at pc 0x00000050d6dd
bp 0x7fff7f84aa60 sp 0x7fff7f84aa58
Change-Id: I9cc526c18d69695d810de98703579818408de011
According to 3GPP TS 05.03, section 5.3, two coding schemes are
specified for access bursts: one for regular 8-bit bursts,
another - for extended 11-bit packet access bursts.
According to 3GPP TS 05.02, section 5.2.7, there are two
additional training (synchronization) sequences for RACH
bursts: TS1 & TS2. By default, TS0 synch. sequence is used,
unless explicitly stated otherwise (see 3GPP TS 04.60).
According to 3GPP TS 04.60, section 11.2.5a, the EGPRS capability
can be indicated by the MS using an alternative training sequence
(i.e. TS1 or TS2) and the 11-bit RACH coding scheme.
Change-Id: I36fd20cd5502ce33c52f644ee4c22abb83350df8
Use static helper to prepare l1ctl_fbsb_conf - this simplifies
fbsb-related functions and make difference between timer callback and
regular response more obvious.
Change-Id: I43832d6a912a32ea5795ed0110981e0b714a7a61
Use static helpers to add l1ctl_info_dl to msgb - this simplifies
l1ctl_* routines and reduce code duplication.
Change-Id: I0b5b81f1fcd2984136e553a93735ea5456d2b3df
Instead of counting both RSSI and ToA measurements separately,
let's have a single counter in trx_lchan_state.meas struct.
Change-Id: I45454a3ac92b8cc85dd74092e4ab6eb350f20c9a
This change fixes the following compiler warning:
sim.c: In function ‘gsm_sim_reply’:
sim.c:149:11: warning: variable ‘payload’ set but not used
[-Wunused-but-set-variable]
uint8_t *payload;
Change-Id: I3767b23bb1b28d3f4bb515d399bce160ba2eee09
As we do iterate over all entities in the BA list, it makes more
sense to print each one separately instead of printing the last
one. Moreover, as soon as the iteration is finished, *ba points
to some zero-initialized part of memory:
gsm322.c:5170 Write stored BA list (mcc=000 mnc=000 Marshall Islands, 000)
After this patch:
gsm322.c:5162 Write stored BA list (mcc=250 mnc=99 Russian Federation, Beeline)
gsm322.c:5162 Write stored BA list (mcc=250 mnc=01 Russian Federation, MegaFon)
gsm322.c:5162 Write stored BA list (mcc=250 mnc=02 Russian Federation, MTS)
gsm322.c:5162 Write stored BA list (mcc=544 mnc=31 Serbia, Telenor)
Change-Id: I5160492e6125401c6a1765f54d129b1f1cd503fc
In If1e851ac605c8d2fde3da565b0bd674ea6350c2e, msgb_wrap_with_TL()
was renamed to msgb_push_tl(). Let's use the new symbol name.
Change-Id: Ief37424e0ca3cd696054518a0ffb07b7ef17a462
Both l1ctl_link_init() and trx_if_open() do accept 'tall_ctx' now,
so there is no need to expose the root context anymore. For
logging initialization, we can just pass a pointer.
Change-Id: I7a2231eb880a995d3296b94481a7799e6ff07489
The main changes are:
- return pointer to the allocated l1ctl_link or NULL,
- accept the talloc context as 'tall_ctx' argument.
Change-Id: I7fe1bc306494ac692c182dcfd2a2d9412929194b
The main changes are:
- return pointer to the allocated trx_instance or NULL,
- extend debug message with TRX address and base port,
- accept the talloc context as 'tall_ctx' argument,
- rename goto label 'error' to 'udp_error',
- rename argument 'port' to 'base_port'.
Change-Id: I39b24afee2f09d6a6c500cfc26ac45f206589c5c
The (BT)SAP (Bluetooth SIM Access Profile) is a part of Bluetooth
specifications, that defines the protocol and procedures that
shall be used to access a smart card (usually GSM SIM) via
a Bluetooth link.
The profile defines two roles:
- Server - the side that has direct access to a smart card.
It acts as a SIM card reader, which assists the Client
in accessing and controlling the smart card.
- Client - the side that accesses and controls the smart card
inside the Server through the connection with Server.
Typical examples of a Server are a simple SIM card holder or
a portable phone in the car environment. A typical example of
a Client is a car phone, which uses a subscription module in
the Server for a connection to the cellular network.
OsmocomBB implements the Client role providing abstract SAP
interface API to the higher layers. Instead of Bluetooth,
a UNIX socket is used to communicate with a Server.
The previous implementation of (BT)SAP interface was incomplete
and hard to maintain. This change (re)implements it almost from
scratch on top of the Osmocom FSM framework.
Besides that, the most significant changes are:
- The implementation is separated into three parts:
- sap_interface.{c|h} - public SAP interface API,
- sap_proto.{c|h} - SAP protocol definition,
- sap_fsm.{c|h} - SAP FSM implementation.
- Both 'sap_message' and 'sap_param' structures follow the
SAP message format definition according to 5.1 and 5.2.
- The message parsing is done more carefully in order to
prevent buffer overflow and NULL-pointer dereference.
- Introduced public API for getting / adding message
parameters, and checking the ResultCode.
- Introduced public API for opening / closing a connection
with the server, powering on / off and resetting the SIM
card, sending ATR and APDU.
- Introduced a call-back for handling the response message.
- Card reader state is also a part of the public API.
The new implementation was tested against softsim [1]. The
only limitation is Server-initiated Release, that allows the
Server to 'ask' a Client to release connection as soon as
communication with the smart card is finished. This is not
implemented (yet), and leads to immediate release.
[1] https://git.osmocom.org/softsim/
Change-Id: I77bb108615bb2c94c441568f195b04e0a5421643
Passing NULL to sap_msg_free() is not only meaningless, but also
would result in NULL pointer dereference. We should call it in
successful case only, so let's fix this.
Change-Id: Icf868c4299e292a17c4b7aad1f9e728ea3653494
Due to a mistake, average RSSI value of received bursts was not
converted to GSM RX level (range 0..63), so trxcon has been
sending incorrect values to the higher layers.
Let's fix this, and also prevent possible division by zero.
Change-Id: Id4659de899411ec1ba1718fdcb40aec562dbfd65
There are several SIM card interfaces, two of which:
- GSM_SIM_TYPE_L1PHY (using built-in SIM reader of the L1 PHY),
- GSM_SIM_TYPE_SAP (using remote reader via (BT)SAP protocol),
can actually deal with a physical SIM card. But, for some reason,
only GSM_SIM_TYPE_L1PHY was considered as such. Let's also get
along with GSM_SIM_TYPE_SAP for the following procedures:
- PIN management and verification,
- FPLMN / LOCI updating,
- A3 authentication.
Change-Id: I4b3080fa7a5332467a449a314ba3cc3a07a9b7df
Since we have two ways to interact with a physical SIM:
- using built-in SIM reader of the L1 PHY (via L1CTL),
- using remote reader via (BT)SAP protocol,
name 'GSM_SIM_TYPE_READER' looks quite confusing. Let's rename it
in order to explicitly indicate the role of L1 PHY.
Change-Id: I0f83f365ed50cfd658fdd3a9d6866ed76c8c4009
Almost all layer23 applications, excluding mobile, have nothing
to do with SAP interface. Moreover, the current implementation
does initialize SAP connection automatically, as soon as the
first message is sent.
Change-Id: I62cc69c06fa15468a55bb0a9d408267d0745174c
The idea of SETFH command is to instruct transceiver to enable
frequency hopping mode using the following parameters:
CMD SETFH <HSN> <MAIO> <CH1> <CH2> [... <CHN>]
Note: since the length of a CTRL command is limited to 128
symbols (BTW: why?), the amount of channels is also limited.
Change-Id: Id3d44e6a2796f1ce8523a49dedd5d484052a5c7f
This change revives the main idea of:
Change-Id: I32517567847fd5c54b1742f18bf409ff81e316fa
to stop ignoring the VTY bind address from the config file.
Furthermore, it deprecates (and disables) both 'u' and 'v'
command line options, because they are redundant.
Change-Id: I99e0ec1717edd29b3be231be86616cc7effe5d95
The process should be aborted if a non-existing command line
option or an incorrect parameter value is passed.
Change-Id: Ib656ad12f12429ed15dc2a1554901ffa51148ff6
The VTY requisites are always being printed by libosmovty,
there is no need to duplicate this information.
Change-Id: I688f66175ea67d4c6a46819bee7d300ad9ce7cc7
This reverts commit c8de8cb1e1
(Change-Id I32517567847fd5c54b1742f18bf409ff81e316fa by Max),
because several problems were introduced, in particular:
a) Help message of mobile application is broken:
"The VTY IP to telnet to. (default (null))",
"The VTY port number to telnet to. (default 127.0.0.1)".
b) Default VTY bind addres != parsed from the config file.
c) The (vty_ip == NULL) is resolved only when an external
MNCC handler is used, otherwise NULL is passed to
l23_app_init().
Change-Id: Ic63a4eb828ff32d3744886b4f5f6f5019c798620
Previously the vty bind config parameter was always ignored. Fix this by using proper
default value from the config unless it's explicitly set via command-line parameter.
Change-Id: I32517567847fd5c54b1742f18bf409ff81e316fa
Log via LOGP() like the rest of the file instead of fprintf() for
consistency. While at it, also print error cause.
Change-Id: Id205bcd9bdb7c3e4b96493d50be8381a6fa80ac6
Fixes following ASan warning:
git/osmocom-bb/src/host/layer23/src/misc/../common/main.c:146:2: runtime error: null pointer passed as argument 2, which is declared to never be null
The warning however is harmless since in that case, app_len = 0 and thus
size to copy is 0.
Change-Id: I009a5b53f1e5be72ce347d64d3a7cb1d95d37ea3
Unlike the DATA messages, traffic frames may have different length.
Instead of having fixed payload (i.e. TCH frame) length, let's
introduce a flexible array member. This would allow one to
calculate the frame length using the MSGB API.
Change-Id: I119fa36c84e95c3003d57c19e25f8146ed45c3c6
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
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
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.
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
Harald Welte
Vadim Yanitskiy
Eric Wild
Pau Espin