Previously, malformed Protocol Configuration Options (PCO) data would trigger
ogs_assert failures in both the generic parser and SMF build routines,
causing the SMF process to abort unconditionally.
This commit replaces those fatal assertions with conditional checks:
In ogs_pco_parse(), switch from ogs_assert(size == data_len) to
ogs_expect(size == data_len), allowing the function to return gracefully.
In SMF's PCO build (smf_pco_build) and all downstream build paths
(including GN, GSM, S5C modules), replace ogs_assert(pco_len > 0)
with explicit if (pco_len <= 0) checks that:
Ensure that malformed or incomplete PCOs no longer crash the process,
but instead are handled cleanly so the network function can continue operating.
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.
- 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.
- **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.
Implement Control Message handling between V-SMF and H-SMF
during Home Routed Roaming process
Completed the implementation of control messages exchanged
between V-SMF and H-SMF as part of the Home Routed Roaming process
The osmocom ttcn3-mme-ogs test uses an APN consisting simply of the NULL
byte. This corresponds to one label of length zero, so simply the APN "".
Since commit 333d3fe1 ogs_fqdn_parse() returning zero is considered an
error in ogs_gtp1_parse_pdp_context().
Fix this by returning a negative value on error in ogs_fqdn_parse() and checking for
that.
According to TS29.503, we can choose whether or not to allow LBO roaming
on a per-session basis.
To this end, we have made changes to allow us to set this via the WebUI.
TS24.008
10.5.6.12 Traffic Flow Template
Table 10.5.162: Traffic flow template information element
Number of packet filters (octet 3)
The number of packet filters contains the binary coding
for the number of packet filters in the packet filter list.
The number of packet filters field is encoded in bits 4
through 1 of octet 3 where bit 4 is the most significant
and bit 1 is the least significant bit.
For the "delete existing TFT" operation and
for the "no TFT operation", the number of packet filters shall be
coded as 0. For all other operations, the number of packet filters
shall be greater than 0 and less than or equal to 15.
The array of TLV messages is limited to 16.
So, Flow(PDI.SDF_Filter) in PDR is limited to 16.
Therefore, we defined the maximum number of flows as 16.
TS24.008
10.5.6.12 Traffic Flow Template
Table 10.5.162: Traffic flow template information element
Number of packet filters (octet 3)
The number of packet filters contains the binary coding
for the number of packet filters in the packet filter list.
The number of packet filters field is encoded in bits 4
through 1 of octet 3 where bit 4 is the most significant
and bit 1 is the least significant bit.
For the "delete existing TFT" operation and
for the "no TFT operation", the number of packet filters shall be
coded as 0. For all other operations, the number of packet filters
shall be greater than 0 and less than or equal to 15.
The array of TLV messages is limited to 16.
So, Flow(PDI.SDF_Filter) in PDR is limited to 16.
Therefore, we defined the maximum number of flows as 16.
Fixed to not change the session information stored in the DB
when transferring context from GERAN to EUTRAN.
Note that the Tracking Area Update Procedure differs
from the Attach Procedure in 5.3.2 in the point
at which HSS and ULR/ULA are performed.
3GPP TS 23.401
Ch 5.3.3 Tracking Area Update procedures
<Attach Procedure>
1. Security-mode complete
2. Update Location Request/Answer
3. Create Session Request/Response
<Tracking Area Update Procedure>
1. Security-mode complete
2. Create Session Request/Response
3. Update Location Request/Answer
When TAU creates a Create Session Request message,
there is no session type information in the Subscriber DB
that is received from HSS in the Update Location.
Therefore, TAU does not reflect the Session Type
but creates PDN Type by reflecting the information
in the Request Type as it is.
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.
* [SBI] Handle and store AMF info
* [SBI] Add "target GUAMI" discovery option
* [SBI] Handle UeContextTransfer request and response messages
* [AMF] Handle NF discovery from AMF to AMF
* [AMF] Add UE Context Transfer Request/Response from AMF to AMF
* [SCP] Handle UeContextTransfer
* Follow-up on #3052
* [AMF] force authentication after 'Ue context transfer' for now
* [AMF] force authentication after 'Ue context transfer' for now
---------
Co-authored-by: Sukchan Lee <acetcom@gmail.com>
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>
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.
* 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.
o Generate the private key as below.
$ openssl genpkey -algorithm X25519 -out /etc/open5gs/hnet/curve25519-1.key
$ openssl ecparam -name prime256v1 -genkey -conv_form compressed -out /etc/open5gs/hnet/secp256r1-2.key
o The private and public keys can be viewed with the command.
The public key is used when creating the SIM.
$ openssl pkey -in /etc/open5gs/hnet/curve25519-1.key -text
$ openssl ec -in /etc/open5gs/hnet/secp256r1-2.key -conv_form compressed -text
In ausf/udm.yaml
hnet:
o Home network public key identifier(PKI) value : 1
Protection scheme identifier : ECIES scheme profile A
- id: 1
scheme: 1
key: /etc/open5gs/hnet/curve25519-1.key
o Home network public key identifier(PKI) value : 2
Protection scheme identifier : ECIES scheme profile B
- id: 2
scheme: 2
key: /etc/open5gs/hnet/secp256r1-2.key
o Home network public key identifier(PKI) value : 3
Protection scheme identifier : ECIES scheme profile A
- id: 3
scheme: 1
key: /etc/open5gs/hnet/curve25519-1.key
o Home network public key identifier(PKI) value : 4
Protection scheme identifier : ECIES scheme profile B
- id: 4
scheme: 2
key: /etc/open5gs/hnet/secp256r1-2.key
Related to #1779
