When a CHAN RQD is received via RSL, we show ra and other parameters.
Lets also show T1, T3 and T2.
Change-Id: I78499b49ae176b736e384e193fadc0bdd669dffa
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
This allows configuring the maximum delay of paging requests to be
queued according to other parameters, such as MSC paging request
timeouts, etc.
Related: OS#5552
Change-Id: Ia556ef4e474e6a2d0d1618bab680a3330a3c062b
The default is to have a dynamic T3113. However, if the user wished to
set it statically, it would show up when writing the current VTY config.
Change-Id: If121a97bbb4a0234a0c162ef37c3692d6408404d
The BTS can be obtained easily from the backpointer in req->bts. Having
the extra param can only lead to confusion and introduction of bugs, as
happened in bug fixed by Change-Id
I8c6828f86b7ccbb2c4a09ca1aec859a2c597b679.
Related: SYS#6200
Change-Id: I545fd853fdffce7f23f0d99203c66c3b39144e4b
When rewriting the loop, the pointer passed all the time to
paging_remove_request() was the one of the BTS which answered the
request, not the one actually handling the related unanwared still
active paging request.
Fixes: 70a1d60a83
Related: SYS#6200
Change-Id: I8c6828f86b7ccbb2c4a09ca1aec859a2c597b679
This allows tracking each BTS active paging request queue length over
time, and evaluate CPU load based on the number of active paging
requests queued.
Related: SYS#6200
Change-Id: I6d296cdeba1392ef95fc31f6c04210c73f1b23e5
This way all paging related stats can be grouped (more will be added in
follow-up commits).
Related: SYS#6200
Change-Id: Iede1b6f68df468c7a3b3bf5fce7f68bb08b78832
Use spaces around equals signs inside structs, as expected from the
kernel coding style we mostly follow.
Neels wrote:
> IIUC "T=123" without spaces is my personal favorite that goes against
> the accepted linter standard, i guess rather than everyone else
> adapting to my weird style, i should start adding spaces in my
> patches.
Change-Id: I01ce986a1b0cdd74d945a04ae62a07f2850d366f
Neels wrote:
> i guess we can drop this comment now, it is a remnant from separating
> osmo-nitb -> osmo-bsc + osmo-ms
Change-Id: I2ce4d691715c1ea5c7c7896693a03b0aefbdb5b9
Prior to this patch the whole paging queue of each BTS was iterated.
After the patch only the active paging_req for a given subscriber are
iterated.
Related: SYS#6200
Change-Id: I225d5e08427c6bb9d92ce6a1dccb6ce36053eab5
This is triggered by BSC_Tests.TC_lcs_loc_req_no_subscriber.
Before, the NULL ptr was not a problem because paging_request_cancel()
only used the pointer to compare it against other pointers, but never
accessing it. A follow-up patch is, however, changing the implementation
to optimize the lookup by using the subscriber pointer, which generates
a crash.
Related: SYS#6200
Change-Id: Id0de43ac5bde0f52f258de6c9bf58b173301c8db
Before this patch, the entire queue of paging_request had to be iterated
in order to find if the subscriber already had an active paging request
(discarding duplicates).
Now that bsc_subscriber holds a list of its active paging requests, it's
easier to look at its list to find out if it is already active on that
BTS.
As a result, there's no need to unconditionally iterate the whole list
and we can optimize the loop finding the spot to insert the new queue:
- First the potentially way smaller loop over
bsub->active_paging_requests is done
- Second, only if the first loop allowed, the bts->pending_requests is
iterated and potentially early terminated.
Related: SYS#6200
Change-Id: I7912275026c4d4983269c8870aa5565c93277c5a
This allows havily decreasing the algorithmic cost of removing all
pending active paging requests for a given subscriber once it answers
on a given BTS.
Beforehand, the whole paging queue of all BTS were iterated. Now, only
the active requests for that subscriber are iterated.
Related: SYS#6200
Change-Id: I831d0fe01d7812c34500362b90f47cd65645b666
This saves the BSC from iterating twice the whole paging list of the BTS
which received the paging response.
Related: SYS#6200
Change-Id: I5f9215f31428ce0249cd9ece6d2d4e93155f429f
Prevent BSC overloading in the event of too many BTS try to connect.
E.g. a network outage between the BSC and BTS.
The BSC will accept incoming OML connection, but will delay sending
any BSC originated messages.
Change-Id: Id56dde6d58f3d0d20352f6c306598d2cccc6345d
Unfortunately "-std=c99" is not sufficient to make gcc ignore cold that
uses constructs of earlier C standards, which were abandoned in C99.
See https://lwn.net/ml/fedora-devel/Y1kvF35WozzGBpc8@redhat.com/ for
some related discussion.
Change-Id: Ic92aa70d569778a776f4c5d24c455f71fd50b61b
The number of NSVCs is fixed but lets not use magic numbers to define
the sizes of the arrays that hold the config values. In osmo-pcu there
is already a define constant, so lets use a define here as well.
Change-Id: Ic94dadd3374c6db9323baca83b6b07b89e96768c
The function rsl_ericsson_imm_assign_cmd has a comment "Chapter 8.5.6"
above it. However, thats only half true. The function implements
ericsson vendor specific RSL IEs, so lets be more clear about this in
the spec reference.
Change-Id: Id27662e208ca8ac0a48851583c11fbacf85f988c
When looking up "BCCH-FREQ-NCELL i" from the measurement report, don't
treat the BCCH channel list as one list sorted by ascending ARFCN.
Instead, treat it as two sub lists, one for the same band, and one for
channels in different bands, as described in 3GPP TS 04.08 § 10.5.2.20.
This fixes getting the wrong ARFCN from measurement reports in
multi-band BSS, which leads to failing handovers.
Fixes: OS#5717
Related: osmo-ttcn3-hacks I4fe6bb9e4b5a69ea6204585ebdf1f157a68a8286
Change-Id: Ic5e4f0531e08685460948b102367825588d839ba
Add a test that shows that the ARFCN of neighbors from the measurement
report is not parsed correctly for multi-band BSS. A follow-up patch
fixes it.
Related: OS#5717
Change-Id: Ie18e341f236bab5cf60d3a342c15c96cc848a7c2
In SCCPlite, the BSC receives the CN-side MGCP from the MSC through an
IPA conn, and it then forwards those messages to its co-located MGW
through a rawUDP socket created at startup.
This forwarding UDP socket still relied exclusively on the "mgw.conf"
struct which was filled only by the old VTY interface which was been
deprecated lately.
This patch moves the mgw-pool setup before the msc setup so that if the
VTY config file still uses the old VTY, the single MGW is added to the
MGW pool through mgcp_client_pool_register_single(). It then simply
picks the first available MGW from the pool when creating the raw UDP
MGCP-forwarding socket.
This means SCCPLite is still left with supporting only 1 MGW. If more
than one MGW is defined in the pool, then when the call is being set up
a different MGW could be picked from the pool while the CN-side MGCP
would still be sent to the MGW pool selected at osm-bsc startup.
This limitation coul be removed later on by adding a new VTY command
under the "msc" to pin calls for an MSC to an MGW with a given "mgw_nr"
from the pool, and that same MGW be looked for in the pool every time a
new call is being established.
Another possibility would be to avoid creating the "connected" UDP
socket at osmo-bsc startup, and rather use it in non-connected mode and
transmit (sendto) using the mgcp_client remote address during call
establishment.
In any case, this is left as future excercise since so far there hasn't
been any need for multiple MGWs in SCCPLite setups.
Related: SYS#5987
Change-Id: If105dee52b8d36161c759f979eaef4579b47d365
Commit 53b23c252e introduced a weird line
duplication that instead should have been the way this patch does it.
Change-Id: I5a9a983bb6135059ec01edf054ea3f7165bb6a6f
The adoc file has been moved to osmo-gsm-manuals.git so that it can be
included by other apps supporting MGW pooling from libosmo-mgcp-client,
such as osmo-msc and osmo-hnbgw.
Related: SYS#5987
Depends: osmo-gsm-manuals.git Change-Id Ieda0d4bfe6fc90da6e19c791d8ec2da89427ba3b
Change-Id: Icaee61905fbefe4632b562603fce393b70a114b1
This is a preparation commit before moving mgwpool.adoc to a share place
(osmo-gsm-manuals.adoc) so that other apps like osmo-msc and osmo-hnbgw
can also include this section.
Related: SYS#5987
Change-Id: Id0d292506e8b2a888c8d7a682a38db80e9d0933a
New VTY commands have been added recently to the "mgw" node which drop
the redundant "mgw" prefix on each fo them.
Depends: osmo-mgw.git Change-Id: Id55af13d2ecde49d968b9dca6a2f8108a17ec484
Related: SYS#5987
Change-Id: I71e49cb4d6c2fe54a895aab0b0ba5acc4e57c253
Let's avoid guiding users towards the old deprecated VTY interface.
Line "mgw endpoint-range" is removed since it's nowadays deprected and
implemented as a NOOP.
Related: SYS#5987
Change-Id: Iff74a9efca2a0a2c38d5ac39df704b2b211fd906
Let's use the new API available in libosmo-mgcp-client to control more
consciously where the mgw pool config is printed.
Before this patch, the place where the node was printed was defined
based on implementation details on how the enum of nodes are defined and
installed.
Change-Id: Ib2f04d96ca846d2d61af0b0c0ea1924609004952
Related: SYS#5987
Depends: osmo-mgw.git Change-Id I7a620cf47886d8ecab30ce369cf123d98ab842c5