I'm not sure why some files did contain an AGPLv3+ header, instead of
the GPLv2+ which is the actual overall project license. I consider it a
mistake.
In any case, any copyrightable contribution to those files was done by
sysmocom employees, so I as managing directory can legally make a
license change, whther or not it was a mistake early on or not.
The only remaining AGPLv3+ files are those implementing the "direct
PHY" interface for osmo-bts-{symo,lc15,oc2g}. That is als
unintentional, but more complex to resolve as they were copied from
osmo-bts, which is indeed an AGPLv3+ project.
Change-Id: I52533193de0ec7e24bf7c5bb035589ba5b9419e4
Until now, if timeslot resources where being allocated for an MS
whose msclass is not known, msclass=12 was being selected.
While it's true that msclass=12 is quite a usual one implemented by
phones (Rx=4, Rx=4, Sum=5), some MS implementations may not support such
modes.
As a result, if the PCU allocates a TBF for an MS which its msclass is
not known (eg. because it used 1-phase access aka no Pkt Res Req), then
a minimal msclass=1 should be assumed. Otherwise, it may assign more
multislots than the MS can handle, and will work incorrectly since an
amount of RLC/MAC blocks won't be sent/received properly.
With the existing code base, changing the default MSCLASS to 1 would,
however, create a worse user experiencie for the vast majority of devices
(which are msclass >= 12). The code should be improved to first use only
1 TS until the MS CLASS is known, and at that point reallocate resources
and re-assign them (eg. RECONFIGURE TBF rlc/mac ctrl blk).
So, for now, simply add a hidden VTY config to allow changing the
default assumed MS Class, so that operators wishing to support all
devices can eg. set it to 1.
Change-Id: If80fdd793db7dad029faa83dbf980ffc4959e2e5
This way the alloc_algo() becomes idempotent, simplifying implementation
of new alloc_algos as well as rolling back if allocation fails (for
instance because some resource is exhausted at the time).
For now the code applying the results is moved to tbf::alloc_algo(), but
it will eventually get out of tbf code, so that the MS object is
responsible for running it. As a result, there's no even need to create
TBF object before trying to allocate resources, which will help furher in
rollback operations described above.
Change-Id: I5ffd00f5f80bde4b73b78db44896f65e70e12b20
This is a first step towards isolating the allocation algorithm from
applying changes on PCU state.
In next steps the tbf pointer will be dropped and the allocation
algorithm will only result a "result" struct which then the caller can
apply to whatever TBF object it requires.
Change-Id: Ie4d9ace526ad012d97738bc55bdb5cc1472c632d
In situations where the PCU is co-located to the BSC, the IMMEDIATE ASSIGNMENT
for downlink TBFs must be sent via RSL and the BSC also must instruct the BTS
to transmit the IMMEDIATE ASSIGNMENT via PCH instead of AGCH. Eventually the
BSC must sent a confirmation message (follow-up patch) where the TLLI is used
as an identifer.
This new method will eventually replace the previous method that uses
the MAC block as an identifier. To remain compatible with older versions
of osmo-bsc, we will keep the old method until osmo-bts is migrated as
well.
This patch also requires new features to be added to the PCU socket
interface the version number of the protocol is incremented from 0x0a to
0x0b. Version 0x0a will remain compatible and use the old method, while
version 0x0b will use the new method introduced with this patch.
Change-Id: I2a78651593323e8b9627c39918d949a33497b70f
Related: OS#5198
We basically want to probe whether it's possible to allocate TBFs, or
whether we know it will fail due to all main resources being already in
use (TFI, USF).
Having bts_all_pdch_allocated() return false doesn't mean though that an
MS will be able to allocate a TBF for sure. That's because further
restrictions are applied based on MS: whether it was already attached to
a specific TRX, whether the ms_class allows for a certain multislot
combination, etc. However, it should provide a general idea on whether
for sure the PCU is unable to provide more allocations. More fine
grained state about failures can still be followed by looking at
tbf:alloc:failed:* rate counters.
Related: SYS#4878
Depends: Iabb17a08e6e1a86f168cdb008fba05ecd4776bdd (libosmocore)
Change-Id: Ie0f0c451558817bddc3fe1a0f0df531f14c9f1d3
While libosmogb / ns2 supports that natively in the VTY, the PCU
doesn't want to use the complexities of the full NS2 vty.
Change-Id: I7bfbad46582e65e5ad2ac0cc66545538bc632df8
Related: SYS#5427
Since a while ago, the data architecture was changed so that TBF is
guaranteed to always have a MS object associated. Hence, it makes no
sense to pass the MS object as a separate param as we can take it from
tbf object and makes code less confusing.
Change-Id: Idc0c76cf6f007afa4236480cdad0d8e99dabec5f
The old VTY command is marked as deprecated and still overrides the use
in case it's used.
Related: SYS#5358
Depends: libosmocore.git Change-Id I74fb0a3afc1ac4aadbfc609b882d929401f790eb
Depends: osmo-bsc.git Change-Id I8b97ea11bad5fe05f2f634945b5703ee9abde81d
Change-Id: I46f2a955b157a409055fca7fb917dc4f75482426
Upon timeout, we move directly to NACC_ST_TX_CELL_CHG_CONTINUE in order
to submit a Cell Change Continue against the MS without providing any
Packet Neighbor Cell Data beforehand, as per spec that's probably the
best we can do in this scenario (TS 44.060):
"""
1) The network responds with a PACKET CELL CHANGE CONTINUE message.
If a mobile station as response to a PACKET CELL CHANGE NOTIFICATION
message receives a PACKET CELL CHANGE CONTINUE message without receiving
any neighbour cell system information, the mobile station shall stop timer
T3208, stop timer T3210 if still running, leave CCN mode and continue cell
reselection in NC0/NC1 mode.
"""
Related: SYS#4909
Change-Id: Ia9932ab082ec095294e85dc4d532046970e17986
A new nacc_fsm is introduced per MS object, with its partner priv
structure struct nacc_fsm_ctx, which exists and is available in the MS
object only during the duration of the NACC procedure.
The NACC context is created on an MS whenever a Pkt Cell Change
Notification is received on Uplink RLCMAC, which asks for neighbor
information of a given ARFCN+BSIC.
First, the target ARFCN+BSIC needs to be translated into a CGI-PS
(RAC+CI) address. That's done by asking the BSC through the Neighbour
Resolution Service available in osmo-bsc using the CTRL interface.
Once the CGI-PS of the target cell is known, PCU starts a RIM RAN-INFO
request against the SGSN (which will route the request as needed), and
wait for a response containing the SI bits from the target cell.
After the SI are received, the scheduler is instructed to eventually
poll a TBF for the MS originating the CCN, so that we can send the SI
encapsulated into multiple Packet Neighbor Cell Data messages on the
downlink.
One all the SI bits are sent, the scheduler is instructed to send a
Packet Cell Change Continue message.
Once the message above has been sent, the FSM autodestroys itself.
Caches are also introduced in this patch which allows for re-using
recently known translations ARFCN+BSIC -> CGI-PS and CGI-PS -> SI_INFO
respectively.
Change-Id: Id35f40d05f3e081f32fddbf1fa34cb338db452ca
This code doesn't do anything yet app-related with the received RIM
messages, but already provides the initial infrastructure to handle them
in the future, and does first checkings.
Related: SYS#5103
Change-Id: Ia0ade0e97ea781ec655439c008b6cefaf3e90dec
This patch doesn't really tests whether osmo-pcu can work on a multi-bts
environment, but it prepares the data structures to be able to do so at
any later point in time.
Change-Id: I6b10913f46c19d438c4e250a436a7446694b725a
Previous work on BTS class started to get stuff out of the C++ struct
into a C struct (BTS -> struct gprs_glcmac_bts) so that some parts of
it were accessible from C code. Doing so, however, ended up being messy
too, since all code needs to be switching from one object to another,
which actually refer to the same logical component.
Let's instead rejoin the structures and make sure the struct is
accessible and usable from both C and C++ code by rewriting all methods
to be C compatible and converting 3 allocated suboject as pointers.
This way BTS can internally still use those C++ objects while providing
a clean APi to both C and C++ code.
Change-Id: I7d12c896c5ded659ca9d3bff4cf3a3fc857db9dd
Both values (optionally) set (forced) by VTY and the values received
from PCUIF were stored in the same variable, meaning that for instance
the PCUIF values wouldn't really be used if someone applied eg "no cs"
during runtime.
This commit does something similar to what was already done for the
max_(m)cs fields. We store PCUIF values in one place and VTY ones in
another place, and then trigger a bts object internal process to find
out exactly which initial CS should it be using.
Change-Id: I80a6ba401f9c0c85bdf6e0cc99a9d2008d31e1b0
Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold
both PCU global fields and BTS specific fields, all mangled together.
The BTS is even accessed in lots of places by means of a singleton.
This patch introduces a new struct gprs_pcu object aimed at holding all
global state, and several fields are already moved from BTS to it. The
new object can be accessed as global variable "the_pcu", reusing and
including an already exisitng "the_pcu" global variable only used for
bssgp related purposes so far.
This is only a first step towards having a complete split global pcu and
BTS, some fields are still kept in BTS and will be moved over follow-up
smaller patches in the future (since this patch is already quite big).
So far, the code still only supports one BTS, which can be accessed
using the_pcu->bts. In the future that field will be replaced with a
list, and the BTS singletons will be removed.
The cur_fn output changes in TbfTest are actually a side effect fix,
since the singleton main_bts() now points internally to the_pcu->bts,
hence the same we allocate and assign in the test. Beforehand, "the_bts"
was allocated in the stack while main_bts() still returned an unrelated
singleton BTS object instance.
Related: OS#4935
Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
Harald Welte
Pau Espin
Max
Philipp Maier