The current name of PCU_IF_SAPI_AGCH_DT is a bit misleading as it
describes a method to send immediate assignment messages (normally AGCH)
via the PCH. The name in the constant should reflect that correctly
Change-Id: I78abeb62d0267baa31a4727c4bdd027b7230f137
Related: OS#5198
The struct gsm_pcu_if_e1_ccu_ind is a bit misplaced. Lets move it next
to the info indication strucht, to have it in the same order is it used
in gsm_pcu_if
Change-Id: I41237c7847ab7a14ed2cd85dd32aabb3a6124a49
Related: OS#5198
A new VTY node was added in commit [1], but bsc_vty_go_parent() was
not updated. Because of that, commands following the MGW node may
crash osmo-bsc. In the example below:
network
network country code 901
mobile network code 70
...
mgw 0
remote-ip 127.0.0.1
local-ip 127.0.0.1
periodic location update 30
the 'periodic location update 30' will trigger a segfault:
(gdb) bt
#0 0x00005555555dfc09 in cfg_net_per_loc_upd ()
#1 0x00007ffff7af6c3f in cmd_execute_command_strict () from /usr/local/lib/libosmovty.so.9
#2 0x00007ffff7af6f1c in config_from_file () from /usr/local/lib/libosmovty.so.9
#3 0x00007ffff7afd4e1 in vty_read_config_filep () from /usr/local/lib/libosmovty.so.9
#4 0x00007ffff7afe375 in vty_read_config_file () from /usr/local/lib/libosmovty.so.9
#5 0x0000555555579616 in bsc_network_configure ()
#6 0x000055555557a352 in main ()
because vty->index would be NULL after returning from the MGW node.
Fix this by adding the missing case to bsc_vty_go_parent().
Change-Id: Id3050ff7e2402c33ee76c7bf0cc83603c0cc6dfc
Fixes: [1] 8d22e68706
The intended endienaess for the remote_port member is host byte order,
while the endianess in the nsvc struct is in network byte order.
(see also pcu_sock.c in osmo-bts.git)
Change-Id: Ib62dcceb80fd500e477dd5e1a0e43de47e16eeb0
Related: OS#5198
osmo-pcu will also support GPRS via E1 timeslots in a BSC co-located
setup. To avoid duplicate configuration the BSC has to communicate the
E1 parameters (which TS, SS etc.) to the PCU. Lets add a new primitive
to do that.
Change-Id: I3a0f6ae6b98694458230d7c0ac2c89b332cfbc92
Related: OS#5198
The Ericsson RBS is a BTS that natively works with dynamic timeslots.
This colides with the current understanding of static PDCH channels
because the BTSs we support so far get thier static PDCH information on
startup and then handle everything related internally. The BSC does not
actively manage the channel in those cases. In the case of Ericsson we
have to activate the PDCH via RSL like any other channel and the timeslot
FSM has to manage it. Lets not add work arouds for this, lets just print
and error message and use the BTS in the dynamic scheme as intended by
the manufacturer.
Change-Id: Icc7c2956fc934691e3bfacb283d896a8767baf27
Related: OS#5198
Before filling in the TS in the info indication, it is checked that the
MO opstate is enabled. Also it is checked that the TS serves a PDCH.
Lets restructure this check and move the PDCH check into a helper
function as we need to check for PDCH from other location as well later.
Change-Id: Icaab52ab73c38889dfadb523b89bb54cafacc99a
Related: OS#5198
We send the TS_EV_OML_READY event early, even though the TRX is not
fully done with all OML initialization steps. Lets complete the TRX
initialization first and then notify each timeslot FSM with
TS_EV_OML_READY.
Change-Id: If5251b102c8aa45dfc8cc4ee4e0223d7dc438938
Make sure that the TRX MO state is enabled and unlocked before filling
in any TRX information into the info indication
Change-Id: I7a93826e6b0df187425310cb82854e7d7fb47e72
Related: OS#5198
Make 'apply-config-file' check the neighbor config, just as is done after config parsing on startup
Related: OS#5866
Change-Id: I24ae8cd7e5e0d15eab9fd04b1858072bf0bad36a
The function pcu_tx_info_ind() fills the trx information in the info
indication. Since the function is already quite long, move the trx
related part into a sperate helper function.
Change-Id: Ic30185c9364adcc61d0a9d3483b0550ac1cdf894
Related: OS#5198
The pcuif only supports a limited but sufficient number of TRXs. When
filling in the TRX array in info_ind, we must guard against overflowing
the maximum number of TRXs
Change-Id: I351080a112f3d3fdf833ee7fa0d77c4cd1d13e42
Related: OS#5198
The formula that is used to recover the (relative) frame number from the
T1, T2, T3 parameters matches the definition in the spec, but since the
partial term t3-t2 can be negative special precaution is required when
performing the MOD 26 operation. This is due to the truncated modulo
implementation in C/C++, which has a very specific understanding on how
to deal with negative input parameters.
The libosmocore gsm_gsmtime2fn(() offers a correct implementation, so
lets use it.
Change-Id: I5fb2b0ada8d409730ac22963741fb4ab0026abdd
Related: OS#5198
The function trx_get_hlayer1() is defined as a prototype but it is not
used anywhere and there is also no implementation, lets drop it.
Related: OS#5198
Change-Id: I91ead9379140e971ccabc83cbf2b62b8aa1fc8a2
The (relative) frame number that is forwarded to the PCU is an
important parameter which is computed from t1,t3,t2.
Change-Id: I83d20ba9e0ce6488d458ccf4a85c8445c30e3a89
When a CHAN RQD is received via RSL, we show ra and other parameters.
Lets also show T1, T3 and T2.
Change-Id: I78499b49ae176b736e384e193fadc0bdd669dffa
The frame number calculation in rsl_rx_pchan_rqd() is done using a
specific formula. Lets add a spec reference and also restructure the
code a bit.
Change-Id: I60500c8694dbc2e6e2c4bbffd4ff7057bbc324e6
TTCN3 have been improved in osmo-ttcn3-hacks.git Change-Id
I6e99ac39f32c9a981420b73f8d7d1568d2fa1c54 to use valid l3 data.
Related: SYS#6280
Change-Id: I4918f1741d465abf8b06a9c65199a44b09778299
IMEI may be used as MobileIdentity during MO emergency call
establishment if the MS has no valid IMSI assigned.
Related: OS#5849
Change-Id: I586b1ee30cbb26ddf58788168d56c962e03ccd5c
The second NSVC MO has been explicit skipped and never been interacted with.
osmo-bts is already supporting it for a long time as well the PCU is
supporting it at least since the NS2 code migration.
Fixes the ttcn3 test case BTS_Tests.TC_pcu_socket_two_nsvc.
Closes: OS#5835
Change-Id: I3486a7cc9a424602b73f8adc2fefce169213e46b
It was found in a BSC on the field that an MS sending an incorrect
MobileIdentity IE (wrong length) in PagingResponse was generating a
crash on the BSC.
When the MobileIdentity cannot be parsed right now we keep on instead of
rejecting the conn. This should change in the future, but it needs
further improvements in our TTCN3 tests. For now let's simply validate
the subscriber is not NULL; since recently paging optimizations made
paging_request_stop() require the subscriber to be non-null.
Fixes: 27cb5d3e24
Related: SYS#6280
Change-Id: If8b439ff74c5dd690d637d3e3278c75d6cd6b928
In send_assignment_complete(), obviously return the current channel
configuration from lchan->current_ch_mode_rate, which is the proper
place to get the channel mode after RSL Chan Activ Ack.
It is interesting to look at the history of this line of code.
lchan->current_ch_mode_rate was added later, so now the mistake is very
obvious.
Related: SYS#6229
Change-Id: I3bf8f5ea9ae2a3c12fc5b483818d550a069fe66e
The array of trx in gsm_pcu_if_info_ind can hold trx 8 items. Lets use a
define constant to specify the size of that array.
Change-Id: I25a9233e7be2d7cda8eb45a4cb9dddd3511d03c9
This patch caches the counts of initial paging requests for each paging
group. This count is needed to estimate T3113 when a new incoming paging
request is received and it has to be inserted into the queue.
With this there's no need to traverse the whole initial_req_list every
time a new incoming paging request is receiving, potentially saving lots
of iteration and hence lots of CPU when the queue is long.
Related: SYS#6200
Change-Id: I6994127827d120a0b4dd3de51e1ddde39f2fe531
If queue size (in transmit delay of requests) is too long (above
threshold) when a new initial incoming request arrives, instead of
directly discarding it, see if we can drop a pending retransmission and
insert the new one instead, in order to avoid losing initial requests.
This is done under the assumption that it is more important to transmit
intial requests than to retransmit already transmitted ones. The
rationale is that there's lower chances that an MS which didn't answer
lately will answer now (aka being reachable at the cell), so it's better
to allocate resources for new requests (new MS) which may be available
in the cell.
Change-Id: Idfd93254ae456b1ee08416e05479488299dd063d
Related: OS#5552
Initial requests: paging requests which haven't been yet transmitted
Retrans requests: paging requests which have already been transmitted at
least once.
Until now one queue was used (llist) to store both. The initial requests
were stored at the start of the queue in FIFO order. After the last
initial requests, the retrans requests followed also in FIFO.
This ordering was used in order to prioritze scheduling of initial
paging requests over retransmit paging requests.
In the end, having both types in the same list only make code handling
the list more complex.
Hence, this patch splits the shared llist into 2 llists.
Related: SYS#6200
Change-Id: Ib68f2169e3790aea4ac77ec20ad79f242b7c2747
When adding a new incoming request (aka "initial_req"), if the queue is
full only of retransmis (no not-yet-ever-transmitted initial requests
queued), then the new incoming request is inserted at the start of the
queue, in order to take scheduling priority over retransmits.
This was already fine before this patch, but the counting of requests
before it (used to calculate its T3113) was wrong, because it counted all
the retransmissions. This patch fixes it to end up with
reqs_before(_same_group)=0.
Change-Id: Ib2e810b0bcc51eac117713584310272462c58867
Philipp Maier
Max
Pau Espin
Vadim Yanitskiy
Neels Hofmeyr