Let's use a 'record of' with indefinite length in order to be able to
dynamically adjust the number of BSSGP_BVC_CT references based on how
many BVCs we have configured.
Change-Id: Id4aa20ff0b553cb8a1f5a67faa1e7b237fb254b8
The hard-coded array of three cell identifiers in the ConnHdlr
configuration doesn't really reflect situations with a different
number of PCUs than three, and a different count of BVCs than one
per NSE.
Let's pass the entire PCU configuration as parameter into every
ConnHdlr. This way, the ConnHdlr can learn whatever cell identities
there mgiht be in whatever number of BVCs of each NSE.
Change-Id: I0bb22be612b8aa256c9ee115ee44ea849c4225e1
This took me quite some time: Tried to use NS_PROVIDER_FR, but the
code was compiled without support for it. It just failed silently
without printing any error or ever sending any message on the FR link.
Change-Id: I96475127a2079830b3456a8e288adf4c6c908887
Let's start a number of per-UE/TLLI component on each BVC, and generate
some uplink traffic with random-payload 512-byte LLC frames. The
FRNET(SGSN) side simply ignores all of those by means of a
CreateCallback.
Change-Id: I1b25b4a650d831bb07e9623b76e6c3dcdd71ac88
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
Harald Welte
Daniel Willmann
Pau Espin
Vadim Yanitskiy
Neels Hofmeyr