Age | Commit message (Collapse) | Author | Files | Lines |
|
Related: SYS#6044
Change-Id: I4466e7066115da98d9f45a876d1d468dc0cca25a
|
|
This way it's easier to quickly spot there was a problem with the socket
connection.
Change-Id: I962bf4837a9e359576c42a51a9919891186c7100
|
|
Change-Id: Id8f104a4123fcfbc96ab07f2e9343369946e3334
|
|
This change basically reverts [1]. Oliver's patch allowing to set
SO_REUSEADDR, which is needed for D-GSM mslookup mDNS testing, has
been merged upstream. No need to depend on our own fork anymore.
Change-Id: Idf96a64f3d5f7928ed0fb81f4a91e469df3a9adc
Related: [1] Ie7e1c3dbd67dba9079a5768e442faffc936fd7fa
Related: SYS#4618
|
|
Related: SYS#5895
Change-Id: I93c4689ddc016eb4eb25f8cbdd0142936c6f972b
|
|
Will soon be used by new subdir 'upf' (test osmo-upf),
and by 'hnbgw' (test GTP mapping via UPF).
Related: SYS#5599
Change-Id: I0723b931b3f755ea291bffa2f27c34ba446c2f2f
|
|
Change-Id: I850b79526145307246bca40c70ed8e4d586d8c68
|
|
Helped me find a failure cause: instead of T_guard timeout, immediately
show an unexpected MNCC event.
Related: SYS#5066
Change-Id: I49a15142a4b6c51ca767a884c0574f96e01d7cb1
|
|
continued from Id0c98bc267daff352fc7db7712f967111970fd4d
Upcoming changes to osmo-msc move the CN side CRCX to an earlier point
in time, reversing that order. Introduce an 'interleave' to not care
about the ordering of MGCP and BSSAP messages.
Related: SYS#5066
Related: Ie433db1ba0c46d4b97538a969233c155cefac21c (osmo-msc)
Change-Id: I0ec348df08aa49ed58b3465de51b259fb74c0aea
|
|
We want to add more options later on, and we don't want to be passing
all of them as params. Let's simply set the global fields directly in
the test and let f_init() use the confgured values.
Change-Id: I27b685c2c22cf876b5eba79cf8ad151a2643ecb1
|
|
That config is used to control the use of osmux between BSC<->MSC. Since
we'll add support for Osmux in BTS<->BSC, we want to test that in a
separate way. Let's rename it so that we can add a "use_osmux_bts" later
on.
Change-Id: I3bde4e6772c18043dd763d7747b5dbe40e0da3b8
|
|
As was explained in [1], until recently we relied on trxcon sendig
dummy RR Measurement Reports with patched L1 SACCH Header values.
Now trxcon does not patch it for us, so we need to send Uplink
SACCH blocks with the correct L1H ourselves.
Revision 2 of [1] was successfully tested and proved to fix the
above-mentioned testcases. However during code review I was asked
to make the statements sending Uplink SACCH blocks self-explanatory.
In revision 3 of [1] I modified the code to call f_send_meas_rep(),
which was introduced in [2], which as stated in the commit message
is using g_pars.l1_pars.{ms_power_level,ms_actual_ta} instead of
the values from received L1H. Of course this does not work.
Add and use f_send_meas_rep_l1h(), which allows to send the given L1H.
Take a chance to add a log() statement, so that we can see what we Tx.
Change-Id: Ia79a0a7b06394bd34d0f40226cf40e6e8bd2ba35
Fixes: [1] I31dd6b9026d04403092256176f67785a0a6486ad
Related: [2] Ia5d0315e053702df5fa8dad8c6c66c11c9f3edcb
Related: OS#5635
|
|
Change-Id: Id80317d1e9de3873ab2d26470a3552b4f2b539b1
|
|
There is a time window between activation of a dedicated channel and
receipt of a L1CTL_DATA_REQ with the first RR Measurement Report, in
which the L1 may need to start transmission on Uplink SACCH.
In this case the L1 is using a dummy SACCH block with hard-coded L1
SACCH header values and hard-coded Measurement Results.
Until recently we relied on implementation specific behavior of trxcon
patching the L1 SACCH header in hard-coded dummy SACCH block. This
behavior was changed, so TC_ms_pwr_ctrl_{constant,pf_ewma} started to
fail. Let's properly populate the SACCH cache to fix these TCs.
Change-Id: I89eb90815e86db466ea626f4c25f2634c1d942d5
Depends: osmocom-bb.git I0f467fc07cf844cc73465f235b36ba7d00788c9f
Related: OS#5635
|
|
BSC_Tests_CBSP was sending an ETWS message but using non-ETWS templates
to match the response, which may differ from an ETWS one (for instance,
ETWS related messages have no channel_ind).
Change-Id: I42941655081af6d5b04b1e061e6259d8dee94665
|
|
This test case verifies the new channel allocation mode, which
is expected to switch between ascending and descending modes
dynamically based on the following two configurable parameters:
* Uplink RxLev threshold (and min number of samples),
* C0 (BCCH carrier) channel load threshold.
The test case scenario includes:
Case a) Unknown Uplink RxLev => fall-back to ascending.
Case b) Not enough RxLev samples => use ascending.
Case c) Uplink RxLev below the threshold => use ascending.
Case d) Uplink RxLev above the threshold => use descending.
Case e) Uplink RxLev above the threshold, but C0 load is not.
Change-Id: Ia522f37c1c001b3a36f5145b8875fbb88311c2e5
Related: SYS#5460
|
|
The aim of these new test cases is to verify both ascending and
descending modes of the BSC's channel allocator. Both tests are
using BTS2, which has 4 TRX instances.
The common test scenario can be described as follows:
1. Establish an SDCCH channel, send some dummy payload on it.
2. Send a BSSMAP Assignment Request for a TCH/F channel.
3. Expect RSL CHANnel ACTIVation for a TCH/F channel.
4. Respond with RSL CHANnel ACTIVation NACK (*).
5. Expect a BSSMAP Assignment Failure.
These steps are repeated several times. Note (*) that for the
sake of simplicity, I am aborting the assignment procedure by
sending a NACK, so that the requested logical channel becomes
BORKEN and behaves like an occupied one until the A-bis/OML
link is re-established. This reduces the overall complexity.
Change-Id: Ic74a9cd264320a9a17648f9331b67fb2c2404122
Related: SYS#5460
|
|
Also run the Iu tests for osmo-msc.
Same as we have in docker-playground.git/ttcn3-msc-test/MSC_Tests.cfg
Related: SYS#5066
Change-Id: Ied0449fd0328ee57b66e3cff9d34b0e1d27b9fb4
|
|
So far, the first CRCX dispatched by osmo-msc is used for the RAN side,
and the second one for the CN side. Upcoming changes to osmo-msc move
the CN side CRCX to an earlier point in time, reversing that order.
Allow both RTP addresses from the two MGCP CRCX OK to appear in the
Assignment Request message to RAN, so that the test succeeds for both
the current osmo-msc and the upcoming patch (see below).
Related: SYS#5066
Related: Ie433db1ba0c46d4b97538a969233c155cefac21c (osmo-msc)
Change-Id: Id0c98bc267daff352fc7db7712f967111970fd4d
|
|
Change-Id: I9bf2c513a30c943bf87b47154a10147dc49c3d02
|
|
These tests are currently failing since osmo-cbc doesn't support
reloading cells yet.
Related: OS#5641
Change-Id: I7b1c5275eff56888268601b481e8f8c1dd1bb1b0
|
|
Related: OS#4945
Change-Id: Ie0ab3d4fbe1d9a824b1f69ceacbf7dfd4f0d9728
|
|
Change-Id: Ia868bf739c29d5b4548bbd1417c352ee6400f501
|
|
CBSP RESTART messages are only sen BSC->CBS direction, so it makes no
sense to activate the receival of RESTART messages in the BSC emulation.
Change-Id: I40e78ff4d980050a6142226a7eb9589f2d15e5bd
|
|
Related: OS#4945
Change-Id: I4589af1ddfac4c6e5bbd99e68ebc4b8dc2d5eb36
|
|
Related: OS#4945
Change-Id: Iabeb3e9d86eaf59b76504edf3976a947ae29b911
|
|
Change-Id: I09526f5ac19c80927b6b8ad1cff874a86e0b3a04
|
|
Change-Id: I31f751f5c61de545d038d9e63e01188c3ae5f161
|
|
Change-Id: I89bc9d15548e6c709f0e1b614f00bc98ec41d441
|
|
So far only non-emergency CBS messages were tested, which require a
slighlty idfferent encoding on the protocol side.
Related: OS#4945
Change-Id: I506322fc8a664716db8cd79217c2091b0b926836
|
|
So far only non-emergency CBS messages were tested, which require a
slighlty idfferent encoding on the protocol side.
Related: OS#4945
Change-Id: Ie22a00120218a205db11a5622274dcc67435f5de
|
|
According to [1], 3GPP TS 48.008 does indicate that on AoIP the MSC
Preferred Codec List IE shall be present in BSSMAP HandoverRequest.
Let's verify that the IUT actually includes this IE.
Change-Id: I2e0ecbcced9f94d2b44d981db353007cad3ae959
Related: osmo-bsc.git I117cc29d6d11db77d160de654f43f5993db6ee21
Related: OS#5529
|
|
Change-Id: Ia5ce0c03fd4198e26068ddd1f18f2e17b1ae533d
Related: OS#5529
|
|
We used to rely on trxcon sendig dummy RR Measurement Reports and
patching the L1 SACCH Header with the configured MS Power Level
and Timing Advance values. Since recently, the following testcases
started to fail because trxcon does not patch dummy MRs anymore:
* TC_rsl_ms_pwr_dyn_ass_updown,
* TC_rsl_ms_pwr_dyn_max, and
* TC_rsl_ms_pwr_dyn_up.
Do not rely on dummy MRs, send SACCH blocks with the expected
MS Power Level and Timing Advance values from the testsuites.
f_send_meas_rep() internally uses:
* g_pars.l1_pars.ms_power_level, and
* g_pars.l1_pars.ms_actual_ta.
Change-Id: I31dd6b9026d04403092256176f67785a0a6486ad
Related: OS#5635
|
|
The key difference is that f_send_meas_rep() simply sends an RR
Measurement Report and does not wait until it's received on the RSL.
Change-Id: Ia5d0315e053702df5fa8dad8c6c66c11c9f3edcb
|
|
Test having more than one active CBS message being broadcasted to an
MME.
Related: OS#4945
Change-Id: Ie9208c33f3b2586e19b446318b6ae9da07a76506
|
|
3GPP TS 23.041 9.3.32 states that the IE is always present for non-ETWS
messages and never present in ETWS messages.
The present template is used for CBS messages (non-ETWS) only so far.
Once we add support to test ETWS message this will be updated
accordingly if needed.
Related: osmo-cbc.git I4a5ac56b7e6eeb85aee07ae2ddf10fa2afbbf4ef
Related: OS#4945
Change-Id: I8f2067069ecf0c46f86279413a10e5970ec4456c
|
|
Related: OS#4945
Change-Id: I7d8cf5e6498d03ad340b8f843ce93a20171e9fca
|
|
Related: OS#4945
Change-Id: I9fa4ddfa18ac85644f219874e6b2166e1795e3a9
|
|
Change-Id: I92b0a2ec931cefed34a33bd90cbc5c97d0aec540
|
|
This way we can test how does osmo-cbc behave when receiving such
message.
Related: OS#4945
Change-Id: Ifcdcddc7dccb5439126a5fa29bb540669ed25908
|
|
The BSC/MMEs ports are applied in osmo-cbc.cfg similarly in sequential
order.
Change-Id: Ib443aba9396aebe0a56b1a79719bbcf66302a1aa
|
|
Let's only create BSC handlers (no MM handlers) in tests validating CBSP
specific features.
A new test is added to specifically validate scenarios with both an MME
and BSC attached to the CBC.
Change-Id: I79ee41f183ef49e9fd606d2a3efa2767628bf142
|
|
A comment in f_TC_rsl_ms_pwr_dyn_up() states:
> By default, the MS power loop gets triggered every 4th SACCH block (1.92s).
> We need 9 * 4 dB steps to get from 0 dBm to 33 dBm, so 9 * 1.92s total.
> Add an extra offset to avoid race conditions: +1.92s.
so the alt statement is expected to block for 19.2s, while the guard
timer is set to 20.0s by default. This is not enough, given that
f_TC_rsl_ms_pwr_dyn_up() also needs to wait for the first SACCH block
before entering the alt statement.
Let's give it more time to run in order to avoid sporadic failures.
Change-Id: Ib7de8383c95ac9e00560f786ec4c56f79f7d81bc
Related: OS#5635
|
|
Sending L1CTL_DM_REL_REQ does not make the L1 tune back to CCCH/BCCH.
We need to send a L1CTL_FBSB_REQ after releasing a dedicated channel
if we want to establish another one. This is essential when running
tests using Calypso PHY, and will be required once we have proper
trxcon_fsm implementation [1] merged.
Related: [1] osmocom-bb.git Ifaf63ead9dd180181358e771367b2a686ba159ca
Change-Id: I65fb243a62fc7670b43f467d6b79268cdfb98f36
|
|
This helps to find where the problem is a lot quicker.
Change-Id: I71ab69d85f453964749270d970c55e6f577a73a1
|
|
Move parameter 'fpc' at the end and assign false by default, so that
there is not need to pass false. We never set it to true anyway.
Change-Id: I8a0ef562c2426a637fbb9fe3d50711ee7738d04f
|
|
This went unnoticed before because all tests were running with both bsc
and mme set to 1.
Change-Id: I978c92819cb4e218c95bc719ade71787dc474b23
|
|
* Each BSC_ConnectionHandler emulates a BSC and handles one TCP/CBSP
conn.
* Each MME_ConectionHandler emulates an MME and handles one SCTP/SBc-AP
conn.
* ECBE related functionalities are moved to its own file
ECBE_Components.ttcn.
* CBS_Message is moved to its own file since it is used by all modules.
Related: OS#4945
Change-Id: Ia0300a2ae69bdf604373dbc484537958413c79a2
|
|
Since osmo-cbc.git I563e7d1c999f14b8197bb41e85b7bcf6262fe2a0, Write
Replace Warning Indication is sent, so expect it.
Change-Id: I84e3ae7a532a8a76ac1c26d357da7eaa73f39374
|