Test that when the BTS NACKs a CHANnel ACTIVation with RSL_ERR_SERV_OPT_UNAVAIL or RSL_ERR_SERV_OPT_UNIMPL, the BSC: does NOT mark the lchan as BORKEN.
As per 3GPP TS 48.008 §3.2.1.25, HANDOVER PERFORMED must report the target cell. Add an optional cell_id parameter to the template (defaulting to '?' for backward compatibility) and update the two intra-BSC handover test helpers to assert that the Cell Identifier IE carries the target BTS (BTS 1: MCC=001 MNC=01 LAC=1 CI=1).
Also remove the unnecessary interleave wrapper in f_tc_ho_during_lcs_loc_req(): the two receives arrive on separate ports (RAN_CONN vs BSSAP_LE) so sequential receive is sufficient.
The f_sleep(0.5) to delay the registration of the PC for the 2nd SCCP connection sometimes fired too late and we received the VGCS/VBS Assignment Request before the channel ConnHdlr was registered in RAN_Emulation. Then in turn we need to delay call establishment until the channel is ready. Implement proper synchronization points to make sure the order of registers is accomplished while making sure the 2 ConnHdlrs are registered before they need it.
The test failed sporadically with: "RAN_Emulation.ttcnpp:600 Dynamic test case error: Sending data on the connection of port BSSAP to 659:SCCP_SP_PORT failed. (Broken pipe)"
That's because it was simply waiting for a fixed amount of time while letting the underlaying RAN_Emulation do the RESET procedure. Sometimes it started tearing down the test before the procedure was fully completed, and RAN_Emulation failed passing the Reset (ACK) up the stack because the component was already unmapped.
Fix the issue by making sure the RAN_Emulation finished the RESET procedure before stopping the testThe test.
The test failed sporadically with: "RAN_Emulation.ttcnpp:600 Dynamic test case error: Sending data on the connection of port BSSAP to 659:SCCP_SP_PORT failed. (Broken pipe)"
That's because it was simply waiting for a fixed amount of time while letting the underlaying RAN_Emulation do the RESET procedure. Sometimes it started tearing down the test before the procedure was fully completed, and RAN_Emulation failed passing the Reset (ACK) up the stack because the component was already unmapped.
Fix the issue by making sure the RAN_Emulation finished the RESET procedure before stopping the testThe test.
The f_sleep(0.5) to delay the registration of the PC for the 2nd SCCP connection sometimes fired too late and we received the VGCS/VBS Assignment Request before the channel ConnHdlr was registered in RAN_Emulation. Implement proper synchronization points to make sure the order of registers is accomplished while making sure the 2 ConnHdlrs are registered before they need it.
stp: m3ua: Expect unsolicited ASPIA ACK after unblocking ASP
Since libosmo-sigtran.git Change-Id If32902575e874d2acc9a5fc12509af42ed151739, osmo-stp will send an unsolicited ASPIA ACK to the peer whenever the ASP becomes unblock, in order to somehow give a chance to the peer to notice something changed and for instance possibly attempt re-activation of the ASP.
stp: m3ua: Fix incorrect RCTX being sent in TC_combinedlset_loadshare
An ASPAC was being sent containing an RCTX of an unrelated AS to the sending ASP. Newer libosmo-sigtran properly validates AS/RCTX is associated to the ASP in the local config, and hence now returns an error properly making the test fail.
Related tests already existed for STP_Tests_M3UA, but we want to explicitly test against M3UA_TCP since these tests involve the transport layer directly.
Related tests already existed for STP_Tests_M3UA, but we want to explicitly test against M3UA_TCP since these tests involve the transport layer directly.
s1gw: generalize f_TC_e_rab_setup_failure() for N E-RABs
The existing TC only tested PFCP Session Establishment failure with a single E-RAB. Generalize f_TC_e_rab_setup_failure() to use g_pars.erabs throughout, so it works for any num_erabs: E-RAB 0 still triggers the only PFCP Session Establishment Request (S1GW processes sequentially), while all E-RABs in the request are expected to appear in the failure response.
Add TC_e_rab_setup3_failure() which re-uses the same body with num_erabs := 3, verifying that the S1GW lists all three E-RABs as failed rather than just the first one. Also make f_tr_E_RABList() non-private so it is accessible from S1GW_Tests.ttcn.
s1gw: generalize f_TC_e_rab_setup_failure() for N E-RABs
The existing TC only tested PFCP Session Establishment failure with a single E-RAB. Generalize f_TC_e_rab_setup_failure() to use g_pars.erabs throughout, so it works for any num_erabs: E-RAB 0 still triggers the only PFCP Session Establishment Request (S1GW processes sequentially), while all E-RABs in the request are expected to appear in the failure response.
Add TC_e_rab_setup3_failure() which re-uses the same body with num_erabs := 3, verifying that the S1GW lists all three E-RABs as failed rather than just the first one. Also make f_tr_E_RABList() non-private so it is accessible from S1GW_Tests.ttcn.
Companion setter for the existing f_PFCPEM_get_recovery_timestamp(). A follow-up patch uses this to inject a specific Recovery Timestamp value into the emulation, so the IUT does not detect a spurious PFCP peer restart between test cases.
TC_pfcp_heartbeat_periodic: verify that the IUT sends periodic PFCP Heartbeat Requests and that the heartbeat timer re-arms correctly after each successful response (at least 2 periodic HBs must be observed).
TC_pfcp_heartbeat_miss_threshold: verify that the IUT resets the PFCP association after mp_pfcp_heartbeat_miss_count consecutive unanswered Heartbeat Requests (a new Association Setup Request is expected).
TC_pfcp_heartbeat_miss_reset: verify that a successful Heartbeat Response resets the miss counter; run 2 cycles of missing (miss_count - 1) HBs then responding to one, expecting no association reset throughout.
TC_pfcp_heartbeat_rts_mismatch: verify that the IUT detects a UPF restart when a Heartbeat Response carries a different Recovery Timestamp than the one observed during Association Setup, and that it promptly resets and re-establishes the PFCP association.
Also add module parameters for the heartbeat configuration (mp_pfcp_heartbeat_interval, mp_pfcp_heartbeat_req_timeout, mp_pfcp_heartbeat_miss_count) and update osmo-s1gw.config accordingly.
s1gw: f_ConnHdlr_pfcp_assoc_handler(): handle already-connected case
Previously, f_pfcp_assoc() would skip spawning a connection handler entirely if the IUT was already PFCP-associated. This was fine for tests that only need an association to be present, but upcoming PFCP Heartbeat test cases need the emulation's Recovery Timestamp to be synced with what the IUT has stored, even when re-using an existing association.
Move the state check into f_ConnHdlr_pfcp_assoc_handler(): if the IUT is already connected, sync PFCPEM's Recovery Timestamp to the value the IUT remembers (rrts); otherwise perform the full Association Setup as before. Remove the now-redundant g_pfcp_assoc component variable from test_CT - it's not accessible by ConnHdlr(s) anyway.
s1gw: TC_pfcp_heartbeat: validate RTS in Heartbeat Response
The test case had a TODO noting that the Recovery Timestamp in the Heartbeat Response was not yet validated. Let's get this resolved: query the IUT's PFCP association state via REST to obtain its local Recovery Timestamp (lrts), and verify that the IUT echoes back that same value in the Heartbeat Response.
This feature is right now not implemented in open5gs and hence the test is expected to fail, since it returns no AlwaysOn Indication in PDU Session Establishment Accept.
This feature is right now not implemented in open5gs and hence the test is expected to fail, since it returns no AlwaysOn Indication in PDU Session Establishment Accept.
Replace `self.stop` with `Misc_Helpers.f_shutdown()`, and add it after existing `setverdict(fail, ...)` calls that previously fell through.
In all these cases there is no meaningful way to continue: the caller of these functions usually expects a valid value to be returned, and continuing (not stopping) oftentimes results in confusing DTEs.
s1gw: f_REST_*(): use tr_HTTP_RespBody(decmatch T:?)
Pass `exp := tr_HTTP_RespBody(decmatch T:?)` to f_http_transact() in every REST helper that decodes the response body. This ensures both a 2xx status code and a decodable body are required before any decode attempt is made, producing an informative "Unexpected HTTP response" verdict (rather than a confusing DTE) when e.g. an older osmo-s1gw returns HTTP 404 with an empty body for an unsupported endpoint.
eIM_Tests: align RSP version number in HTTP header
The RSP version number in the x-admin-protocol header string should be set to v.2.1.0 (gsma/rsp/v2.1.0), even though the ASN.1 spec we currently use is at version 2.5.
This is to maintain compatibility with older IPAd versions and also stated explicitly in GSMA SGP.32 V2.1, section 6.1.
There's no procedure to do direct mobility between GERAN/UTRAN and 5GS according to spec, and IP preservation is not supported either through indirect mobility GERAN/UTRAN<->EUTRAN<->5GS.
Regarding 3GPP TS 23.502 Annex G, open5gs-smfd supports Gn interface but only when working against a 4G MME, not through 5GS (PCF and AMF).
Related specs: *3GPP TS 23.501: ** 5.17.2.4 Mobility between 5GS and GERAN/UTRAN ** Annex L (normative): Support of GERAN/UTRAN access * 3GPP TS 23.502 4.11.5 Impacts to 5GC Procedures * 3GPP TS 23.632 5.3 5GC-EPC Mobility Scenarios
There's no procedure to do direct mobility between GERAN/UTRAN and 5GS according to spec, and IP preservation is not supported either through indirect mobility GERAN/UTRAN<->EUTRAN<->5GS.
Regarding 3GPP TS 23.502 Annex G, open5gs-smfd supports Gn interface but only when working against a 4G MME, not through 5GS (PCF and AMF).
Related specs: *3GPP TS 23.501: ** 5.17.2.4 Mobility between 5GS and GERAN/UTRAN ** Annex L (normative): Support of GERAN/UTRAN access * 3GPP TS 23.502 4.11.5 Impacts to 5GC Procedures * 3GPP TS 23.632 5.3 5GC-EPC Mobility Scenarios
