This way code triggered through signal has an updated view of the object
tree when running generic code which queries the current state of
objects.
This way for instance one can use APIs like trx_is_usable() or alike.
Change-Id: Ib46234e3f3e446e866d27b0dfee65edf4af4d2ba
Don't wait until RSL link goes up to check the reported features against
the config. Do it in the OML bring up right after the features are
reported.
Related: SYS#5922, OS#5538
Change-Id: I6b1b4ef3e163528ed186050d848ec089a4315a7c
There's no need to use pointers there, it is only asking for errors from
code handling the data structe from the signal by attempting to change
them. Even for mem size point of view it doesn't make sense, since it's
3 byte vs a 4 byte pointer.
Furthermore, this is a preparation for new commit, where the NM object
current state will be updated before emitting the signal. This patch
eases a lot the follow up mentioned patch.
Change-Id: I9b648dfd8392b7b40bfe2b38f3345017481f5129
Having 2 signals makes all code handling them more complex, specially
because S_NM_STATE_CHG_OPER could actually provide any change in
admin/oper/availability.
Both signals already provided the same kind of data (the whole
admin/oper/avail state change), so let's simply merge the signals
themselves. Current code really doesn't act differently for those 2
signals anyway.
Change-Id: Ia86d20a42b859063d0327b940ba528ec1438b04a
This code is not used currently. Furthemore, it makes little sense to
transmit an OPSTART if the BTS already told us it is enabled (because
OPSTART is what moves the BTS into operational enabled state).
Change-Id: I2c65e0803fbde7de9497089b562275baad58936a
* Don't copy features for osmo-bts and nanobts initially, wait until
BTS reported its features
* Checks for BTS features in VTY cmds: pass if features are not known
(not yet reported by the BTS), fail if the feature is missing
* Once BTS reports its features, check relevant VTY config parts again
Related: SYS#5922, OS#5538
Change-Id: I7fca42a39a4bc98a6ea8b9cfab28c4bad3a6a0aa
As pointed out in code review, for nanobts we need to be able to combine
the reported features with a list of features we assume that the bts
model supports. This is because the enum of features is based on what
nanobts is able to report, but was extended for osmo-bts.
Related: SYS#5922, OS#5538
Change-Id: I7bdbf28c148877275048e070dce7f503ca5e6226
Just log all reported features, instead of comparing them against an
expected set of features and logging mismatches. The point of reporting
features from the BTS at runtime is that the BSC can support various BTS
versions with various feature sets.
Related: SYS#5922, OS#5538
Change-Id: Ibd79bc7ef802d8e95e05d746df182ff974b78e29
abis_nm locally declares its own struct for the ipaccess firmware
header, even though libosmocore defines it as well. Lets use the
definition from libosmocore.
Change-Id: I69cb45fc40bd20ea2533cc8cd6a68363b59cc408
They will gain support to be activated as SDCCH/8 soon too.
Related: OS#5309
Depends: libosmocore.git I56dcfe4d17899630b17f80145c3ced72f1e91e68
Change-Id: Id5b89fe589a52ff88486435ac43809edb4b80f98
Prepare for VAMOS, where there will be secondary "shadow" lchans serving
secondary MS on the same timeslots. For those, RSL messages will need to
reflect a different stream ID aka TEI, via an rsl_link_vamos.
Make sure that every code path that sends an RSL message for a specific
lchan selects the RSL link via the new function rsl_chan_link(). When
VAMOS is implemented, this function can select the proper RSL stream.
Rename gsm_bts_trx.rsl_link to rsl_link_primary. This makes sure I'm not
missing any uses of the RSL link, and clarifies the code.
Related: SYS#5315 OS#4940
Change-Id: Ifbf16bb296e91f151d19e15e39f5c953ad77ff17
So far the function uses insane byte array magic numbers to compose the
OML "RSL Connect" message. For VAMOS, I intend to modify that message.
To ensure sanity, first change the attr composition to msgb_put*().
Related: OS#4940
Change-Id: Iba005635cf86aee1fde77d58ef203e28eed92281
The reported feature vector may contain new features the BSC is
not aware of. Report each of them individually as NOTICE.
It's normal when some BTS feature is considered as not supported
by the BSC, but a BTS reports that it is - do not log this.
Change-Id: I2f925bcdb010cb10d074bf7c82619e3ae1f8818b
There's no real need to retrieve the trx before passing it to the
function, we can do that in the function itself and hence also simplify
the function itself.
Related: OS#4870
Change-Id: I7181510c5021ff2712c09ebc6ec8b13fdd8e8dc2
The only real 1-1 relationship between BTS NM objects is the one between
GPRS Cell and BTS (which is actually a BTS cell).
In our current osmo-bts implementation we don't care much since we only
handle 1-cell BTSses, but let's make the data structure organization
more generic.
Implementation notes:
The gsm_bts_sm is moved to its own file, APIs to allocate are added and
the new public object is hooked correctly in the allocation process of
osmo-bsc.
Change-Id: I06461b7784fa2a78de37383406e35beae85fbad8
During the A-bis/OML bootstrapping, osmo-bsc sends Opstart to the
Radio Carrier MO twice. The first Opstart is triggered by the
State Changed Event Report, originated by the Radio Carrier itself.
The second is triggered by Software Activated Report.
According to 3GPP TS 12.21, figure 2, we shall send it only once,
after the "Attribute setting" step. Therefore, the first Opstart
is premature, and we shall not send it.
Related: SYS#5063, OS#4755
Change-Id: If69393551117266ecb726d8961153560b2b3cc59
In the big mess of gsm_data we reached a point where we have multiple
functions doing the same thing, most probably because it's hard finding
stuff in there. Let's drop one of them (the one which less callers) and
move it to bts.*, where it belongs.
Change-Id: I9071a0ab250844619280fbe2be63ed99f2c87eb1
Place all code related to the object into the related file.
Having all the data model in one file made sense in early stage of
development to make progress quickly, but nowadays it hurts more than
helps, due to constantly growing size and more and more bits being
added to the model, gaining in complexity.
Currently, having lots of different objects mixed up in gsm_data.h is a hole
of despair, where nobody can make any sense were to properly put new stuff
in, ending up with functions related to same object in different files
or with wrong prefixes, declarations of non-existing functions, etc.
because people cannot make up their mind on strict relation to objects
in the data model.
Splitting them in files really helps finding code operating on a
specific object and helping with logically splitting in the future.
Change-Id: I00c15f5285b5c1a0109279b7ab192d5467a04ece
There are a number of OML messages which are not seen on IP based
BTSs. Those are perfectly normal and expected on E1 based BTS.
Change-Id: Icd87fc9f3652b21f9d569af2572d080c9ac89e8b
Closes: OS#4665
Found while playing with "rf_locked 1" on a 2TRX setup with channel
allocator descend. After applying the setting, the 1st TRX is still used
to allocate the channels. After this patch is applied, the BSC correctly
allocates channels from TRX0.
Change-Id: I5201d2749363c9cbd0706177bde09117b163cbe3
This message may contain optional IEs (HSN, MAIO, ARFCN list),
so we cannot know the final length in advance. Let's set both
msg->{l2h,l3h} pointers and use msgb_l3len() to get the length.
Change-Id: I948ad4b847921324794a6eabd95d5583324da6e4
Related: OS#4545
3GPP TS 12.21 defines coding of 'ARFCN List' attribute as follows:
+---------------------------+--------------------+
| Attribute Identifier | 1st octet |
+---------------------------+--------------------+
| Length | 2-3 octets |
+---------------------------+--------------------+
| ARFCN1 | 4-5 octets |
+---------------------------+--------------------+
| ... | ... |
+---------------------------+--------------------+
| ARFCNn | (n * 2 - 3) octets |
+---------------------------+--------------------+
so this is basically TL16V, where L16 is the length of V.
In the Siemens dialect of OML coding rules are different though:
+---------------------------+--------------------+
| Attribute Identifier | 1st octet |
+---------------------------+--------------------+
| ARFCN count | 2nd octet |
+---------------------------+--------------------+
| ARFCN1 | 4-5 octets |
+---------------------------+--------------------+
| ... | ... |
+---------------------------+--------------------+
| ARFCNn | (n * 2 - 2) octets |
+---------------------------+--------------------+
so this is TCV, where C is the amount of ARFCNs in V.
This change fixes encoding of 'ARFCN List' for other dialects,
in particular encoding of the 'Length' field (1 vs 2 octets).
I verified the results in Wireshark (generic 3GPP TS 12.21
and ip.access dialect), everything looks good.
Change-Id: Iec1826f55459ac8e9355328a1a6bb0949874db60
Related: OS#4545
The value of the feature vector can not only be greater, but also
shorter than size of the buffer! This would potentially result
in a buffer overrun. Let's fix this.
Change-Id: I65e3228022865ea73de2e4821985df3097b9448b
Pau Espin
Oliver Smith
Vadim Yanitskiy
Philipp Maier
Neels Hofmeyr
Harald Welte