Age | Commit message (Collapse) | Author | Files | Lines |
|
Instead of limiting the number of TRX at VTY to the actual number of
supported TRX, VTY allows to configure any possible number of TRX. If a
TRX is configured, which is not supported by BTS model, an error message is
returned, which states that the given TRX is not supported.
|
|
|
|
|
|
sysmocom-bts model shuts down on link loss, but other models may not want
this, so shutdown is moved tor bts_model_abis_close of osmo-bts-sysmo.
|
|
The code is quite complete, TCH and PDCH channels are not yet tested.
|
|
MS uplink power control is required in pretty much any BTS, and we
cannot assume that they PHY / L1 will always take care of it by
itself. So the correspondign code is moved to common/power_control.c
and called from the generic part of L1SAP.
The corresponding VTY paramter has been moved from the sysmobts-specific
trx VTY node to the common BTS VTY node.
|
|
|
|
There are three transitions:
1. LCHAN_CIPH_NONE -> LCHAN_CIPH_RX_REQ -> LCHAN_CIPH_RX_CONF
It is used to enable ciphering in RX (uplink) direction only.
2. LCHAN_CIPH_RX_CONF -> LCHAN_CIPH_RX_CONF_TX_REQ -> LCHAN_CIPH_RXTX_CONF
It is used to additionally enable ciphering in TX (downlink) direction.
3. LCHAN_CIPH_NONE -> LCHAN_CIPH_RXTX_REQ -> LCHAN_CIPH_RX_CONF_TX_REQ
-> LCHAN_CIPH_RXTX_CONF
It is used to enable ciphering in both TX and RX directions. This is used
when the channel is activated with encryption already enabled. (assignment
or handover)
In order to follow the order of these transitions, the RX direction must
always be set before the TX direction.
If no cipher key is set (A5/0), ciphering is set to ALG 0, but lchan cipher
state remains at LCHAN_CIPH_NONE.
|
|
... introduced in 2cc37035d73191b71b9ba9c0d559a0da6a5f35e5
|
|
This part moves TCH handling from osmo-bts-sysmo to common part. The RTP
handling is done at the common part, so they can be used by other BTS
models.
|
|
This part replaces channel activation/deactivation/modification routines
by MPH_INFO messages.
|
|
|
|
This part moves GSM time handling from osmo-bts-sysmo part to common part.
|
|
This first part moves BCCH message primitives from osmo-bts-sysmo to common
part. A new file "common/l1sap.c" is introduced to implement handling of
layer 1 messages from/to BTS model.
|
|
Instead of handling primitives directly at layer 1 specific code,
osmo-bts handles primitives at common code.
When all primitive are moved, the l1sap interface will:
- receive PH-DATA indications and forward them to layer 2.
- check for RF link loss and notify BSC.
- receive TCH indications and forward them via RTP.
- receive PH-RTS indications and send PH-DATA requests with content
according to its logical channel.
- receive TCH-RTS indications and send TCH requests with content
received via RTP or loopback from TCH indications.
- send MPH-INFO requests to activate, deactivate and modify logical
channels and handle their confirms.
- receive MPH-INFO indications with measurements from tranceiver.
- forward received and transmitted PH-DATA to GSMTAP.
|
|
Currently the DSP is instructed to achieve a given uplink
power target but there are circumstances (e.g. EMV testing)
where we need more control over it. The "manual/software/osmo"
power control can only be implemented per TRX and not per
lchan. Add a very very basic control that checks the MS Power
used by the phone, the actual receive level and then adjust
the power.
The code doesn't take the history into account, if the phone
can not reach the requested power level the code will be stuck
(e.g. no timeout based on multiframes). It has a mode for a
fixed power control but no way to set it yet.
The change of the mode requires a restart of the software.
|
|
* CBCH load indications are not yet sent
* The queue length is not yet limited!
|
|
This should handle OML channel combinations with CBCH and activate the
CBCH SAPI towards the DSP correspondingly. What is still missing is
sending any actual information over the CBCH in respons to the
PH-RTS.ind coming up from L1.
|
|
bts_ctrl_lookup.c: In function 'bts_controlif_setup':
bts_ctrl_lookup.c:97:2: warning: implicit declaration of function 'bts_ctrl_cmds_install' [-Wimplicit-function-declaration]
rc = bts_ctrl_cmds_install(bts);
^
|
|
libosmo-abis doesn't make it easy to have these parameters
as const.. just declare it non-const in the api. We pass
a static string but we know it will not be modified.
|
|
We use the completion call-back from L1 to compare the instructed
TRX board output power with the actual value as reported back from
L1.
Right now we only print an error message in case the values disagree.
In the future we might want to either use that value as part of our
calculation or send an OML alarm report to the BSC.
|
|
|
|
... which is now defined in libosmocore
|
|
Using this control interface, an external program can request
attentuation of the transmitter for thermal management reasons. The
external application doesn't have to know anthing about the actual
transmit power, but it can just configure a certian value of milli-dB
(1/10000 bel) and update (increase/decrease) that value depending on
the thermal environment.
|
|
In order to support transmit power reduction by thermal management
as well as the variety of new internal / external PA configurations
of BTSs, we need a slightly more complex system.
Also, as at high power a single dB can be quite a big difference,
we are now doing all computations in milli-dB(m), i.e. 1/10000 bel.
Ramping is now used both for up and down ramping, as that is useful in
cases where you want to gracefully shut down a cell by shrinking its
radius, gradually handing over subscribers to neighboring cells.
Furthermore, this code is becoming part of the 'common' codebase, as it
is not really specific to how sysmobts is working.
The user can specify a single aggregate value for external system
gain/attenuation. Let's say you have 1dB loss of antenna cable, so you
can put that as 'user-gain -1' into the config, which means that a
'transmit power of 20dBm' will be compensatet for that and the TRX is
instructed to output 21dBm to compensate the cable loss. Similarly,
external PAs can be described by a positive user-gain.
One of the next steps will be to communicate those values and the
nominal power capability of the specific BTS to the BSC, so the BSC will
automatically show correct signal levels in the VTY and log files.
The code includes provisions for future extensions regarding
* an external and an internal PA with calibration tables
* a thermal attenuation setting to be controlled by the site manager
|
|
the latter is now in libosmogsm.
|
|
Extend the router to verify that the message received is
properly encoded. The code can deal with the basic structure
of ETSI OML and vendor specific messages for ip.access and
the osmocom project.
|
|
Fixes:
../../include/osmo-bts/oml.h:8:42: warning: ‘struct gsm_bts’ declared inside parameter list [enabled by default]
int down_oml(struct gsm_bts *bts, struct msgb *msg);
^
../../include/osmo-bts/oml.h:8:42: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
../../include/osmo-bts/oml.h:12:52: warning: ‘struct gsm_abis_mo’ declared inside parameter list [enabled by default]
int oml_mo_send_msg(struct gsm_abis_mo *mo, struct msgb *msg, uint8_t msg_type);
^
../../include/osmo-bts/oml.h:13:31: warning: ‘struct gsm_abis_mo’ declared inside parameter list [enabled by default]
int oml_mo_opstart_ack(struct gsm_abis_mo *mo);
^
../../include/osmo-bts/oml.h:14:32: warning: ‘struct gsm_abis_mo’ declared inside parameter list [enabled by default]
int oml_mo_opstart_nack(struct gsm_abis_mo *mo, uint8_t nack_cause);
^
../../include/osmo-bts/oml.h:15:32: warning: ‘struct gsm_abis_mo’ declared inside parameter list [enabled by default]
int oml_mo_statechg_ack(struct gsm_abis_mo *mo);
^
../../include/osmo-bts/oml.h:16:33: warning: ‘struct gsm_abis_mo’ declared inside parameter list [enabled by default]
int oml_mo_statechg_nack(struct gsm_abis_mo *mo, uint8_t nack_cause);
^
../../include/osmo-bts/oml.h:19:29: warning: ‘struct gsm_abis_mo’ declared inside parameter list [enabled by default]
int oml_mo_state_chg(struct gsm_abis_mo *mo, int op_state, int avail_state);
^
../../include/osmo-bts/oml.h:22:31: warning: ‘struct gsm_abis_mo’ declared inside parameter list [enabled by default]
void oml_mo_state_init(struct gsm_abis_mo *mo, int op_state, int avail_state);
^
../../include/osmo-bts/oml.h:26:10: warning: ‘struct gsm_abis_mo’ declared inside parameter list [enabled by default]
int success);
^
../../include/osmo-bts/oml.h:29:33: warning: ‘struct gsm_abis_mo’ declared inside parameter list [enabled by default]
int oml_tx_state_changed(struct gsm_abis_mo *mo);
^
../../include/osmo-bts/oml.h:31:33: warning: ‘struct gsm_abis_mo’ declared inside parameter list [enabled by default]
int oml_mo_tx_sw_act_rep(struct gsm_abis_mo *mo);
^
../../include/osmo-bts/oml.h:36:4: warning: ‘struct gsm_abis_mo’ declared inside parameter list [enabled by default]
uint8_t cause);
|
|
For LCR and other systems without out-of-band information we need
to indicate the CMR. Not every air message will include the mode
and we sent a stream that had the CMR set and not-set. This lead
to the AudioCodes MGW only playing every second frame.
Remember the last used mode and initialize it to _NONE when we
receive the multirate config. In case of a real error we will
still use AMR_CMR_NONE.
The initial patch is from Harald. I have added the initialization
and moving of the defines to amr.h.
Manually verified by enabling AMR5.9 and looking at two RTP
packages in sequence. In both cases the CMR was 2. I have looked
at "amr.nb.cmr != 2" in wireshark and only found the MGCP dummy
packet.
|
|
|
|
Initialize the libosmo-abis VTY nodes more early so we can parse
the config file that was created by "write". Introduce abis_init
to initialize the libosmo-abis and modify abis_open to re-use an
existing line. Update the comments. This has only been tried with
the sysmobts-remote on x86. A TCP connection is opened toward the
configured BSC.
Fixes: SYS#285
|
|
These routines do not pass the gsm_abis_mo and parsing the FOM
header of the msg does not seem to be a good idea either. Pass
in the OML object so that the model code can determine what the
void pointer is.
|
|
The BTS layer needs to inform the handover code when an access
burst has been received. In turn the handover layer will ask the
bts to modify the channel, it will schedule the physical information
inform the BSC with the HANDOVER DETECTION and waits for the BTS
layer to inform it about the first received frame to stop a timer.
|
|
Introduce the handover.h/handover.c and initialize handover parameters
in OML and remember the activation through RSL.
|
|
|
|
|
|
Currently, the AGCH queue length is not limited. This can lead to
large delays and network malfunction if there are many IMM.ASS.REJ
messages.
This patch adds two features:
- Don't accept msgs from the RSL layer when the queue is way too
full (safety measure, mainly if bts_ccch_copy_msg() is not being
called by the L1 layer, currently hard coded to 1000 messages)
- Selectively drop IMM.ASS.REJ from the queue output depending on the
queue length
Ticket: SYS#224
Sponsored-by: On-Waves ehf
|
|
This patch extends paging_gen_msg() by adding an output parameter
is_empty that is true, if only a paging message with dummy entries
has been placed into buffer. This feature is then used by
bts_ccch_copy_msg() to insert an AGCH message if is_empty is true.
Ticket: SYS#224
Sponsored-by: On-Waves ehf
|
|
Counters are added for the following events (use VTY show to query):
- Dropped IMMEDIATE ASSIGN REJECT messages
- Merged IMMEDIATE ASSIGN REJECT messages
- Rejected AGCH messages
- Use of PCH (non-reserved) for AGCH messages
- Use of AGCH (reserved) for AGCH messages
Sponsored-by: On-Waves ehf
|
|
This patch adds a function bts_update_agch_max_queue_length()
to compute a limit of the AGCH queue. This is based on the idea,
that the AGCH queue has a limited drain rate and that CHANNEL
REQUESTs must be answered within a certain time frame, given
by the minimum value of T3126 (see GSM 04.08). When the AGCH queue
reaches that limit, the last message would be delivered in time if
there were no other delays involved (which is not the case).
The calculation is based on the ratio of the number RACH slots and
CCCH blocks per time:
Lmax = (T + 2*S) / R_RACH * R_CCCH
where
T3126_min = (T + 2*S) / R_RACH
R_RACH is the RACH slot rate (e.g. RACHs per multiframe)
R_CCCH is the CCCH block rate (same time base like R_RACH)
The value depends control_channel_desc.ccch_conf and
rach_control.tx_integer (both from SYSINFO_TYPE_3) and should
therefore by called at least each time after one of these is changed.
For this reason, a signal callback is registered under
SS_GLOBAL/S_NEW_SYSINFO which invokes bts_update_agch_max_queue_length().
Sponsored-by: On-Waves ehf
Based-On: "bts: Calculate length of agch queue" by Ivan Kluchnikov
<kluchnikovi@gmail.com>
|
|
This patch adds a common function bts_ccch_copy_msg() that provides
and schedules AGCH and PCH messages. It is basically a frontend to
paging_gen_msg() and bts_agch_dequeue() and contains refactored code
from l1_if.c.
Sponsored-by: On-Waves ehf
|
|
This patch adds and updates btsb->agch_queue_length to keep track of
the queue length.
Sponsored-by: On-Waves ehf
|
|
Use the lchan->rel_act_kind field for the BCCH activatiob by OML.
The lchan's should be marked as active but no event should be sent to
the BSC. This is mostly like the PCU. We can now remove the secnd
argument from lchan_activate.
|
|
Nicolas ended up with linker issues due abis_rsl_sendmsg being
defined twice. Rename our version of the function and update the
code.
Patched with:
@i@
expression E;
@@
- abis_rsl_sendmsg(E)
+ abis_bts_rsl_sendmsg(E)
|
|
Currently the LEDs are being accessed directly from within the
l1_if.c file. So the handling of rf mute and activate/deactivate both
access LED_RF_ACTIVE directly. This may lead to an inconsistent LED
status.
This patch replaces these calls to sysmobts_led_set() by an abstract
equivalent bts_update_status(), that uses a set of independant status
ids. The associated values can than be combined into a visible LED
status. Currently LED_RF_ACTIVE is on iff BTS_STATUS_RF_ACTIVE is set
and BTS_STATUS_RF_MUTE is not set.
Sponsored-by: On-Waves ehf
|
|
Currently a Change Administrative State Request is just applied
unconditionally to the object's state object and then acknowledged.
This patch implements the special handling of setting the Radio
Carriers state to LOCK or UNLOCK. This is done by passing the
appropriate mute command to the L1 layer. Always all radio channels
are affected, it is not possible to lock single radio channels.
On success, an ACK is sent back to the bsc with the new state (based
on the state passed in the callback by the L1 layer). If something
went wrong or the firmware doesn't support RF mute, a NACK
(REQ_NOT_GRANTED) is sent instead.
Note that a NACK for such a request hasn't been sent by the BTS to
the BSC yet, so (albeit it's spec conformant to do so) the BSC must
be prepared to handle this correctly.
Ticket: OW#976
Sponsored-by: On-Waves ehf
|
|
This adds a new function
l1if_mute_rf(femtol1_hdl, ch_mute[8])
to set the mute state for each radio channel. On completion and iff
l1if_mute_rf() returned 0 the callback
oml_mo_rf_lock_chg(mo, ch_mute_state[8], success)
is invoked when the response from the superfemto DSP is received.
Ticket: OW#976
Sponsored-by: On-Waves ehf
|
|
The PCU is forcing the activation of a PDCH. Currently the BSC
will receive a channel act ack for a channel that was not
activated at all. Use the "release_reason" flag of the lchan
to see if we have requested a normal activation or a silent
one.
It feels a bit odd to do it in the TX function but it is the
most easy solution right now. I have added logging so it will
not be totally silent.
|
|
|
|
This introduces a new get_signlink_remote_ip() function whcih we also
use in the RSL code to determine the RTP remote address if the CRCX/MDCX
contains no remote IP address IE.
|