In an Inter-RAT setup a UE could perform a RAU coming from a 4G network.
In that case the UE/MS is unknown to the SGSN and it should request the
SGSN context (MM, PDP) from the MME. This is done through the following
GTPv1C message exchange on the Gn interface of SGSN and MME:
SGSN -> MME: SGSN Context Request
SGSN <- MME: SGSN Context Response
SGSN -> MME: SGSN Context Acknowledge
This commit doesn't aim to be a complete implementation of the mentioned
procedure, since it's quite a complex one, with lots of fields and logic
required. This so far only implements in general the minimally
successful case by filling as much as possible the required set of
fields.
This will allow for a base onto which do incremental improvements and
fixes while testing against UEs and SGSNs (such as osmo-sgsn, which
doesn't yet support this procedure but will potentially earn it soon).
This commit doesn't implement the reverse direction, aka UE issuing cell
reselection 2G->4G. Initial support for this scenario will hopefully be
added soon as a follow-up patch, similar to this one.
Related: https://osmocom.org/issues/6294
(cherry picked from commit 3d693da73e)
Move the config to the sgsn node instead of having a specific route with
specific format "default: route", since anyway internally it's already
applied to the sgsn object.
ogs_pool_init() shall be used in the initialization routine.
Otherwise, memory will be fragment since this function uses system malloc()
Compared with ogs_pool_init()
ogs_pool_create() could be called while the process is running,
so this function should use ogs_malloc() instead of system malloc()
* [MME] Introduce aging timers
* Creating three new timers
* mirroring work done by gstaa on the AMF
* Implicit detach procedures added
* Fix for detach from unknown UE
* no Purge Timer, no config, expanded code
Without this change, using metrics with core setup configurations
(configs/vonr.yaml for example) would not be possible. Having one
metrics section for whole config file causes every NF to start metrics
server on same port causing an abort.
The problem occurred in the following scenario:
1. VLR sent PAGING-REQUEST to the MME
2. MME sent S1-Paging to the UE
3. Paging failed
4. MME responded SERVICE-REQUEST to the VLR
5. VLR sent DOWNLINK-UNITDATA to the MME
6. Even though there is no S1 Context,
MME try to sent DownlinkNASTransport message to the UE.
7. So, the problem occurred.
I've changed the number 4 PAGING-REJECT instead of SERVICE-REQUEST.
When a UE that requests slices tries to connect and there are no slices configured, the reject message is:
5GMM cause = 0x7 (5GS Services not allowed)
however it should be:
5GMM cause = 0x3e (No network slices available)
All 5GMM cause value in reject message is reviewed in this commit
All process will be forcely exited if it failed to encode the S1AP/NGAP/GTP/PFCP message. It is to make sure there was no problem with the encoding of open5gs.
Pau Espin
Sukchan Lee
Shigeru Ishida
jmasterfunk84
Bostjan Meglic
Carlos Giraldo