The BVCI that this message might contain should not be used to route it.
It referes to the BVCI that the PDUs were transferred to (BVCI (new)).
Instead broadcast to all components.
Change-Id: Ia1df35da44ef28d91501bb898e1059bf1390129b
IF the BSS-BVC is gone gbproxy blocks the BVC towards the SGSN (this is
the only thing it can do since there is no BVC-REMOVE). If the SGSN ever
decides to reset that BVC the gbproxy should not ACK it, but instead
consider the BVCI unknown.
Change-Id: Ic57b39a77adf71abda99ef8af7da1592e2225a0d
Related: SYS#5628, OS#5236
Since we have new releases in -latest, we don't need this param since
it's never set to true.
Related: OS~5042
Change-Id: Ic496407fd2139b3a5221c30f1798797320cdee24
For 12+ days, suspend/resume related SGSN + PCU TTCN3 tets have been failing.
It was the introduction of the BSSGP_CT:GLOBAL test port in
I40d973d80709f5d56f59247e8647b52754f09bc8 +
I805372f3024a0ec2491a24422e02c0bc6dc669d2 which caused the related PDUs
now to no longer show up where they used to.
Change-Id: I1977302fef4868dc1c330bc6f48f6a6608949393
Closes: OS#4902
There are some messages/procedures on a PTP BVC which are not related
to one specific TLLI, but affect the whole PTP BVC. First and foremost
that is the FLOW-CONTROL-BVC. Let's check if the user is interested in
handling those internally (by connecting to the GLOBAL port). If not,
fall back to acknowledging all incoing FC-BVC and ignoring all ACKs.
Related: OS#4891
Change-Id: Ib80a6a522dbcb33fd0e7bd31a73ef28fdc636f57
This port is used for sending/receiving RIM related BSSGP messages. It
exists once per BSSGP_CT Component (i.e. once per NSE), as RIM is global
for the entire NSE.
Change-Id: I04511df5dffbfe19faabf22014acc72b7673b7d6
When the SGSN is sending an OVERLOAD message, we expect that to
propagate down to every BSS on the other side.
Change-Id: Ic61fabd9c633bcb3f256fe7aa5834e66cc66a4fb
the existing ordering of altsteps unfortunately caused some
receive clauses never to be hit, as they are only in the default
altstep, while more generic receive clauses are already in the
state-specific altsteps.
Let's introduce an as_allstate_pre() and an as_allstate_post() to
solve this ordering problem.
Change-Id: Icc4da95833557931d6685826fb30bdc60bf460c1
We recently introduced a MGMT port in the per-BVC component for the
PTP BVC. Let's add this also to the signaling BVC.
Change-Id: I24df4cb290c9f9dc1a7398994af101711f12d42e
This notifies the user via the MGMT port about the fact that an inbound
BVC-RESET procedure just happened.
Change-Id: I54d0d5e0e06a330a90dfb1da06062d65022efe81
We need to change to BLOCKED local state in order to activate
the altstep which handles the inbound BVC-RESET-ACK.
Change-Id: I32ede586f0977b7d96af9fe3ea5fae485184ea98
We cannot handle this in as_ptp_allstate(), as the respective clauses
are never hit: In as_ptp_unblocked() we broadcast all BSSGP messages
without a TLLI, "hiding" the BVC-RESET handling.
Change-Id: Ie3e7a997554e6af42ae7e7294829b6f8d2447d60
The per-NSE BSSGP_CT gets a new GLOBAL port which is used for procedures
that are not specific to one BVC, such as the SUSPEND/RESUME related
PDUs, which all are on the signalling BVC without any BVCI in the BSSGP.
Change-Id: I40d973d80709f5d56f59247e8647b52754f09bc8
The primitive normally only contains NSE + BVCI, but in a tester
we actually want to verify which NS-VC a given message has arrived on,
and hence it makes sense to add the NSVCI, too.
Change-Id: I9402bf0be47e5b93c9cfb081eb8f9fa6734c9227
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
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 existing BSSGP_Emulation is built around the assumption that every
instance of BSSGP_Emulation only servers one signaling-BVC and one
PTP-BVC. While this is true for osmo-pcu at this point (BTS-colocated
PCU), other BSS/PCU implementations differ.
In general, there can always be any number of PTP BVC (one per cell)
next to the signaling BVC (one per BSS). Let's represent this in
BSSGP_Emulation so we can create more comprehensive tests.
Change-Id: I7e30b4c4e188518a574e082962fba457b3a97ce3
This is required by the spec, and implemented libosmocore since
Change-Id Ie87820537d6d616da4fd4bbf73eab06e28fda5e1
So let's change our test expectations. Meanwhile, introduce
mp_tolerate_bvc_reset_cellid for working around the bug in 'latest'.
Change-Id: If6245d73ed701e631b67146ace4ba028bdb4226c
We always used to include the CellID IE, but 3GPP TS 48.018 is
actually quite specific about when it should be present and when not.
Change-Id: Iffd023f0272c9ccb087bdd225fcfb08424a46bdf
Daniel Willmann
Pau Espin
Pau Espin Pedrol
Harald Welte