Submit RAB Modification Req towards HNB to udpate its peer IuUP address if MGW changed it
Due to ip probing used at MGW and specific/complex routing in place between RAN and CN, it may happen that, on the RAN-side endpoint connection, the MGW first selects a local IP address.
Then, after the HNBGW signalling it to the HNB with the patched RabAssReq and receiving the HNB local IP address through RabAssResp, then applying it to MGW through MDCX, it can happen that the MDCX ACK contains a changed local IP address at the MGW, due to IP probing after learning the remote address.
This change is so far not announced to the HNB in anyway, ending up in the HNB sending IuUP packets to the wrong IP/port, which is rejected with ICMP due to osmo-mgw having no socket open there anymore.
The sequence goes like this:
HNBGW <- MSC: RAB-AssignmentRequest [A.A.A.A:35932] HNBGW -> MGW: CRCX HNBGW <- MGW: CRCX ACK [IN IP4 B.B.B.B audio 3806 RTP/AVP 96] HNBGW -> HNB: RUA-RAB-AssignmentRequest [B.B.B.B:3806] [IuUP INIT + INIT ACK on C.C.C.C:16400 <-> B.B.B.B:3806] HNBGW <- HNB: RUA-RAB-AssignmentResponse [C.C.C.C:16400] HNBGW -> MGW: MDCX [C.C.C.C:16400] HNBGW <- MGW: MDCX ACK [IN IP4 D.D.D.D audio 3808 RTP/AVP 96] !!!! HERE THE IP+PORT AT MGW CHANGES!!!! PROBABLY DUE TO ROUTING CONFIG AND IP PROBE!
We should at least, in osmo-hnbgw, if detecting the local MGW IP address changed during MDCX, tear down the call setup.
The best would be, though to signal the change of IP address to the HNB, using Rab Modify Req. See related spec in 3GPP TS 25.413 section 8.2:
For the CS domain, when an ALCAP is used, UTRAN shall report the successful outcome of a specific RAB to establish or modify only after the Iu user plane at RNL level is ready to be used in UL and DL. At a RAB establishment, the transport network control plane signalling required to set up the transport bearer shall use the Transport Layer Address IE and Iu Transport Association IE. At a RAB modification when Transport Layer Address (IE) and Iu Transport Association IEs are included, the RNC shall establish a new transport bearer. The transport network control plane signalling shall then use the included Transport Layer Address IE and Iu Transport Association IE. Then the switch over to this new transport bearer shall be done immediately after transport bearer establishment and initialisation of the user plane mode. If Transport Layer Address (IE) and Iu Transport Association IEs are not included, then the RNC may modify the already existing transport bearer. For the PS domain or for the CS domain when an ALCAP is not used, when they are present at a RAB modification, the RNC shall use the embedded Transport Layer Address IE and Iu Transport Association IEs as the termination point of the new transport bearer. For the PS domain or for the CS domain when an ALCAP is not used, for each RAB successfully modified, if the RNC has changed the Transport Layer Address IE and/or the Iu Transport Association IE, it shall include the new value(s) in the RAB ASSIGNMENT RESPONSE message.
- Status changed from New to Feedback
- % Done changed from 0 to 90
IP-address change at MGW reported through MDCX ACK to the HNBGW announced to HNB is now tested in TTNC3 HNBGW_Tests with the following patchset:
remote: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/35164 hnbgw: Rename mgcp conns to reflect each side peer [NEW]
remote: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/35165 hnbgw: Rename record CrcxResponse->MgwResponse [NEW]
remote: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/35166 hnbgw: Allow announcing a different mgw-local IuUP address after MDCX [NEW]
remote: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/35167 hnbgw: Introduce test TC_rab_assign_mgw_iuup_addr_chg [NEW]
Support for it is implemented in osmo-hnbgw in here:
https://gerrit.osmocom.org/c/osmo-hnbgw/+/35168 mgw_fsm: Modify RAB on HNB if IuUP local IP addr at MGW changes during MDCX