In an Inter-RAT setup a UE could perform a TAU coming from a 2G/3G network.
In that case the UE/MS is unknown to the MME and it should request the
SGSN context (MM, PDP) from the old SGSN. 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
Diagram with full set of steps can be found at 3GPP TS 23.401 D.3.6.
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).
The reverse direction, aka UE issuing cell reselection 4G->2G was
already implemented (same as here, initial non-complete implementation)
in open5gs-mmed in commit 3d693da73e.
Related: https://osmocom.org/issues/6294
Within the PathSwitchRequest packet,
the E-RABToBeSwitchedDLList has two bearers.
If the E-RAB-ID of both bearers is 5, the MME's list memory is destroyed
and the MME crashes. To fix this issue, we modified the code so that
the MME can work correctly with invalid S1AP messages.
This will be useful for other procedures where only the RAI is known,
but not the specific CI. This is the case of idle mobility from Gb or Iu
to EUTRAN, where MME needs to request contexts based on the RAI mapped
in the GUTI obtained from the UE during TAU.
This also makes the config more resilient in RIM scenario, where an SGSN
can be picked now even if CI doesn't match, instead of failing or faling
back to the default route SGSN.
While they were continuing their fuzzy testing and developing PacketRusher, an unusual issue with the AMF was observed. The problem arises when a single Ethernet frame containing three bundled SCTP chunks is sent. This behavior is reproduced with PacketRusher when attempting to concurrently register two UEs with the same MSIN.
The expected behavior is that the PDU Session Establishment Accept is sent inside a DownlinkNASTransport to RAN UE NGAP ID 1. However, it is actually sent inside an InitialContextSetupRequest to RAN UE NGAP ID 2. The MAC of this NAS message is invalid for the Security Context of RAN UE NGAP ID 2 (probably valid for RAN UE NGAP ID 1)
../lib/core/ogs-list.h:62:24: warning: invalid conversion from 'void*' to 'ogs_list_t*' {aka 'ogs_list_s*'} [-fpermissive]
../lib/core/ogs-rbtree.h:79:32: warning: invalid conversion from 'const void*' to 'const ogs_rbnode_t*' {aka 'const ogs_rbnode_s*'} [-fpermissive]
[SBI] Fix compiler error - possible uninitialized variable
[SCP] Fix compiler error - Error: this condition has identical branches
In case of additional compiler warnings turned on, the compiler warns
about potentially unused variables. Fix those issues.
Both types are defined under lib/proto/type.h, and the conversion
function is used in several different protocols, so let's better move it
to generic lib/proto/conv.h and remove the "gtp2" prefix.
The assert is checking for sess->session->name, but afterwards there's a
check to skip ses->session not being null, which means the assert can
crash while dereferencing sess->session.
I've resolved an issue where sending continuous
'PDU Session Release Request' message to the same session,
when more than two sessions were created, was causing an SMF crash.
For your reference, this problem did not occur
when only one session was created.
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
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
This information will be required by the Gn interface in MME when
answering an SGSN with an "SGSN Context Response" message during MS cell
reselection EUTRAN->GERAN.
* [AMF/MME] UEContextReleaseCommand in Integrity (#2786)
Modified not to send UEContextReleaseCommand in Integrity Unprotected
NAS message such like Registration or Service request.
* [AMF/MME] UEContextReleaseCommand after Interity Protected (#2786)
Modified not to send UEContextReleaseCommand in Integrity Unprotected
NAS message such like Registration or Service request.
Allow network operators to omit the time zone in the 4G EMM Information
and 5G Configuration Update. This is useful for better compatibility
with some UEs.
The parameter is optional according to:
* 4G: 3GPP TS 24.301 Table 8.2.13.1
* 5G: 3GPP TS 24.501 Table 8.2.19.1.1
Bug:
In case that AMF does not have subscription data for the UE,
PDU session remains unreleased after implicit de-registeration.
The exact test case:
- UE registered (integrity protection applied)
- UE deregistered (Nudm_SDM_Unsubscribe, Nudm_UECM_Registration (purgeFlag))
- UE registered, PDU session activated
UE data are still stored in AMF. So if integrity protected applies,
the steps 4 - 14 [ETSI TS 123 502 V16.7.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/16.07.00_60/ts_123502v160700p.pdf) are skipped.
Only AM Policy Association Establishment is performed.
- UE is moved out of radio coverage, 2 x (4 min + Timer t3512) expires
Result: UE is implicitly de-registered, PDU session is not released
The steps of implicit de-registeration:
1. Implicit Timer Expiration
2. UDM_SDM_Unsubscribe
3. UDM_UECM_Deregistration
4. PDU session release request
5. PDUSessionResourceReleaseCommand + PDU session release command
6. PDUSessionResourceReleaseResponse
7. AM_Policy_Association_Termination
So PDU session release is performed after the confirmation of
UDM_UECM_Deregistration.
Since there is no UDM_SDM subscription, the UDM steps are skipped
and PDU session is not released.
Fix:
If the AMF does not have subscription data for the UE which registers,
the AMF registers with the UDM using Nudm_UECM_Registration and
retrieves subscription data with Nudm_SDM_Get.
[ETSI TS 123 502 V16.7.0](https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/16.07.00_60/ts_123502v160700p.pdf), 4.2.2.2.2 General Registration, 14a-c:
> If the AMF does not have subscription data for the UE, the AMF retrieves the Access and Mobility Subscription data, SMF
> Selection Subscription data, UE context in SMF data and LCS mobile origination using Nudm_SDM_Get.
1. UE sends RegistrationRequest to AMF.
2. AMF sends Nudm_UECM_Registration to UDM.
3. UE sends RegistrationRequest to AMF.
4. GMM state is gmm_state_authentication
5. UDM sends Nudm_UECM_Registration response to AMF.
6. AMF crashs since no Handler in gmm_state_authentication state
According to 3GPP TS 29.510, the search parameter "tai" should be a
single item, not an array of items.
TS 29.510: Table 6.2.3.2.3.1-1:
URI query parameters supported by the GET method on this resource
Revert "[SBI] Change discovery option TAI from array to single item"
This reverts commit b4beff1ae16c64b3c6d84d8bdb47c36e19b705f2.
wip
This commit splits filling Requested-Service-Unit, Used-Service-Unit and
QoS-Information into their own helper functions for better readibility,
and then partially reverts 125740727e,
where lots of AVPs were left out of INITIAL_REQUEST messagesi during the
changes made.
After looking through 3GPP TS 32.299 and rfc4006, it seems expected to
send Requested-Service-Unit only during INITIAL_REQUEST, and
Used-Service-Unit during UPDATE_REQUEST, so that part is kept.
However, I am not able to find clear indications that AVPs such as QoS
Information and RAT-Type should not be sent during INITIAL_REQUEST.
So, since we have the info, better set it already during
INITIAL_REQUEST, since the OCS may want to grant different resources
based on that information if available too.
* [AUSF] Fix removing UE context on authentication removal request
AUSF crashed when trying to access ausf_ue->sm fields after they were
already deleted.
* [AMF] Delete UE authentication result after UE deregisters from 5G core
Based on TS 29.509 - 5.2.2.2.5 Authentication Result Removal with 5G AKA
method:
In the case that the Purge of subscriber data in AMF after the UE
deregisters from the network or the NAS SMC fails following the
successful authentication in the registration procedure, the NF Service
Consumer (AMF) requests the AUSF to inform the UDM to remove the
authentication result.
Bostjan Meglic
jmasterfunk84
Sukchan Lee
Gaber Stare
Pau Espin
Emanuele Di Pascale
Stare Gaber
Oliver Smith
gstaa
Bostjan Meglic
Šimon Lukašík