| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
During development one switches from GSM900 to GSM1800 and GSM850 to
GSM1900. This commit attempts to make this switch more easy.
GSM1800 and GSM1900 have overlapping ARFCNs. This means that the
mapping from bands to arfcn is not injective. Because of that I
removed the code to deduce the band from the ARFCN. This was done
in commit 8c3d807b3fc785ffb18aeb97355150c92221e8a0. The auto-band
option allows to move between GSM900/GSM1800 and GSM850/GSM1900.
Add a simple testcase with these auto-band configurations.
|
|
In case there is no transmitter the S counter might never be decreased.
This means that no radio link timeout will not be sent and the lchan will
remain open forever. There are several ways to resolve this.
The first would be to use the MphTimeInd and after each multiframe check
if there has been a SACCH message for the open lchan's. This could be
similar to the trx_meas_check_compute.
I decided to change fBFILevel to always receive SACCH frames and move
the code down to the PDTCH/PACCH handling and update the comment.
|
|
Make sure the l1msg is always freed in the callback. There were
several error conditions were the msgb would not have been freed,
in the case of the calib data and the system information the message
was not freed even in normal condition.
I will modify this code to __use a msgb. This allows to re-use
the allocated msgb across read operations.
|
|
When not reading quick enough from the queue we will get a bogus
response which will lead to marking the lchan as broken and to
clear the sapi queue. The sapi_queue_dispatch was checking if the
queue was empty before calling the callback but not taking into
account that it might have been flushed.
Stop processing if the queue was empty before calling the callback
or if it is empty after the callback.
Backtrace:
#0 0x4eb1f1cc in raise () from /lib/libc.so.6
#1 0x4eb22f48 in abort () from /lib/libc.so.6
#2 0x4ecc2cb8 in talloc_abort (reason=<optimized out>) at talloc.c:167
#3 0x4ecbc854 in talloc_abort_unknown_value () at talloc.c:180
#4 0x4ecc6bc8 in talloc_chunk_from_ptr (ptr=0x4ec2d494) at talloc.c:192
#5 _talloc_free (ptr=0x4ec2d494) at talloc.c:517
#6 talloc_free (ptr=0x4ec2d494) at talloc.c:990
#7 0x0000f294 in sapi_queue_exeute (lchan=0x402414a0) at oml.c:528
#8 0x0000f2d4 in sapi_queue_send (lchan=0x402414a0) at oml.c:542
#9 0x0000f3e0 in sapi_queue_dispatch (lchan=0x402414a0, status=-4) at oml.c:565
#10 0x000114d0 in lchan_deact_compl_cb (trx=0x4021e038, l1_msg=0x7e690) at oml.c:1269
#11 0x0000d70c in l1if_handle_l1prim (wq=1, fl1h=0x607c8, msg=0x7e690) at l1_if.c:938
|
|
In case the channel is not active we can omit the external requests
to modify it. For the channel modification the higher level is already
acking it and for the ciphering it is probably too late to do anything.
|
|
There are three new commands. There are two markers and a deactivate
command. The markers are used to wait until all previous commands are
executed and then to decide if the SAPI needs to be released at all.
When asked to release the SACCH the marker will be queued, then on
execution of the marker the SACCH in Up-/Downlink will be released.
For the RF Channel Release we use another marker, when the marker is
executed we check all the SAPIs we want to release. It is possible that
the queue looks like this:
(SACCH_REL_MARKER is done) REL_MARKER, SACCH DEACT, SACCH DEACT
This could happen if a BSC sends SACCH Deactivate and RF Channel Release
at the same time. We deal with issue by changing the SAPI state to the
REL_REQ state and check_sapi_release will not ask for another release. So
after the execution the queue will look like this:
SACCH DEACT, FACCH DEACT, TCHF DEACT..
This code does not check that all allocated SAPIs are released. The
lchan_deactivate_sapis could be changed to go through all sapis_dl
and sapis_ul to fix that.
The normal flow should now be:
1.) lchan_deactivate
2.) Check if the queue is empty then go to 4
3.) REL_MARKER is executed and lchan_deactivate_sapis is called
4.) For all SAPIs to be released, check if they are allocated and
then schedule a CMD_DEACTIVATE. If there is an error remember
something went wrong but continue.
5.) Once all commands are executed send the channel release ack.
For the release markers we need to be careful as they might not schedule
any work. E.g. if the BSC sends two SACCH DEACTIVATE the second marker
will not generate any release requests and we should proceed with the
next command. Make sapi_queue_command return 1 in case the command has
been directly executed. So a queue like SACCH_REL_MARKER, LOGCH will
result in LOGCH, SACCH DEACT Rx, SACCH DEACT Tx but a 0 will be returned
and the sapi_queue_next will then call sapi_queue_exeute again.
NITB has been modified to trigger these corner cases more easily.
* Do not send IMM.ASSIGNMENT for some timeslots to go through the
error path
* Issue multile SACCH deactivates in the normal release mode
* Send rsl_chan_mode_modify_req before the SACCH DEACT and also when
the RLL is being released.
|
|
|
|
|
|
|
|
Put all SAPI requests into a queue and handle them one after another.
Begin with the channel activation. Once the queue is empty the channel
activate will be sent. For the BCCH activation we do not want to send
a channel activation message and this is why we set the lchan->state
to NONE.
One change is that we do not attempt to call the ciphering routines on
the BCCH anymore.
This change is necessary to fix issues with LCHANs staying open and being
marked as broken by the BSC and will help in implementing handover support
as this requires a re-configuration of the lchan on the fly.
|
|
Chapter 5.2 applies to MS procedure, but 5.3 (BSS procedure) defines no
exact criterion, so I decided to use the procedure equivalent to MS.
The criterion is based on a counter S, which is initialized to a preset
RADIO_LINK_TIMEOUT, which can be configured via VTY. Whenever a received
SACCH block is bad, S is counted down by one. If SACCH block is
successfully decoded, S is counted up by two, but never above initial
RADIO_LINK_TIMEOUT value. If S reaches 0, an RSL Connection Failure
Indication with cause RF Radio Link Failure is sent to BSC, which then
aborts channel.
Use link timeout value from BSC via OML attribute.
How to test:
- Set "debug" for "meas" logging.
- Start silent call to an attached mobile.
- Remove battery from mobile or shield mobile.
- Watch S count down.
|
|
Issue the RfDeactivate.REQ before sending the MphClose.REQ. Ideally
we would issue MphClose.REQ after the RfDeactivate.CNF but this is
not possible right now.
The current approach makes the following warning of the DSP go away
on shutdown. This was tested with my E71 and an active silent-call
using a SDCCH.
DSP Warning:
[ERROR] : DeviceMng_ValidateL1Handle() => Invalid layer 1 handle
|
|
|
|
Pass in the trx argument at the lower level as everyone is using
the fl1h->priv now.
|
|
|
|
I am working toward killing the last argument of the l1if_gsm_req_compl
and just have the trx inside the callback signature.
|
|
Move the channel activation out of the loop into a dedicated function.
This is done in preparation of separating the decision to activate
something and sending the request.
|
|
Prepare to change the queue and callback handling. For the TX power
VTY command it is still possible that it will conflict with other
callbacks and the easiest way is to beging with sending these requests
through another method that allows us a more strict test.
|
|
The wait list code has a limitation that for two requests of the
same kind it does not know where the confirmation belongs to. This
limitation is triggered when two lchan's get activated/deactivated
at the same time and is noticed once we start to count the SAPIs.
Set the hLayer3 to the lchan identifier, use the trx as closure for
the callback and resolve the lchan in the callback using these two
bits of information.
|
|
We are using this conversion for both hLayer2 and hLayer3. Make the
function name more generic to indicate that this function can be used
with the hLayer3.
The functions that call the methods were updated using spatch and
@rule1@
expression E;
expression F;
@@
- l1if_hLayer2_to_lchan(E, F)
+ l1if_hLayer_to_lchan(E, F)
@rule2@
expression E;
expression F;
@@
- l1if_lchan_to_hLayer2(E)
+ l1if_lchan_to_hLayer(E)
|
|
|
|
We used to have -75 dBm as the target value for the uplink receive
level. Now this is configurable.
The parameter is used as input into the power control loop that adjusts
the MS transmit power in order to achieve the target rx value on the
BTS Rx input.
|
|
The band was derived from the ARFCN but this does not work for
PCS1900/DCS1800 due overlapping ARFCNs. Use the already existing
band configuration to select the band for the MphInitReq. The
dsp firmware will complain if the band/arfcn do not match.
|
|
Use "-P -M" to enable PCU and direct access.
|
|
|
|
|
|
This is just an intermediary hack, until we get proper lchan manager
threads...
|
|
Make this code a bit easier to read by moving the payload setting
into a new method.
|
|
Harald fixed the issue for the activation by adding TchH, but this
needs to be added for de-activation as well.
|
|
|
|
|
|
this allows for quick manual tx power changes from the VTY, particularly
useful in type approval or other measurements.
|
|
This allows us to do RF measurements (EDGE EVM and the like) even
without having any PCU/RLC/MAC code as of now.
To use it, configure PDCH type timeslots (e.g. TS 7) in the BSC and then
use "trx 0 7 activate 0" to manually activate the PDTCH lchan on top
of that timeslot. The BTS will now happily transmit EDGE/8PSK data.
|
|
The ciphering parameters in L1 are persistent accross MPH
deactivate/activate, so we need to make sure to always initialize them
cleanly at RSL CHAN ACT time. This has the added benefit that we can
also activate channels that have encryption enabled from the very
beginning (required for encrypted handover).
|
|
where previously we would only see
<0006> oml.c:931 (bts=0,trx=0,ts=1,ss=0) MPH-DEACTIVATE.req (FACCH/F)
we now get
<0006> oml.c:931 (bts=0,trx=0,ts=1,ss=0) MPH-DEACTIVATE.req (FACCH/F RxUL)
to notice it is modifying the receive path in the uplink direction.
|
|
Send the RSL ACT ACK/NACK after the Layer1 firmware has acked the
activation/deactivation. In case the channel can not be activated
we will send a NACK. In case the channel can not be deactivated we
will send an ACK and the next time the channel is activated we will
send a NACK. The release ack will be sent once the TxDownlink of the
TCH/SDCCH is closed.
Change the rsl_tx_chan_nack method to create a new msgb to be used
by the hardware layer, change the return value to ask the caller to
delete the msgb.
|
|
|
|
Use the deact_sach (renamed to deact_sacch in master) to remember if the
SACCH has been disabled. This should fix the case of lchan errors due releasing
the lchan twice.
|
|
If the deactivation is failing the channel needs to be moved into
and error state, if the deactivation completed the channel needs to
be set to the none state and set the state to release reqeust on
the deactivation.
|
|
By making all modifications through lchan_set_state we can easily
add code to verify the state transition.
|
|
We now check if the received message is an LAPDm I frame in order to
determine if we have received the first valid encrypted message on the
radio link. This relates to the fact that we often see 'old' UI frames
coming up from L1, even after it has confirmed decryption has been
enabled.
|
|
When the RR CIPH MODE CMD is transmitted to the MS, we need to tell the
L1 to enable decryption on RX. After the first received frame has been
decrypted successfully, we will enable encryption also on transmit.
This has been tested with A5/1 so far, but A5/2 and A5/3 should work
exactly identical.
|
|
without this, we would set a FR_V1 codec on a TCH/H channel, which
the L1 is obviously not happy with.
|
|
In L1 RTP mode, the L1 already does all the bit-shifting and re-ordering
required for the RTP formats (which have different bit/nibble order than
the ETSI/3GPP encodings, for some odd reason).
We don't enable it by default yet, as only HR/FR/EFR work with it, but
AMR has some yet to be debugged problem.
Enabling USE_L1_RTP_MODE would save some CPU cycles on the ARM side.
|
|
|
|
|
|
|
|
|
|
If we don't do this on recent L1, the L1 will refuse the open after
re-starting osmo-bts.
There still is an issue in case osmo-bts crashes. We should have a
respawn loop that re-loads the DSP firmware before re-starting osmo-bts,
just to make sure...
|
|
I was wondering why the channel was activated twice but it needs
to be activated for each SAPI.
|
