This commit adds Xn and N2 handover procedures to the Home-Routed Roaming code.
Direct forwarding is now fully operational.
Indirect forwarding for N2 handovers is not yet supported.
To preserve the GTP-U header and extension header (even without QER)
along the source gNB -> V-UPF -> target gNB path, future work will create
PDRs without Outer Header Removal IE and FARs without Outer Header Creation IE
and implement the necessary UPF logic.
* [AMF] Fix UE context transfer when only NRF is client
If UE context transfer is initiated and the new AMF does not get the
old AMF from NRF or no UE context is retrieved from the old AMF,
we do not want to reject UE registration. Send identity request instead.
Test "transfer-error-case" is added into the commit.
* [tests] Unite tests for UE context transfer
All tests for UE context transfer with different configs are placed
into test folder transfer.
* [tests] Make two binaries for UE context transfer tests
For each test config a different test binary is created.
This commit adds support for processing network-initiated PDU Session
Modification in a home-routed roaming context, following section 4.3.3.3
of the specification.
- Add support for PDU Session Release in 3GPP TS 23.502 section 4.3.4.3
Note: PCF-initiated release flow for Home-Routed Roaming is not implemented;
- Fix N4 release step ordering in 3GPP TS 23.502 section 4.3.4.2 UE or network requested PDU Session Release for Non-Roaming and Roaming with Local Breakout
Previously, policies were configured via YAML files without MongoDB.
This update enhances the YAML approach by adding the 'supi_range' key to
filter policies based on UE SUPI ranges. When both 'supi_range' and
'plmn_id' are provided, both conditions must be met.
Note that PLMN-ID filtering will be deprecated in a future release.
In case that mapped HPLMN SST was not set by the UE in the request to
Establish PDU Session, AMF/SMF would assume it is set to 0 (since the
recent change to allow SST value 0).
Added support for binding to local IP addresses in ogs_sctp_client and
ogs_sctp_server, and correct SGsAP configuration
Implemented the ability to bind to one or multiple local IP addresses using
`sctp_bindx()` in both the `ogs_sctp_client()` and `ogs_sctp_server()` APIs.
Users can now specify local addresses in the configuration files under the new
`local_addresses` field, reducing unnecessary complexity and signaling caused
by binding to `ANY_ADDR`.
This update addresses issue https://osmocom.org/issues/6509 by ensuring
correct operation in multi-interface and complex networking setups.
Additionally, corrected the `sgsap` configuration by changing it
from `server` to `client`, and added support for specifying `local_addresses`
for local binding as follows:
```
sgsap:
client:
- address: msc.open5gs.org # SCTP server address configured on the MSC/VL
local_address: 127.0.0.2 # SCTP local IP addresses to be bound in the M
```
- Added support for the N9 For Roaming interface type:
- Core interface act as V-UPF.
- Access interface act as H-UPF.
- Modified V-UPF behavior:
- V-UPF updates only the TEID and IP Address in the GTP-U header.
- The content following the Extension Header is passed through directly
between the UE and H-UPF.
This implementation ensures seamless data flow between the UE, V-UPF, and H-UPF
while maintaining integrity for Home Routed Roaming scenarios.
While experimenting with CSFB, it was observed that when the UE returns
to E-UTRAN after a CS call, the UE performs a Tracking Area Update
with a combined Tracking Area/Location Area update and IMSI attach.
Currently, Open5GS's MME simply responds with a TAU Accept message
but does not inform the MSC/VLR.
As a result, no further MT (Mobile Terminated) CS/SMS services are possible
in cases where the MSC/VLR only attempts paging on GERAN.
However, some MSC/VLR implementations with fast fallback may still attempt
paging on E-UTRAN, allowing MT CS/SMS services to function intermittently.
According to 3GPP TS 29.118 Section 5.2.2 Procedures in the MME,
specifically Section 5.2.2.2.1, if the timer Ts6-1 is not running,
the MME shall start the location update for non-EPS services procedure
upon receiving a combined Tracking Area Update Request indicating
combined TA/LA updating with IMSI attach. However, SGs timers are not
implemented in Open5GS, which is a separate issue.
To comply with the specification and ensure that the MSC/VLR is informed
when the UE becomes reachable via SGs, the following changes have been
implemented:
1. Delay UEContextReleaseCommand:
When the active_flag is set to 0, the UEContextReleaseCommand is now delayed
until the MME receives the TAU Complete message from the UE. This ensures
that the UE has acknowledged the new P-TMSI before the network releases
the context, maintaining proper synchronization between the UE and the network.
2. Include Mobile Identity Only When P-TMSI Changes:
The Mobile Identity is now included in the Attach/TAU Accept messages
only when the MSC/VLR updates the P-TMSI. This ensures that the UE receives
the Mobile Identity information solely when there is an actual change
in the P-TMSI, preventing unnecessary or incorrect handling
of TAU Complete messages.
3. Send SGsAP-REALLOCATION-COMPLETE Conditionally:
The SGsAP-REALLOCATION-COMPLETE message is now sent to the MSC/VLR
only upon receiving a Attach/TAU Complete message from the UE.
This confirmation indicates that the UE has successfully updated its P-TMSI,
ensuring that the MSC/VLR is accurately informed of the change.
4. Handle P-TMSI Confirmation:
When the MSC/VLR updates the P-TMSI, Open5GS stores the new P-TMSI
in the next field of the mme_ue structure. Upon receiving the TAU Complete
message from the UE, indicating acknowledgment of the new P-TMSI,
Open5GS confirms the update by transferring the P-TMSI from the next field
to the current field. This ensures that the MME maintains an accurate and
up-to-date record of the P-TMSI as confirmed by the UE.
1. Set packet filter identifier values to 0 when the UE requests to:
- Create new QoS rule
- Modify existing QoS rule and replace all packet filters
- Modify existing QoS rule and add packet filters - As specified in TS24.501, section 9.11.4.13, Table 9.11.4.13.1.
2. Revise QoS rule modification logic:
- Instead of replacing packet filters based on their identifiers (EPC approach), update the implementation to delete all existing packet filters within the QoS rule and add new ones.
- This ensures that when modifying an existing QoS rule to replace all packet filters, the packet filters are correctly reset and updated per 5G Core requirements.
- **Correct Packet Filter Identifier Handling:**
Remove the addition of +1 when searching for the packet filter context using `smf_pf_find_by_identifier()` in the 5G Core SMF. According to 3GPP TS24.008 Section 10.5.6.12 and TS24.501 Section 9.11.4.13, the Packet Filter Identifier should range from 1 to 15 (or 0 to 15) depending on the operation and should be used directly as received from the UE.
- **Adjust Maximum Number of Packet Filter Identifiers:**
Change the maximum number of Packet Filter Identifiers from **16** to **15** in the SMF to comply with the 3GPP specifications. The standards specify that the number of packet filters shall be greater than 0 and less than or equal to 15 for certain operations.
**Background:**
In the current 5GC implementation, the SMF incorrectly adds +1 to the identifier received from the UE and allows up to 16 identifiers, leading to mismatches and potential communication issues. These discrepancies cause the SMF to fail in correctly locating the packet filter context, resulting in improper QoS rule enforcement.
**Changes Made:**
- **For Packet Filter Identifier Handling:**
- Updated the SMF code to use the identifier received from the UE directly without modification:
```c
// Corrected code for 5GC:
pf = smf_pf_find_by_identifier(
qos_flow, qos_rule[i].pf[j].identifier);
```
- **For Maximum Number of Packet Filter Identifiers:**
- Adjusted the code to enforce a maximum of 15 packet filters as per the specifications.
**Impact:**
- **Compliance:**
- Ensures that the 5GC implementation of Open5GS adheres to the 3GPP TS24.008 and TS24.501 specifications regarding Packet Filter Identifier handling and limits.
- **Functionality:**
- Corrects the mapping and management of packet filters between the UE and SMF in 5GC, preventing potential communication issues and misconfigurations.
- **EPC Implementation:**
- The EPC implementation remains unaffected by these changes. EPC correctly handles the Packet Filter Identifier by decrementing it by 1 before sending it to the UE and adding +1 when searching for the packet filter context.
**Conclusion:**
By making these adjustments, we ensure proper synchronization between the UE and SMF in the 5G Core and maintain compliance with the 3GPP specifications. This fix resolves the mismatches caused by incorrect identifier handling and enforces the correct limit on the number of packet filters, enhancing the reliability and standards compliance of the 5GC implementation without impacting the existing correct behavior in EPC.
SMF selection according to 4.3.2.2.3 of TS23.502.
V-SMF makes discovery in the V-NRF according to V-NSSF.
H-SMF makes discovery in the H-NRF according to H-NSSF.
(The AMF goes through the V-NSSF and forwards the message seeking the NRF to the H-NSSF.)
If the UE continuously attempts to Attach while changing PDN Type,
it will cause the wrong IP to be assigned.
(e.g PDU-Type : IPv4v6 -> IPv4 -> IPv4v6)
This is because we use two variables at the same time,
one to read and store the Static IP from the Subscriber DB and
one to store the IP assigned from SMF, called session->paa.
When the UE attaches with PDN-Type set to IPv4v6,
MME saves the allocated IP in session->paa.
However, MME thinks it has been assigned a static IP based on the information
in session->paa, so changing the PDN-Type may result in the wrong IP
being assigned.
To solve this problem, I separated the variable(session->paa) that stores
the allocated IP received from SMF and the variable(session->ue_ip) that stores
the Static IP read from the Subscriber DB.
Therefore, the information read from the Subscriber DB
(session->session_type and session->ue_ip) should not be modified.
The AMF will crash on the following locations when it receives a sequence
of NAS messages from a UE.
- ogs_nas_encrypt: Assertion `pkbuf->len' failed. (../lib/nas/common/security.c:86)
- gmm_state_authentication: Assertion `r != OGS_ERROR' failed. (../src/amf/gmm-sm.c:1561)
Besides the crashes found above, an incorrect protocol transition
is identified in Open5GS. Without any Registration/Attach Request message,
when the Identity Response message sent, the Core Network responds
with an Authentication Request message. According to the standard,
only the Registration/Attach Request message can start a state transition
from the 5GMM/EMM-DEREGISTERED state to the 5GMM/EMM-COMMON-PROCEDURE-INITIATED.
So I've modified the relevant code to address these issues.
First of all, it crashes when creating a Dedicated Bearer
on the default Session that is created for the first time.
This behavior should be possible, so the related ASSERT is removed.
Next, the InitialContextRequest is modified
during the Attach Request to include the first Bearer.
Finally, there was an issue where trying to create a Dedicated Bearer
with SGsAP enabled resulted in an InitialContextSetupRequest message
with a PTI of zero. This is because MME initializes the PTI to 0
upon receiving the Create Bearer Request while processing SGsAP.
All of these issues has been fixed.
Assume the UE has Attached, the session has been created,
and is in the IDLE state with the UEContextRelease process.
This could result in the following call flow.
1. TAU request without Integrity Protected
2. Authentication request/response
3. Security-mode command/complete
MME can be performed simultaneously by the HSS(S6A) and UE(S1AP).
Update-Location-Request
Service request
Service reject
Delete Session Request
Delete Session Response
Update-Location-Answer
UEContextReleaseCommand for Service reject
TAU reject
UEContextReleaseCommand for TAU reject
UEContextReleaseComplete
UEContextReleaseComplete
MME crashes when UE sends a service request(S1AP) during ULR/ULA(S6A) with HSS,
which has been fixed.
1. HandoverRequired
2. HandoverRequest
3. HandoverFailure
4. UEContextReleaseCommand
5. HandoverPreparationFailure
If UEContextReleaseComplete is not received,
the Source-UE will have the Target-UE.
6. HandoverRequired
There may be cases where the Source UE has a Target UE
from a previous HandoverRequired process. In this case,
it is recommended to force the deletion of the Target UE information
when receiving a new HandoverRequired.
7. HandoverRequest
8. HandoverFailure
9. UEContextReleaseCommand
10. UEContextReleaseComplete
11. HandoverPreparationFailure
... Crashed ...
For bi-directions, the rules are created in the same form as for downlink
as shown below, so to apply them for uplink, we need to swap the rules
according to the interface.
RX : permit out from <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT> to <UE_IP> <UE_PORT>
GX : permit out from <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT> to <UE_IP> <UE_PORT>
PFCP : permit out from <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT> to <UE_IP> <UE_PORT>
RULE : Source <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT> Destination <UE_IP> <UE_PORT>
TFT : Local <UE_IP> <UE_PORT> REMOTE <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT>
RX : permit in from <UE_IP> <UE_PORT> to <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT>
GX : permit out from <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT> to <UE_IP> <UE_PORT>
PFCP : permit out from <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT> to <UE_IP> <UE_PORT>
RULE : Source <UE_IP> <UE_PORT> Destination <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT>
TFT : Local <UE_IP> <UE_PORT> REMOTE <P-CSCF_RTP_IP> <P-CSCF_RTP_PORT>
APER encoding fails when using the asn_uint642INTEGER function on a 32-bit machine as shown below.
```C
asn_uint642INTEGER(AMF_UE_NGAP_ID, 0xffffffff);
...
aper_encode_to_buffer(...)
```
INTEGER APER encode/decode functions seem to be operating internally with long variables instead of intmax_t.
That is probably the reason of the failure.
@v0-e fixed this issues in the mouse07410/asn1c pull request.
https://github.com/mouse07410/asn1c/pull/176https://github.com/mouse07410/asn1c/pull/177
../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.
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.
* [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.
* Add "subscriber_status" cmd to open5gs-dbctl to set values for
"subscriber_status" and "operator_determined_barring" DB fields.
* Add webui View+Edit for those same fields.
* open5gs-hssd now takes those values into account and submits
Operator-Determined-Barring AVP with DB-retrieved value if
subscriber_status is set to OPERATOR_DETERMINED_BARRING.
For more information, see TS 29.272 section 5.2.2.1.3 and 7.3.30.
Scenario is handover on S1AP, data forwarding is enabled, and
the Source ENB is forwarding DL PDCP packets to EPC(SGWU)
with PDCP SN included. SGWU is also forwarding these packets
to the Target ENB.
However the PDCP SN is not present in the forwarded packets
from SGWU to Target ENB.
I modified this part, and there was the same problem in 5GC, fixed it as well.
A lot of code in GTP-U has been modified,
so if you have any problems, please let us know right away.
NAS, GTP, PFCP, SBI, all except S1AP/NGAP use x1000 multiplier for Kbps, Mbps, Gbps ... etc.
From now on in WebUI all units also use a multiplier of x1000.
