Skip to content
Unstable

Changes

Summary

  1. RAN_Emulation: Support Tx RESET retries in RANAP (details)
  2. BSSAP_LE_Emulation: Support Tx RESET retries (details)
  3. BSSAP(_LE)/RANAP: Proper counting of RESET retries (details)
Commit 5cfc6f9805f640e3125fa1454836265872fa9996 by Pau Espin Pedrol
RAN_Emulation: Support Tx RESET retries in RANAP

As already done in BSSAP in the same module.

Change-Id: I84553ae7aee19efa007bae060d7f7ca218a5f306
The file was modifiedlibrary/RAN_Emulation.ttcnpp
Commit 863ad897ff0adf128b546cf7757ac4f1ee7ed61d by Pau Espin Pedrol
BSSAP_LE_Emulation: Support Tx RESET retries

Have same code as we use in RAN_Emulation.ttcnpp.

Change-Id: I475f93ff0b8cbfa5aa4900d02ddcb2e97fa5ca6a
The file was modifiedbsc/MSC_ConnectionHandler.ttcn
The file was modifiedlibrary/BSSAP_LE_Emulation.ttcn
The file was modifiedsmlc/BSC_ConnectionHandler.ttcn
Commit a323f0b37d7c87c5535ddde886e9db9a5ab5542a by Pau Espin Pedrol
BSSAP(_LE)/RANAP: Proper counting of RESET retries

N retries means N+1 attempts.

Since M3UA_Emulation (in deps/, not in library) doesn't support pushing
DUNA/DAVA as primitive up the stack, we cannot implement the related
SCCP primitives which should end up sending in turn other primitives to
our BSSAP(_LE)/RANAP emulations.
This means we currently have no way  to figure out the status of the
underlying SCCP/MTP link, and our only way is implement a poor man's
solution: retransmit RESET until we get an answer.

Since before bssap_reset_retries was set to 1 everywhere and we were
only attempting once, it could happen that the other end (the IUT) was
not yet connected to the STP when we send the RESET, and hence it is
discarded the STP. In that scenario, we'd time out and fail the test.
Instead, now that we do N+1 attempts, we retry after 5 seconds, which
should be enough time for the peer to reconnect to the STP.

Change-Id: If02e424672ff6270aed323c3bb236e822d8a39a4
The file was modifiedlibrary/RAN_Emulation.ttcnpp
The file was modifiedlibrary/BSSAP_LE_Emulation.ttcn