Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: Ifd16e8129b4440542b82a47749df1547a061ae88
|
|
Change-Id: Ie9d86e1b651dff279e7d50a4282bf14fbed5bb76
|
|
Change-Id: I5cc25ccb8e0d169b6f85e597fda47fdd2130aa70
|
|
Change-Id: Ieed010a15675b105807bc8c55bb0977fcb6aa7f3
|
|
Change-Id: I37db9962f51baf2c63bd58ec47ec89f773d7a255
|
|
"val" field is not used in GET commands and is hence set to omit by
TTCN3 decoder.
Change-Id: If1a273a2be71040eaea2189a0aeaf737adf848e5
|
|
The template set we use for testing the GB (BSSGB) interface on
osmo-sgsn and osmo-pcu lacks templates to generate RIM (ran information
management) messages. The records and unions are already specified in
BSSGP_Types.ttcn, we just need to form templates in order to be able to
use them.
Change-Id: Ic495e0bb6ceb2b65cbc7c3da7ee519a013aede55
Related: SYS#5103
|
|
The emulation of an SGSN with SNS was incomplete. The SNS
procedure was completed. However the NSVCs didn't moved
into an unblocked state.
Also sending a NS_ALIVE at the beginning is wrong.
Change-Id: I54c2d9d5b34d791be354298171d04180a9b263c3
|
|
The BVC-RESETs are a little bit more complicated. The PCU will send
a BVC-RESET after the NSE become available.
Ensure the RESET is received and ignored so there is no race condition
if both sides send a BVC-RESET at the same time.
The test case TC_sns_1c1u_so_bvc_reset is still failing because the PCU can't
handle BVC-RESETs properly (both PTP and signalling).
Change-Id: Id681749d75073c1d50a4b0a2e86f0a2dd0955b45
|
|
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
|
|
Change-Id: Ie087ee8e8adfb963d21f35c60628214d4297250d
Closes: SYS#5210
|
|
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
|
|
... to indicate this is about the signaling BVC only.
Change-Id: I646db452c89842465902b5167c9c86de51df1241
|
|
Change-Id: Ib9a09fea85110a4f0966c07d911e37234aa06391
|
|
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
|
|
Particularly in case both sides initiate a BLOCK or UNBLOCK procedure
at almost the same time, it can happen thet we're already in BLOCKED
state and receive a late BLOCK-ACK or in UNBLOCKED state and receive a
late UNBLOCK-ACK.
Let's just silently discard them instaed of generating NS-STATUS which
may confuse the peer.
Change-Id: I2e5b934e1cf6c6cf982d5ab1dbb32e8920b91071
|
|
These allow passing N vty configurations on the bts / msc node without
requiring subsequent 'exit'.
As an example, use f_vty_cfg_msc() in BSC_Tests.ttcn AMR config.
Change-Id: I9f3e485f692acb3d2a7620e9b454b372651be78e
|
|
f_vty_config2() makes it convenient to enter a specific vty node without
needing to send 'exit'/'end' explicitly. However, to pass multiple
commands on the same node, the VTY would enter and exit the node for
each call of f_vty_config2(). The new f_vty_config3() also allows
multiple commands to be run on that same node without intermediate
exiting.
Change-Id: If969ac645aa82e5a36245d974de2a251633de111
|
|
When the SGSN is sending an OVERLOAD message, we expect that to
propagate down to every BSS on the other side.
Change-Id: Ic61fabd9c633bcb3f256fe7aa5834e66cc66a4fb
|
|
This tests the LLC-DISCARDED message, which relates to a BVCI but
is itself sent on BVCI=0. We expect it transparently passes from BSS
to SGSN.
Change-Id: I98d02d6fa68bddf15b732d06dab00e91e72995d1
|
|
Change-Id: I1e46e5c403712eb7972c57e6b6f6eb0850b96ae3
|
|
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
|
|
Change-Id: I7c9cda916f6583613fbf3cdf31f3f08ceadf58d4
|
|
Add a log label argument to f_vty_wait_for_prompt(), and feed the sent
command from f_vty_transceive*(), so that the failure verdict already
lists the vty command that caused the failure.
A common error is to issue insufficient 'exit' commands, so that I often
think the newly added VTY command failed, even though it is a subsequent
command causing the failure. I want to shorten the "time-to-aha" there.
Change-Id: Icfd739db150d86e9256a224f12dc979dcd77879f
|
|
Change-Id: I0d8f18d0e6438a98c75ff24e2a9c8136d8b417d2
|
|
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
|
|
Change-Id: I587ec89471083e339065f6371ffe6253d49007bf
Related: SYS#5210
|
|
Change-Id: I57ef98b9a3022ed5915381504aa129979799bee8
Related: SYS#5210
|
|
Change-Id: Id432022fdd7f96bc014f0fd81658fa4aa796a688
Related: SYS#5210
|
|
Change-Id: I9b225249d135399f63d3c7e4c567121dfea63f75
|
|
The value part of this IE is defined as vendor-specific.
Change-Id: I48703c45d26cd88c1d9b5fda1a9df42616cb7cc0
|
|
Change-Id: Ica1ea41ebba5c518d515a211e77ca6651c4173d6
|
|
Change-Id: Ib9bd7268b8a0fd8ed64064871c09fab35e15a761
|
|
In some cases GsmArfcn itself is not enough. It case of L1CTL
and GSMTAP, it needs to be equipped with a band discriminator:
- DCS / PCS (as the numbers may overlap),
- Downlink / Uplink (not yet there).
Let's rename this record and move it to GSM_Types. Also, add
send / receive tamplates, so we can add new fields later.
Change-Id: I7a63f03bbd15a06caafb786122dc12991d115771
|
|
Change-Id: Ida44b62dfdb9c4ce2755de63d51a9907d34f247f
|
|
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
|
|
Change-Id: I4ca156b53dfe9daa190d52a7de46be56cf74099a
|
|
Change-Id: I6d49eb4907c4568d88da5d6fd7962e388a3607fb
Related: SYS#5210
|
|
Change-Id: I9f1b621a8365e69d2e1a33d59cb8c7a59639ad94
|
|
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
|
|
Change-Id: I023b3d24a31d117f05c7327b08e9f8f930720944
Related: SYS#5210
|
|
Change-Id: If7e5a5cab1e445e0b4ef0466990e352143c31245
|
|
Change-Id: Ib4a1d64da634813b49474c13ae080d729bbabcf1
|
|
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
|
|
Change-Id: I0d6555f8644e39da6124be2e861d57fda3b3d8a1
|