Let's generalize the data types a bit, and move the gb (bssgp) config
into a module parameter. That parameter then is used for both the PCUs
as well as (concatenated) for the SGSN side.
This allows the configuration file to have more control over the number
of BVC within each NSE.
Change-Id: I43a3a8e133cf0f0e377b64d1b385e88285246957
This port can (optionally) be connected to, and it will receive
state change notifications as well as permit the user to block/unblock
and reset the specific PTP BVC.
Change-Id: I1f0289c8805168e3daace4a7d76764b45cead3d0
The existing BSSGP Code assumed that the TLLIs were always known "a
priori" by the test case. With the newly-introduced create_cb,
the user can provide a function to handle any incoming messages for an
unknown TLLL. The default handler behaves like before: fail +
terminate.
Change-Id: Ice0e145f5a6518ff79547dd851042b7965f38e00
In If1220852785853f8a5d8de183d5053ddd6ccb958 I introudced a config
file typo in the GBProxy_Tests.cfg. Let's fix that
Change-Id: I78b6307d16abd37e77e66e511f91a8dda902b58d
The template restrictions are quite useful, becaue they give hints
to the TTCN-3 compiler, so it can spot more bugs. For example,
the lack of thereof would not prevent one from passing 'omit' to
a template, that assigns a value to a non-optional field, so that
might lead to a DTE at run-time in some cases.
Since adding 'template (restriction) ' to each template parameter
obviously makes templates look more cumbersome, let's move the
part with template name and arguments onto a separate line, just
like it's sometimes done for function definitions in C.
Change-Id: I7e6846381e0b3fb611059fcfbafb19bd6c15cfd8
It will be easier to use this list / array in non-L1CTL specific
records and templates, e.g. in (RR) Immediate Assignment.
Change-Id: I392299eea9a82168f893a72d06872c280b6fbdce
The new altstep reduces code duplication and simplifies access
to the L1 SACCH Header. It uses dec_SacchL1Header() to decode
the header, and would apply the received TA / MS Power level
values by default (see 'do_apply' parameter).
Change-Id: Ie593d9b06aea694fb0903a6d26ee387d8da4c82d
Related: SYS#4918
When doing load simulatin, the amount of console printing becomes a
serious throttle factor. We don't need to see the decode of every
message.
Change-Id: Ic988d1e1d60c9d03d5b70e9b38f109b47569b89e
Those functions don't depend on any L3 specific data structurs, and
it is not a good idea to burden every user with having to impot all
of a 2G/3G Layer3 just to generate some hexstring identifiers.
Change-Id: I6fc41ed94e97e0ec44dc4ea56d110bdd9ac77a72
Those functions don't depend on any L3 specific data structurs, and
it is not a good idea to burden every user with having to impot all
of a 2G/3G Layer3 just to generate some hexstring identifiers.
Change-Id: I7880633a46afc607f16f8aa6ea1a277f7958c95b
We don't want the number of NSE and the number of BVC to be a
compile-time choice, but rather something dynamic at rutime. This
allows configuration files to define those details.
Change-Id: I55b44481b5322deaf78619c1689462d716ddfcec
The Load Sharing Function distributes traffic among all unblocked NS-VC
within a NS-VCG. The sharing is done based on a LSP (Link Selector
Parameter) which is passed with the NS-UNITDATA.req primitive from BSSGP
to NS. Details are implementation specific, but NS must ensure that all
traffic of one LSP is always sent through the same NS-VC, as long as
that NS-VC is alive/unblocked.
We use the LSP as follows:
* Signaling BVC always only uses lsp 0
* PTP BVC messages unrelated to user straffic use a per-BVC static LSP,
which is the BVCI
* User traffic can set whatever LSP it wants
* NS keeps an array of NSVCs currently unblocked and uses the LSP modulo
the array size as an index into it
Change-Id: I8b960ec4d729f50cadca353bb52685311cd45eed
Related: SYS#5084
In case of a NS-VCG with multiple NS-VC, we must BVC-RESET only when the
first NS-VC becomes unblocked, i.e. as soon as we have any connection
to the peer at all. Whether we have further additional links doesn't
matter, at least not in the sense that all state should be reset.
Change-Id: I69b2e9bd919fc981f189b6671b4234c3642e2449
This is something we need to simulate more complex scenarios,
particularly in the context of frame relay.
Change-Id: If1220852785853f8a5d8de183d5053ddd6ccb958
The test sets random bits for SI5 and expects to see those in dl SACCH. That
can only possibly work when that SI5 was actually sent to the BTS.
Change-Id: I0d3a96f5ae932734e986637ca2cb23805eba6829
Previous commit implemented the CS/MCS verification, and hence now some
tests fail because they had too restrictive checks.
In theory the verifications could be done so restrictive by configuring
the PCU accordingly at the start of the test, but we are not
really interested in checking the exact CS/MCS in these tests, only
checking if GPRS/EGPRS is being used.
Change-Id: I79b81d473b7428b57a0ec501c5bd0d88e35c81e3
Let's provide this information to higher layer since CS is mostly
discovered by original bitstring size which is available during
decoding.
Call the size2mcs converter in each function to avoid having to pass it
as a parameter and have it selfcontained, meaning one can simply call
decode(bitstring) from TTCN3 code and be done with it.
Change-Id: I80ed44e575cc0a11510832e5bbfc07173e7b75b8
Once GPRS/EGPRS multiplexed support is ready, it will be controlled
through pcu info_ind.flags by enabling
MCS or not; the "egprs only" VTY comamnd will be dropped.
The usual setup would be to support both GPRS+EGPRS, so make that the default.
Most tests require to be passed the _noMCS variant to work in older
versions of PCU, since those versions use the "egprs only" concept which
will reject egprs_ms_class=0. Same tests enabling MCS in newer osmo-pcu
shouldn't be a problem.
Related: OS#4544
Change-Id: Ib95aae155b0712313a30f0c5404a8cb1f28b98f5
Harald Welte
Pau Espin
Vadim Yanitskiy
Neels Hofmeyr