5G SCP Retry Control to Prevent Duplicate Charging
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In 5G indirect communication, the Service Communication Proxy (SCP) performs retries and reselections without knowledge of the request nature, leading to risks of duplicate or triplicate charging due to the inability to set the retransmission indicator, causing unnecessary processing load and potential duplicate charging.
Innovation Solution
The NFConsumer provides handling instructions to the SCP through the extended 3gpp-Sbi-Selection-Info header, allowing it to control retries and reselections, restricting them to specific scopes or disabling them entirely, and returning the selected NFProducer's identifier upon failure.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the SCP performs automatic retries and reselections without handling instructions, then the system maintains high availability and fault tolerance, but duplicate charging occurs and unnecessary processing load is generated
Solution Approach 1:
The invention changes the parameter of retry behavior by introducing handling instructions that modify the SCP's default retry policy. When a handling instruction is present, the SCP adjusts its retry parameters (whether to retry, scope of reselection) based on the instruction content, thereby preventing duplicate charging while maintaining reliability for requests without such instructions
Solution Approach 2:
The handling instruction mechanism provides feedback to the SCP about the requester's intent regarding retries. The SCP receives feedback in the form of handling instructions that indicate whether retries should be performed and under what conditions, allowing the SCP to adapt its behavior accordingly and avoid harmful duplicate charging
2Reliability
If the SCP performs unrestricted retries and reselections, then fault tolerance is improved, but computational overhead increases due to unnecessary processing
Solution Approach 1:
The handling instruction changes the parameter of retry execution by providing conditional logic that allows the SCP to skip unnecessary retries. When a handling instruction indicates that retries should not be performed or should be restricted, the SCP reduces its computational overhead by avoiding redundant processing while maintaining fault tolerance for cases where retries are appropriate
3Object-generated harmful factors
If the SCP is made aware of request nature to control retries, then duplicate charging is prevented, but SCP complexity increases
Solution Approach 1:
The handling instruction acts as an intermediary that conveys request nature information from the requester to the SCP without requiring the SCP to directly analyze or understand the request content. The SCP simply follows the instructions provided, maintaining its agnostic nature while still preventing duplicate charging through the intermediary instruction mechanism
Solution Approach 2:
The invention segments the retry control functionality by separating the decision-making logic (handled in the handling instruction) from the execution logic (performed by the SCP). This segmentation allows the SCP to remain simple and agnostic while the handling instruction carries the necessary information about request nature and retry preferences
4Reliability
If the SCP performs retries without handling instructions, then system resilience is maintained, but the requester cannot control retry behavior
Solution Approach 1:
The handling instruction introduces dynamic control over retry behavior, allowing the requester to adapt retry parameters based on specific request characteristics. The SCP's retry behavior becomes dynamic rather than static, adjusting according to the handling instruction provided by the requester while maintaining system resilience for requests without such instructions
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Method comprising: monitoring whether a proxy receives a request and a handling instruction for the request from a requester; forwarding the request from the proxy to a first target; checking whether the proxy receives, in response to the forwarding the request, a success indication from the first target indicating that the request was successfully executed; if the proxy receives the handling instruction and the proxy does not receive the success indication: handling the request according to the handling instruction; wherein the handling instruction instructs whether or not the proxy is admitted to retry to forward the request to the first target.