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)
* Cancel Location while Idle Fix
* Forgot about SGSAP on MME Change.
Added "action" to sgsap_send_detach..
* Make handle_clr uniform with other handlers
* Added Robustness for Any Detach Type
* Memory wasn't freed upon CLR for unknown IMSIs
* Moving MME Detach to new PR
* [MME] Support for Insert Subscriber Data
* Supported AVPs in IDR will overwrite existing subscription information
* Provide error on partial APN updates
* IDR and ULA use same function to process AVPs
* Move subdatamask values into s6a, so both HSS and MME can use them
* Updates are not actioned at this time. A Re-attach is required for
most changes to take effect
* Memory issue on IDR exceptions
* Remove of handling MSIDSN change until DSR is used
* Add Diameter Dictionary Elements
* Initial IDR Framework
* Resolve Compile Issues
* Moving Closer
* Compile error
* Somewhat Working stuffing Code
* Add Timestamp Changes
* Cleanup some of this code. mme_s6a_handle_idr in s6a-handler.c removed for now, since it will only come in handy when IDR flag is set to request current location, which would involve breaking out into paging. I think there's a few other things we can do just within fd-path first.
* further removal of mme_s6a_handle_idr
* CLR while idle is broken after 7031856cd7
Cancel Location Request arriving while UE is idle will not proceed to paging due to this check for S1 connection. Using new flag "isAnswer" to bypass this check to allow paging to occur when we are not doing a AIA/ULA related procedure.
* No Context Setup is required when sending the detach request. If the paging was due to wanting to send a Detach Request to the UE, then we fast track to sending the detach request.
* emm-sm.c:
In the case of MME initiated detach while UE is idle, there is no initial conext setup. We go right from the service request after paging into sending the detach request. TS23.401
mme-path.c:
Using nas_eps.type in the case of MME Initiated Detach while UE is idle does not work. nas_eps.type would represent the service request.
mme-s11-handler.c:
After S11 action, no action should be taken. We want to wait for the detach accept from the UE before proceeding with the S1 release (detach).
* InitialContextSetup should occur for detach.
- Added diameter dictionary definitions for Cancel Location
- Cancel Location will completely remove UE from MME, allow for a fresh IMSI attach to occur on next attempt.
- T3422 is used for detach request.
- Added new handling for s6a events in mme-sm, as not all s6a messages are at attach now. Maybe there's something in a state machine I should've been using here instead of a new flag?
- Testing was completed with UE in idle and connected. With CLR flags indicating re-attach required and without. Also sending CLR after UE detach. And then sending again when mme_ue is empty.
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
In the past only GTPv2C was supported, and had the "gtp" generic prefix.
Later on, GTPv1C support was added, and "gtp1" prefix was used.
Let's move GTPv2C specific bits to have "gtp2" prefix too, and leave
"gtp" prefix for generic stuff among different GTP versions.
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.
Most of the time, an application wants to perform some amount of data buffering
in addition to just responding to events. When we want to write data,
for example, the usual pattern runs something like:
1. Decide that we want to write some data to a connection;
put that data in a buffer.
2. Wait for the connection to become writable
3. Write as much of the data as we can
4. Remember how much we wrote, and if we still have more data to write,
wait for the connection to become writable again.
Now, Open5GS implements the above method by default when transmitting data
in a stream type socket.
Pau Espin
Sukchan Lee
jmasterfunk84
Bostjan Meglic
Kenny Barlee