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
Three test cases covering the MME pool selection logic in OsmoS1GW:
* TC_mme_pool_reject_fallback: S1GW falls back to the next pool entry when the first MME rejects S1SetupReq with S1SetupFailure. * TC_mme_pool_timeout_fallback: S1GW falls back when the first MME does not respond to S1SetupReq within the timeout. * TC_mme_pool_all_reject: all pool entries reject S1SetupReq; S1GW must send S1SetupFailure to the eNB and tear down the connection.
Infrastructure added to support these tests:
* S1AP_Server.ttcn: S1AP_ServerList type; directed register/unregister helpers (f_ConnHdlr_s1ap_register_to / _unregister_from) for use when multiple S1AP_Server_CT instances are active simultaneously. * S1GW_ConnHdlr.ttcn: f_ConnHdlr_s1ap_setup_pool() drives the pool setup sequence: pre-registers with all servers, sends S1SetupReq once (S1GW re-transmits it per-MME), then iterates through the expected behaviors (ACCEPT / REJECT / TIMEOUT) waiting for each server in turn. * S1GW_Tests.ttcn: f_init_s1ap_srv(N) starts N MME emulators on consecutive IP addresses; f_TC_exec_pool() orchestrates pool tests. * osmo-s1gw.config: a 'mme_pool' section with three entries is added alongside the existing sctp_client section. Older OsmoS1GW (without pooling support) will use sctp_client to connect to a single MME and the pool test cases will simply fail, as expected. Newer OsmoS1GW will use mme_pool and all three test cases will pass.
s1gw: add testcases for impatient eNB during MME pool selection
Two new test cases covering scenarios where the eNB disconnects before S1 setup completes, targeting specific states of the enb_proxy FSM:
* TC_mme_pool_enb_disc_wait_s1setup_req: eNB connects but disconnects before sending S1SetupReq (enb_proxy in wait_s1setup_req). No MME connection is ever attempted; S1GW must handle the disconnect cleanly.
* TC_mme_pool_enb_disc_wait_s1setup_rsp: eNB sends S1SetupReq, S1GW forwards it to the first pool MME (enb_proxy in wait_s1setup_rsp), then eNB disconnects before the response arrives. S1GW must detect the eNB disconnect and close the open MME connection in response.
A new helper S1GW_ConnHdlr.f_ConnHdlr_s1ap_close() is added for these tests: unlike f_ConnHdlr_s1ap_disconnect(), it closes the eNB-side socket without waiting for an S1APSRV_EVENT_CONN_DOWN from a pool server (since in these scenarios either no MME connection exists yet, or the CONN_DOWN is captured by the test body directly).
Add three test cases exercising the S1GW REST interface for MME pool management. The REST TCs are gated on the mp_rest_enable module parameter in the control block.
TC_rest_mme_list: query the MME pool list via REST and verify it matches the three static entries from the 'mme_pool' section in osmo-s1gw.config (mme0/mme1/mme2 with their respective addresses).
TC_rest_mme_add_del: add a new MME entry at runtime via REST, verify it appears in both the list and individual GET responses, then delete it and confirm it is gone.
TC_rest_mme_del_fallback: delete mme0 from the pool at runtime and verify that a connecting eNB is routed directly to mme1, skipping the deleted entry. The pool is restored to its original state afterwards via f_REST_mme_pool_restore().
Also add: * {ts,tr}_MmeItem templates to S1GW_REST_Types.ttcn * f_REST_mme_find(): returns the integer index of a named entry in a MmeList, or -1 if not found; used for both presence and absence checks * f_REST_mme_pool_restore(): deletes all current entries and re-adds mme0/mme1/mme2 in original order to keep pool state predictable across test cases
s1gw: enable the REST interface, fix wrong REST port
REST had been disabled because only nightly builds supported it. The latest stable release (v0.4.0) also supports the REST interface, so let's enable it unconditionally by removing the mp_rest_enable.
Also fix the REST port: mp_rest_port was incorrectly set to 8125 (the StatsD port) instead of the actual REST port 8080.
s1gw: use REST interface to check PFCP assoc state
It's quicker to query the IUT using the REST interface rather than waiting for StatsD metric "gauge.pfcp.associated.value" to be received. As a bonus, we "learn" the local/remote RTS from the S1GW, which can be used in new PFCP related testcases.
bsc: fix copy-paste in TC_lcls_gcr_bway_codec_mismatch
The comment says that:
* first call leg uses FR, * second call leg uses HR,
however the code actually modifies the first call leg to use HR.
The test still exercises a codec mismatch, so LCLS non-activation is still triggered, but the leg roles are swapped relative to the stated intent. Fix this to avoid confusion.
TC_uemux_e_rab_release_ind never actually tests the release indication because release_ind is false instead of true. The test body becomes identical to TC_uemux_e_rab_setup - no release indication is ever sent.
Change-Id: Ieed5d8a2bf4f696efc1071569090facc7b731f96 Fixes: cdc149a6 ("s1gw: add UEMux TCs for E-RAB SETUP and RELEASE")
s1gw: fix TC_e_rab_setup_failure: expect a specific S1AP PDU
setup_rsp is carefully constructed, but is not actually used. The f_ConnHdlr_rx_s1ap_from_enb() call falls through to the ? default, so the test accepts any S1AP PDU and never validates that the S1GW actually populated the failed-items list correctly.
s1gw: f_ConnHdlr_conn_track_disable(): set conn_track := null
After deactivate, conn_track still holds the now-dead reference. A second call (which can happen if any test explicitly calls this before f_ConnHdlr_s1ap_disconnect()) will attempt to deactivate an already-inactive default, which is a TTCN-3 runtime error.
On timeout pdu was never assigned (it's an out parameter), so TITAN logs <unbound>. The useful diagnostic is the expected template, not the received value.
These tests are expected to fail since open5gs has no specific logic for emergency services in open5gs-amfd, and announces no Emergency Support in Registration Accept.
Database preparations used to be done in PyHSS by all services if they noticed that this was needed. The time between checking and creating the tables caused a race condition where two services attempting to create tables at the same time will result at one of them failing, we have seen this in our ttcn3-hlr-test-pyhss jobs sometimes:
I have fixed this upstream by letting only the main service (pyhss_hss) prepare the database: https://github.com/nickvsnetworking/pyhss/commit/8b8a2202c345fbb7262c9d07d03003cd2fdb819f
This means that we now need to run the pyhss_hss service in the HLR tests, so pyhss_gsup doesn't fail with:
[Database] [INFO] Waiting for the main service to prepare the database ERROR: 127.0.0.1:4222 did not become available within 5s! [testenv][pyhss] pyhss_gsup: setup script failed
ggsn: TC_pdp(4)6_clients_interact: Expect UEs can interact using global IPv6 address
The link-local IPv6 address is only meant to be used privately between the UE and the GGSN, but the UEs should be in general able to reach each other using their global IPv6 address (unless some operator policy explicitly forbids it).
Since open5gs.git 6cc627c4855703a17c92352660078325c6ce63cc, open5gs-upfd supports proper routing of IPv6 packets between UEs.
osmo-ggsn apparently doesn't implement that internal routing logic yet, so these tests will start failing now, but it's actually legit to have it not passing the test anymore.
Fix unintended if condition removal in recent commit when in the -latest case. That commit expected to leave the -latest path untouched but ended up removing the line. Re-add it.
Since we recently increased a bit the timeout to assume the BSSAP_LE peer (SMLC) is implicitly up, the function f_bssap_le_wait_sccp_peer_available() may still be onging when we drop the sctp connection at the STP in the test, which will generate an explicit DUNA towards BSSAP_LE and hence fail the test because it never comes back available before it times out.
Since we don't need nor test SMLC in this test, simply disable starting the SMLC here to avoid this race condition and simplify the test.
hnbgw: Fix race conditions during PFCP Association
Since osmo-hnbgw now sends Heartbeat Requests, we need to take that into account. Furthermore, since it also now supports retriggering association when detecting peer restarted upon rx of Heartbeat Req, use that to trigger an association to clean up state and have a deterministic way to synchronize at that point regarding state.
BSSAP_LE_Emulation: Increase timeout in f_bssap_le_wait_sccp_peer_available()
It was spotted in SMLC_Tests.ttcn that the current timeout may be too short, and the test fails because ttcn3 connects to STP and receives a DUNA, and then the IUT (osmo-smlc) connects to STP around 4 seconds later, which is too late with existing timeout.
bts: as_rsl_meas_res(): tolerate low RxLev in early reports
The MS is not guaranteed to begin transmitting immediately after activation of the respective logical channel. There is typically a short interval during which the BTS receives no bursts. Consequently, the initial RSL measurement reports are expected to indicate poor RxLev/RxQual values.
We already tolerate bad RxQual values; however, sporadic failures still occur due to low RxLev in the very first report. Extend the logic in f_build_meas_res_tmpl() to tolerate low RxLev as well.
Change-Id: Ic632917d429ec597dba524bf79749944cf1fc628 Related: 8ce558dd ("bts: as_rsl_meas_res(): tolerate bad RxQual in early reports") Related: OS#6933
hnbgw: TC_rab_assign_mgcp_to: Allow hnbgw to tear down CN conn at SCCP level
Newer versions of osmo-hnbgw will be tearing down the CN conn at SCCP level by transmitting an RLSD in this scenario, instead of sending a Iu RANAP Release Request crafted by the osmo-hnbgw itself. The HNBGW is expected to forward RANAP messages between UE/HNB and CN, not to generate them.
The previous logic of not always running "make deps" was useful when "make deps" would take a long time to complete even if there were no changes. But this has been fixed in c7e40d6a ("Makefile: avoid fetching deps if not needed"). Run it every time now in order to fix that deps are not updated after deps/Makefile gets changed.
With this patch it is already possible to transmit the NAS Auth Response in the test ConnHdlr. We still lack generating a proper RES to have the response properly accepted.
testenv: podman: Install newer libcurl from bookworm-backports
It was already spotted a few days ago that libcurl4 7.88.1-10+deb12u12, currently being shipped by debian12, contains some sort of bug where it doesn't properly format/read HTTP2 requests when used in open5gs. It was found out that installing a newer version of libcurl4 fixes the problem. This patch also fixes the problems spotted in the 5gc testsuite when running within podman (they didn't show up outside podman because I'm using Archlinux and hence using newer libcurl 8.13.0 too).
Install eclipse-titan from osmocom:nightly instead of osmocom:latest, which now has version 11. Once we ensured everything works as expected, we will upgrade the version in osmocom:latest too.
