-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Modify code for indirect communication in free5gc v3.4.4 #51
Conversation
if validTargets, exists := npPairs[sourceNF]; exists { | ||
for _, validTarget := range validTargets { | ||
if validTarget == targetNF { | ||
supportNFPairForIndirectCommunication = true | ||
} | ||
} | ||
|
||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Check the SCP
is enabled before finding whether the NF pair is supported or not.
"UDM": {"UDR", "AUSF"}, | ||
"UDR": {"UDM", "NEF"}, | ||
"SMF": {"AMF"}, | ||
"NEF": {"UDR"}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the CHF be supported?
If yes, please add the TODO comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my understanding, SCP can support the selected NF pairs according to demand, without a strict definition of which NFs must be supported, and can provide additional functions as needed. The most basic function is to forward messages.
We chose to implement these NFs because our detection system will use the SBI messages of these NFs to determine if there are any anomalies.
@@ -290,6 +303,12 @@ func (p *Processor) NFDeregisterProcedure(nfInstanceID string) *models.ProblemDe | |||
|
|||
uriList := nrf_context.GetNofificationUri(nfProfiles[0]) | |||
nfInstanceType := nfProfiles[0].NfType | |||
|
|||
// Record deregister SCP | |||
if nfInstanceType == "SCP" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we consider the case of multi-SCP deployment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't thought about this issue, but theoretically, it is possible to deploy multiple SCPs.
However, will there be multiple NRFs? Because if we follow the current implementation method: without changing other NFs, but using NRF to allocate information to SCPs, I feel that NRF will be a performance bottleneck.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If multiple NRFs deploy, the NF profiles for the other NFs to discover also need to be synchronous.
So, the SCP URL can also be synced at that time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means that if multiple NRFs are to be deployed, does ScpUui need to be set up in the config?
I think I can first add "TODO: currently only supporting a single SCP" situation in this piece of code.
Later, it can be modified to support multiple SCP situations, perhaps by obtaining the Uri from the config or something like that.
If we want to support multiple SCPs, I think implementing indirect communication with delegated discovery would be a better approach. This means that NFs can communicate directly with SCPs without going through NRF. However, this would require modifying some NF the want to support the indirect communication.
I modified the NRF so that it can direct some of the messages to the SCP.