library/s1ap: fix wrong IE ID in E-RABReleaseListBearerRelComp (details)
library/s1ap: fix wrong field in S1AP-RABReleaseInd (details)
library/s1ap: add templates for INITIAL CONTEXT SETUP (details)
library/s1ap: fix wrong IDs in {ts,tr}_S1AP_InitialCtxSetupResp (details)
Commit
faa6fc2d3083e1d074a3a3e6ca8714c920a6d453
by laforge
library: add generic Mutex API for parallel components
In certain scenarios, it's required to ensure that only one of multiple parallel components executes a specific code block at any given time.
This, for example, is the case for the S1GW testsuite, where we want to simulate multiple eNBs establishing E-RABs. Each new E-RAB triggers the IUT (osmo-s1gw) to send a PFCP Session Establishment Request, and there is no way for the PFCPEM to correlate which session belongs to which eNB. This problem can be solved by ensuring that only one eNB is triggering the PFCP Session Establishment Request(s) at a time.
This patch implements a generic Mutex API, which can also be used by other testsuites that orchestrate multiple parallel components.
Commit
aaa88deeb3ef7f53f9867438ee7fcad9b7df8e11
by laforge
library/PFCP_Emulation: a better PDU routing concept
In recently merged 2962d170 I wrongly assumed, that SEID of outgoing PFCP PDUs can be used to correlate and route the incoming PDUs. In fact, the PFCP peers use two different SEID values, negotiating them using the F-SEID IE.
We could have implemented a logic to look for F-SEID in the outgoing PDUs, store and then use it for routing. However, a more flexible approach is to allow the the PFCP_ConnHdlr components to subscribe and unsubscribe to/from specific SEID values explicitly.
In this spirit, let's allow the PFCP_ConnHdlr components to subscribe and unsubscribe to/from broadcast PDUs (i.e. those, for which the PFCPEM component could not find a single recipient) explicitly.
Implicit routing using the SeqNr remains unchanged and will be performed by the PFCPEM component automatically like before.
Change-Id: I25802471519fa297ad4cb2b056adaa6748b00af2 Related: 2962d170 "library/PFCP_Emulation: fix routing of incoming PDUs"
Commit
19ef9f42928774f09248f907795c6cbf8c31cf84
by laforge
library: as_pfcp_ignore(): log SeqNr of received PDUs
Printing the PFCP PDU template ('?' by default) is not very informative when reading logs. Printing the message type of the received PDU is not informative either, because message types are defined as numbers in PFCP_Types.ttcn. Printing the whole PDU is way too verbose, and would be redundant given that the PFCPEM component already does print all received PDUs. Let's print the sequence number.
Commit
ff60a63c2aa656978cfdaf5958e21fadf8462ef5
by laforge
Revert "s1gw: cache PFCP Recovery Timestamp in ConnHdlr"
This reverts commit 7ad95e1cfb00d269069bd052c44a9cae9027f763.
A follow-up commit will remove the need for each ConnHdlr to call f_ConnHdlr_register_pfcp(), that among with handling the PFCP association retrieves a PFCP Recovery Timestamp from the PFCPEM.
Caching the PFCP Recovery Timestamp value is not really worth it, since it's rarely used and can always be retrieved on demand.
Commit
17f589464ba4063f12f3b03a9a958f492ad6d88f
by laforge
s1gw: move PFCP association handling into a dedicated ConnHdlr
Previously, the PFCP association request from the IUT was handled by the first ConnHdlr component (idx := 0). While this approach has worked, it fails when multiple ConnHdlr instances (idx > 0) are spawned.
The problem arises when other ConnHdlr (idx > 0) instances initiate PFCP procedures before the first ConnHdlr (idx := 0) has established the association, so we end up playing races.
This patch introduces a dedicated ConnHdlr component to handle the PFCP association independently. Once the association is established, the actual test ConnHdlr instances are spawned, ensuring a more reliable and orderly process.
Commit
2f6d76c9dd982fbf9c6660e875fb6d3aa3beced6
by laforge
s1gw: add multi-eNB variants of TC_e_rab_setup
The idea is to simulate multiple eNBs establishing one or more E-RAB(s) simultaneously. In order to achieve that, use the new Mutex API to ensure that only one ConnHdlr component is triggering PFCP session establishment at any given time.
The problem is that there is no way for the PFCPEM component to correlate which PFCP session belongs to which eNB when multiple ConnHdlr instances establish E-RAB(s) in parallel. This can be solved by making a part of the test scenario synchronous.
![[Jenkins]](/jenkins/static/62d04a6b/images/svgs/logo.svg){kind=logo}
