- create SDM subscription to UDM when PDU session is created, just
before sending SMF registration to UDM
- delete SDM subscription when PDU session is released
- handle SDM Change Notification, but not yet process items in it
NF should accept 204 No Content for Update Subscription requests.
According to 3GPP 29.510 NRF specification document in figure 5.2.2.5.6.1
NRF may return 204 or 200 for success update operations.
2a. On success, if the NRF accepts the extension of the lifetime
of the subscription, and it accepts the requested value for the "validityTime"
attribute, a response with status code "204 No Content" shall be returned.
2b. On success, if the NRF accepts the extension of the lifetime
of the subscription, but it assigns a validity time different than
the value suggested by the NF Service Consumer, a "200 OK" response code shall
be returned. The response shall contain the new resource representation
of the "subscription" resource, which includes the new validity time,
as determined by the NRF, after which the subscription becomes invalid.
I changed it so that all NFs can receive both 200 and 204 STATUS.
I also changed the default behavior of NRFs to respond with 204,
which is NO CONTEXT.
- Upgraded libraries to 4.5 to address compile error issues with CXX11 support
- Change the default version of FreeBSD Vagrant to 14.1-STABLE
- FreeBSD Platform documentation also changed to 14.x version
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.
When exiting a diameter interface, the session state data could be NULL.
So we added code to check the session state data
to prevent SIGSEGV occurring.
We're experiencing an issue after changing SearchResult.validityTime
from 3600 seconds to 30 seconds.
When AMF finds a PCF through Discovery, it can be deleted
after 30 seconds by ValidityTime.
We have changed our implementation to not send the PCF-ID in this case.
What we need to do is proactively add a part that will re-discover
the PCF when a situation arises where we really need the PCF-ID.
* [UPF/SGW-U] Optimizing data-path (#3306)
In ogs_pfcp_up_handle_pdr, there is a copy operation performed on recvbuf,
which can reduce the sending performance in the data path. Personally,
We believe that this copy operation can be eliminated.
Of course, if it is canceled, the recvbuf does not need to be released again
at the location where ogs_pfcp_up_handle_pdr is called. After testing,
it has indeed shown an improvement in performance of approximately 15-18%.
/*
sendbuf = ogs_pkbuf_copy(recvbuf);
if (!sendbuf) {
ogs_error("ogs_pkbuf_copy() failed");
return false;
}*/
sendbuf = recvbuf;</div>
* update it
UE attached to 4G cell, terminates 4G connection,
then attempts 5G cell attach with TAC update - fails connection
Setup a UE on a 4G cell. Also have a 5G cell available to the UE.
Next, disable the 4G cell. The 4G connection terminates normally.
The UE scans the network and finds the 5G cell.
At this time the UE sends a registration to the 5G cell.
Open5gs sent back a reject with reason "Semantically incorrect message".
Then the UE did not try to attach again and lost the call forever.
Compare this scenario with a different core that we tested this scenario on.
With a different core (other than open5gs) the core sent back a reject
also but with a reason "UE can't be derived by network".
Then the UE tried attach again and the 5G call was successful.
Although this was successful for the other core it could be suggested
that not rejecting at all is good behavior.
There is a workaround which is that the Samsung UE could be put into
airplane mode and taken out of airplane mode and at that point
the UE is able to attach to the 5G cell. But this is a lot of manual effort
on the user of the UE which could be avoided with a simple open5gs change.
Note: Issue only happens when registration request + tracking area update
occurs on 5G cell attach following LTE cell being disabled.
If only registration occurs without a tracking area update
(such as the first time system is up) then it is ok with no rejection.
To solve this issue, added Additional-GUTI to the ClearText Group.
On 4G only... when UE sent an inactivity UEContextReleaseRequest,
Open5GS sent back UEContextReleaseCommand **with cause=normal-release.
This, in turn, does not allow the Samsung UE to return to the low power state
in our testing of the scenario.
Comparing the behavior of open5gs to other cores that we have tested
the other cores are sending a ** cause=“Radio Network Layer Cause”:
User inactivity ** when the UE sends inactivity. And this is what allows
other cores to transition the UE to the low power state whereas
with open5gs the UE is not entering the low power state.
We've fixed to allow open5gs to come to the same level of compliance
in this area as to the other cores.
Update Bearer Request
Modify Bearer Context Request
Modify Bearer Context Accept
Update Bearer Response
In the process above, we incorrectly used the Timer
that the MME uses to wait for the eNB.
We used xact's holding timer, which continues to hold the transaction
for further exception handling even after sending the Update Bearer Response.
This timer should end exactly when the Update Bearer Response is sent
by the MME to the SGW-C. Therefore, we have added a new peer timer
in xact for this purpose.
We fixed an issue in #3302 where MME does not send Downlink Data Notification
Acknowledge to SGW-C in Error Indication situation.
However, it did not work properly when this occurred in conjunction
with releasing the bearer as shown below.
>>>Seesion-Termination in Diameter
>>>SMF sends E-RABReleaseCommand and
Deactivate EPS bearer request context
1. SGW-U received Error Indication
2. SGW-U sends PFCP Report Request to SGW-C
3. SGW-C sends PFCP Report Response to SGW-U
4. SGW-C sends Downlink Data Notification to MME (MME Connected with eNB)
>>> eNB sends E-RABReleaseCommand
>>> UE sends Deactivate EPS bearer context accept
5. MME sends UEContextReleaseCommand to the eNB
6. eNB sends UEContextReleaseComplete to the MME
7. MME sends S1-Paging to the eNB
8. eNB sends Service-Request to the MME
9. MME sends InitialContextSetupRequest to the eNB
10. eNB sends InitialContextSetupResponse to the MME
No bearer context, so cannot send Downlink Data Notification Acknowledge
So, we've fixed it as below.
>>>Seesion-Termination in Diameter
>>>SMF sends E-RABReleaseCommand and
Deactivate EPS bearer request context
1. SGW-U received Error Indication
2. SGW-U sends PFCP Report Request to SGW-C
3. SGW-C sends PFCP Report Response to SGW-U
4. SGW-C sends Downlink Data Notification to MME (MME Connected with eNB)
>>>>>>>> Since eNB Connected, we send Downlink Data Notification Acknowledge here.
>>> eNB sends E-RABReleaseCommand
>>> UE sends Deactivate EPS bearer context accept
5. MME sends UEContextReleaseCommand to the eNB
6. eNB sends UEContextReleaseComplete to the MME
7. MME sends S1-Paging to the eNB
8. eNB sends Service-Request to the MME
9. MME sends InitialContextSetupRequest to the eNB
10. eNB sends InitialContextSetupResponse to the MME
We've encountered an issue where Downlink Data Notification Acks are not sent
in the following situations.
1. SGW-U received Error Indication
2. SGW-U sends PFCP Report Request to SGW-C
3. SGW-C sends PFCP Report Response to SGW-U
4. SGW-C sends Downlink Data Notification to MME
(MME Connected with eNB)
5. MME sends UEContextReleaseCommand to the eNB
6. eNB sends UEContextReleaseComplete to the MME
7. MME sends S1-Paging to the eNB
8. eNB sends Service-Request to the MME
9. MME sends InitialContextSetupRequest to the eNB
10. eNB sends InitialContextSetupResponse to the MME
Here, MME needs to send Downlink Data Notification Acknowledge.
So, we've fixed it
I created ogs_sbi_xact_find_by_id() with a hash
to replace ogs_sbi_xact_cycle().
Modified to find the xact via xact->id
when making an HTTP request with the SBI client function
and waiting for the HTTP response.
Pool library has the following issues with XXX_cycle,
including mme_enb_cycle()/amf_ue_cycle()
```
INIT POOL(SIZE:5)
Alloc Node1
Alloc Node2
Alloc Node3
Alloc Node4
Alloc Node5
Free Node4
Free Node3
PoolCycle(Node4) is NULL (Freed...OK!)
PoolCycle(Node3) is NULL (Freed...OK!)
Alloc Node6
Alloc Node7
PoolCycle(Node4) is Not NULL (Freed...but NOK!)
PoolCycle(Node3) is Not NULL (Freed...but NOK!)
PoolCycle(Node6) is Not NULL (Allocated...OK!)
PoolCycle(Node7) is Not NULL (Allocated...OK!)
```
If we use ogs_poll_alloc() to create and allocate a node,
the correct behavior of calling ogs_pool_free() on this node
and then later calling ogs_pool_cycle() on this node must always return NULL.
However, the behavior of calling ogs_pool_cycle() on this node
in the future may return a “valid” pointer.
To solve the problem, we added hash id to the pool memory and
ogs_pool_find_by_id() function is added.
3GPP TS 23.003 Ch. 2.8.2.2.2 (Mapping in the UE) states "The P-TMSI
signature is sent intact to the MME."
So simply use the PTMSI signature from the TAU and pass it throught to the
SGSN Context Request.
The algorithms described in 3GPP TS 23.003 Ch. 2.8.2.1.2 an 2.8.2.2.2
are not directly the inverse of each other.
To send a SGSN Context Request (in 2G -> 4G mobility) the algorithm in
2.8.2.2.2 has to be done in reverse (like mentioned in 2.8.2.2.3 -
Mapping in the new MME).
When parsing an SGSN Context Request (for 4G -> 2G mobility) the reverse
of 2.8.2.1.2 (as described in 2.8.2.1.3) has to be used.
PTMSI signature handling is added in a separate commit.
