Handling overload control information (OCI) in a telecommunications network

Abstract

There is provided a method for handling overload control information in a telecommunications network performed by a first node. The method comprises generating an OCI header request comprising at least scope information wherein the scope information mentions a second node for which the OCI is required. The 5 method comprises transmitting the OCI header request to the second node. The method also comprises receiving an OCI header response from the second node, wherein the OCI header response comprises current overload information of the second node.

Description

[0001] HANDLING OVERLOAD CONTROL INFORMATION (OCI) IN A TELECOMMUNICATIONS NETWORK

[0002] TECHNICAL FIELD

[0003] Embodiments presented herein relate to methods, a first node, a second node and a computer program product for handling Overload Control Information (OCI) in a telecommunications network.

[0004] BACKGROUND

[0005] Overload control enables an Network Function (NF) Service Producer, an NF Service Consumer, an Service Communication Proxy (SCP) or a Security Edge Protection Proxy (SEPP) becoming or being overloaded to gracefully reduce its incoming signalling load, by instructing NF Service Consumers to reduce sending service requests or by instructing NF Service Producers to reduce sending notification requests respectively, according to its available signalling capacity to successfully process the requests. An NF Service Producer, NF Service Consumer, SCP or a SEPP is in overload when it operates over its signalling capacity.

[0006] In general, overload protection of Network Functions (NF)s in a network is handled by Hypertext Transfer Protocol (HTTP) response codes or by using Overload Control Information (OCI). Overload protection based on the HTTP response code is the reactive approach. This means that the H'ITP client can understand that HTTP server is overloaded after sending the request. Also, H’IT P client is not aware when the HTTP server is back to normal. In this methodology, client should also have an intelligence on how many responses are received with overload (e.g. response code 403) and should calculate the rejection rate. Based on the rejection rate, the client either decides to abate or redirect the request to alternate HTT P server.

[0007] Overload protection based on the Overload Control Information (OCI) headers support the proactive approach.

[0008] Fig la illustrates a general flow diagram showing OCI information sharing currently executed as part of the Prior Art. Here an HTTP Client (10) sends a Service Request (30) to the HTTP Server (20). As a response, the HTTP Client (10) receives a Service Response (40) from the HTTP Server (20) from which it also comes to know about the overload information of the HTTP Server (20). Fig la also shows the Overload information (50) of the HTT P Server (20). Along with other parameters the overload information also includes the NF-instance of the HTTP Server. It is this NF-Instance which enables the HTTP Server to generally send any type of communication to the right HTTP Client. This NF-instance is also registered with a Network Repository Function (NRF) in the network. Clause 6.4.3 in Third Generation Partnership Project (3GPP) Specification 29.500 version 19.0.0 specifies details of the Overload Control based on OCI.

[0009] There is still a need for improved handling of overload control information in a telecommunications network.

[0010] SUMMARY

[0011] There are limitations for this OCI information sharing mechanism as it is done today. There is no guaranteed delivery of OCI information. HTTP Server sent the OCI information in the HTTP response based on the “Frequency of conveyance”. There is a chance that the OCI information sent by HTTP server towards the HTTP client get lost due to various reason like packet lost, network issue etc. This will make the HTTP client to pump the traffic towards the HTTP Server.

[0012] HTTP Server must maintain the details for each and every connected NF-instance on when the next OCI to be sent. This is an additional burden to the HTTP Server to evaluate and maintain such information about the client.

[0013] HTT P Server will send the OCI information only when it receives a request for it. If HTT P Client sends lesser traffic towards Server (Say 1 message in every 10 minutes), it might not be possible for the HTTP Server to keep the client updated on its latest overload information.

[0014] It is necessary for HTT P Server to get the NF-instance information of the HTTP client. But for few services like Nchf (Network Charging Function) Spending Limit control, the interface does not provide the Client NF- instance details. So, there is no straight forward method for the HTT P server to understand the Client NF-instance details. This will confuse the HTT P server where to send the overload information. An object of embodiments herein is to address the above issues and to facilitate handling of overload control information in a telecommunication network.

[0015] According to a first aspect there is presented a method for handling overload control information in a telecommunications network performed by a first node. The method comprises generating an OCI header request comprising at least scope information wherein the scope information mentions a second node for which the OCI is required. The method comprises transmitting the OCI header request to the second node. The method also comprises receiving an OCI header response from the second node, wherein the OCI header response comprises current overload information of the second node.

[0016] According to a second aspect there is presented a method wherein the OCI header request is transmitted as part of a service request or a notification.

[0017] According to a third aspect there is presented a method, wherein the OCI header request is transmitted from the first node to the second node via an intermediate node.

[0018] According to a fourth aspect there is presented a method, wherein the first node is an intermediate node.

[0019] According to a fifth aspect there is presented a method, wherein the intermediate node is one of a Service Communication Proxy (SCP) or a Security Edge Protection Proxy (SEPP).

[0020] According to a sixth aspect there is presented a method, wherein the first node is an H’ITP client.

[0021] According to a seventh aspect there is presented a method, wherein the second node is an HTTP server.

[0022] According to an eighth aspect there is presented a method, for handling overload control information in a telecommunications network, performed by a second node. The method also comprises receiving from a first node an OCI header request comprising at least a scope information wherein the scope information mentions the second node for which the OCI is required. The method further comprises generating an OCI header response comprising current overload information of the second node.

[0023] The method comprises transmitting the OCI header response to the first node.

[0024] According to a ninth aspect there is presented a method, wherein the OCI header response is transmitted from the second node to the first node via an intermediate node.

[0025] According to a tenth aspect there is presented a method, wherein the second node is an intermediate node.

[0026] According to an eleventh aspect there is presented a first node for handling overload control information in a telecommunications network. The first node comprises a processing circuitry and a memory coupled to the processing circuit. The memory stores instructions that, when executed by the processing circuitry, cause the first node to generate an OCI header request comprising at least scope information wherein the scope information mentions a second node for which the OCI is required. The first node is also configured to transmit the OCI header request to the second node. The first node is also configured to receive an OCI header response from the second node, wherein the OCI header response comprises current overload information of the second node.

[0027] According to a twelfth aspect there is presented a computer program product for handling Overload Control Information (OCI) in a first node of a telecommunications network. The computer program product comprises a non-transitory computer- readable medium having computer-executable instructions stored thereon, the instructions, when executed by processing circuitry, causing the processing circuitiy to generate an OCI header request comprising at least scope information wherein the scope information mentions a second node for which the OCI is required. The instructions, when executed by processing circuitry, causing the processing circuitiy to transmit the OCI header request to the second node. The instructions, when executed by processing circuitry, causing the processing circuitry to receive an OCI header response from the second node, wherein the OCI header response comprises current overload information of the second node.

[0028] According to a thirteenth aspect there is presented a second node for handling overload control information in a telecommunications network. The second node comprises a processor circuitry and a memory coupled to the processing circuitry. The second node is configured to receive from a first node an OCI header request comprising at least a scope information wherein the scope information mentions a second node for which the OCI is required. The second node is configured to generate an OCI header response comprising current overload information of the second node. The memory stores instructions that, when executed by the processing circuitry, cause the second node to transmit the OCI header response to the first node.

[0029] According to a fourteenth aspect there is presented a computer program product for handling Overload Control Information (OCI) in a second node of a telecommunications network. The computer program product comprises a non- transitory computer-readable medium having computer-executable instructions stored thereon. The instructions, when executed by processing circuitry, causing the processing circuitry to receive from a first node an OCI header request comprising at least a scope information wherein the scope information mentions a second node for which the OCI is required. The instructions, when executed by processing circuitry, causing the processing circuitry to generate an OCI header response comprising current overload information of the second node. The instructions, when executed by processing circuitry, causing the processing circuitry to transmit the OCI header response to the first node.

[0030] Advantageously, these aspects guarantee delivery of OCI information from the second node (e.g. HTTP server) to the first node (e.g. HTl'P client).

[0031] Advantageously, these aspects enable the first node (e.g. HTl'P client) to be aware of the overload situation of the second node (e.g. HTl'P server) even in low traffic situations.

[0032] Advantageously, these aspects also enable better handling of client information by limited or no caching in the H1TP server. This results in less burden or no burden to the HTl'P server on communicating the overload information compared to existing mechanism.

[0033] Advantageously, these aspects also enable the overload information to be communicated promptly to the requesting HTl'P client. This addresses the exiting SBI interface, even when it does not provide the NFInstance (Client Instance) information in the payload during the communication.

[0034] Advantageously, this solution can be reused for other headers to retrieve the system load dynamically.

[0035] Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, from the attached dependent claims as well as from the drawings.

[0036] Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a / an / the element, apparatus, component, means, module, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, module, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

[0037] BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The inventive concept is now described, byway of example, with reference to the accompanying drawings, in which:

[0039] Fig la illustrates a general flow diagram showing OCI information sharing currently executed as part of the Prior Art;

[0040] Fig lb is a flow diagram illustrating handling overload control information directly between a first and a second node using Service Request and Service Response according to an embodiment;

[0041] Fig 2 is a flow diagram illustrating an example embodiment handling overload control information using Service Request and Service Response;

[0042] Fig 3 is a flow diagram illustrating an example embodiment handling overload control information using Notification Request and Notification Response;

[0043] Fig 4 is a flowchart illustrating method performed at the first node according to an embodiment; Fig 5 is a flowchart illustrating method performed at the second node according to an embodiment;

[0044] Fig 6a is a flow diagram illustrating an example embodiment handling overload control information between a first and a second node via an intermediate node using Service Request and Service Response;

[0045] Fig 6b is a flow diagram illustrating an example embodiment handling overload control information between a first and a second node via an intermediate node using Notification Request and Notification Response;

[0046] Fig 7 is a flow diagram illustrating an example embodiment handling overload control information of an intermediate node;

[0047] Fig 8 is a flow diagram illustrating an example embodiment handling overload control information by an intermediate node;

[0048] Fig 9 is a schematic diagram showing structural units of a first node according to an embodiment;

[0049] Fig io is a schematic diagram showing structural units of a second node according to an embodiment;

[0050] Fig n is a schematic diagram showing structural units of an intermediate node according to an embodiment; and

[0051] Fig. 12 shows one example of a computer program product according to an embodiment.

[0052] DETAILED DESCRIPTION

[0053] The inventive concept will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the inventive concept are shown. This inventive concept may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Like numbers refer to like elements throughout the description. Any step or feature illustrated by dashed lines should be regarded as optional.

[0054] In a service-based interface, the interactions between NF nodes follow a producerconsumer model. NF consumer is an NF that requests or consumes services from another NF and an NF Producer is an NF that offers or provides a service to the consumer. In Service-Based Architecture (SBA), when an NF experiences overload, it must signal this condition to other NFs to manage traffic effectively and prevent failures. As explained earlier, this is done through Overload Control Information (OCI). In a Service-Based Architecture (SBA), the typical flow of Overload Control Information (OCI) involves the NF producer signalling its overload status to the NF consumer to manage incoming requests. However, the reverse scenario where an NF producer seeking the OCI status of an NF consumer could arise as well occasionally.

[0055] While the standard OCI flow involves the NF producer signalling its status to the NF consumer, niche cases could arise where the producer may need to know the consumer’s overload status. These scenarios tend to occur in complex workflows, bidirectional communication, or service chains where a consumer's overload can have cascading effects on the producer's ability to operate efficiently.

[0056] Both the consumer and producer must support the signalling methods for exchanging overload information, directly between them or via one or more intermediary such as a Service Communication Proxy (SCP) or a Security Edge Protection Proxy (SEPP).

[0057] There could occur situations where SCP or SEPP may monitor or may want to know the OCI of NF producers and consumers and, based on this information, decide how to load balance or distribute the traffic across the network. This is important to avoid overwhelming any NF that is experiencing high load. It is also possible for a NR producer or a consumer to know the OCI information of the intermediate node for secure and balanced transfer of information.

[0058] As mentioned above an NF producer, NF consumer or an intermediate node (SCP or SEPP) would want to know the OCI information of another NF node in the communication network. To capture the broad spectrum of use cases and to simplify the understanding, three types of nodes are introduced in our explanations, i.e. a first node, a second node and an intermediate node. Based on some the use cases the intermediate node could either take the role of a first node or a second node when required. Practical example use cases involving specific NF nodes (e.g. SCF, CHF, SCP & SEPP) are also included for better understanding.

[0059] Fig lb is a flow diagram illustrating handling overload control information directly between a first node 105 and a second node 110 according to an embodiment.

[0060] In the embodiment, the first node is the one which would like to have an OCI information of another node and hence it is the node which generates and transmits an OCI header request. The second node is the one which receives the OCI header request and responds to the received OCI header by generating an OCI header response.

[0061] Based on the broad spectrum of use cases as explained above, the said first or second node could be an NF Service Producer, NF Service Consumer, SCP or a SEPP. The NF Service Producer or Consumer could be any NF node (e.g. SMF, CHF) or any type of node capable of handling OCI header requests and response.

[0062] NF Service Producer is typically responsible for indicating its overload status to consumers, and NF Service Consumer must respect these signals and adjust its request rate or pattern based on the producer's overload status.

[0063] Such NF node could be any node in the Service-Based Architecture (SBA) of the Next Generation Mobile Networks (NGMN), particularly including 5G network. For example, the NF nodes could be but are not limited to any of an AMF (Access and Mobility Management Function), SMF (Session Management Function), UPF (User Plane Function), UDF (Unified Data Repositoiy), PCF (Policy Control Function), NSSF (Network Slice Selection Function), NRF (Network Repositoiy Function), CHF (Charging Function), MB-SMF (Multicast / Broadcast Session Management Function), SMSF (Short Message Service Function), Network Exposure Function (NEF) etc. An NF node can request overload information (OCI) of another NF node to understand its current load status and make informed decisions about service requests or traffic distribution. This interaction helps in preventing congestion and ensuring the availability of services. As mentioned above, in the current known solution, OCI information is sent by the HTTP Server at specific intervals, sometimes called frequency of conveyance which might not be the most desired interval. As mentioned earlier it also suffers from other issues including non-guaranteed delivery.

[0064] Hence in the present proposal, a solution is described wherein whenever a client wants to know the overload situation of any other node, it triggers an OCI header request towards the other node. In Fig ib, the method comprises generating 115 an OCI header request comprising at least scope information, wherein the scope information mentions a second node 110 as a target node for which the OCI is required.

[0065] In the context of 3GPP (3rd Generation Partnership Project) standards, particularly concerning the Service-Based Architecture (SBA), scope information in a Service- Based Interface (SBI) service query refers to details that define the context and limitations of a service request.

[0066] After generating 115 an OCI header request, the method further comprises transmitting the OCI header request via a Service Request 120 to the second node 110. In response to receiving OCI header request, the second node 110 generates 125 its current overload information, which is required by the first node 105. The first node 105 receives an OCI header response via a Service Response 130 from the second node 110, wherein the OCI header response 130 comprises current overload information of the second node 110.

[0067] To illustrate a practical example commonly used today in 5G Core (5GC), in the Service-Based Architecture (SBA) of 5G networks, the a Session Management Function (SMF) and a the Charging Function (CHF) communicate through a the Service-Based Interface (SBI) to coordinate session management and charging operations effectively. Today, the Charging Function (CHF) reports the overload information at every specified interval to the SMF or any other clients connected. It is possible that the overload information sent by the CHF is not received by the clients including SMF i.e. no guaranteed delivery. Currently, CHF is also expected to send the overload information to all clients connected. CHF should therefore be aware of all the clients connected and for that CHF should maintain the cache of each client on what information is sent and when to send this information. This is very cumbersome and inefficient. Instead, if a guaranteed delivery can be ensured to a requestor, such as the first node of Fig.ib, when the overload information is requested, the said problem could be resolved.

[0068] Fig 2 is a flow diagram illustrating an example embodiment handling overload control information using Service Request. The flow diagram illustrates an example embodiment handling overload control information directly between Session Management Function (SMF) 205 and CHF 210. Consider that a user wants to establish a data session to access a streaming service on a mobile device. The SMF is responsible for managing the session, while the CHF is responsible for charging based on the user’s subscription and service usage. The SMF (acting as an HTTP client) sends an HTTP request to the CHF (acting as an HTTP server) to request charging information. Throughout the session, the SMF may need to periodically communicate with the CHF to report usage (e.g., data consumed) or to adjust charging parameters if the user’s behaviour changes (e.g., upgrading to a higher bandwidth). In this scenario, the SMF acts as an HTTP client requesting charging information from the CHF, which acts as an H’ITP server. This interaction is crucial for ensuring that the data session is established with appropriate charging rules, enabling efficient service delivery and accurate billing. Considering the same practical example indicated, in Fig 2, SMF 205 can be envisaged as the H’ITP client and CHF 210 as the H’ITP server here.

[0069] The method comprises generating 215 an OCI header request, which is then transmitted as part of the Service Request 220 by SMF 205 to CHF 210. The OCI header comprises at least scope information, wherein the scope information mentions the CHF 210 as a target node for which the OCI is required. As mentioned, the OCI header request is transmitted via a Service Request 220 from SMF 205. In response to the received OCI header request, the CHF 210 generates 225 its current overload information, which is required by the SMF 205. In response to the request, the SMF 205 receives an OCI header response as part of the Service Response 230 from the CHF 210, wherein the OCI header response comprises current overload information of the CHF 210. Fig 3 is a flow diagram illustrating an example embodiment handling overload control information using Notification Request. While a service request is a formal communication initiated by one network function (e.g., the SMF) to another (e.g., the CHF) to obtain specific information or to perform an action related to service management, a notification request is a communication from one network function to another that informs about an event or status change. In the said example, both types of requests play a crucial role in ensuring efficient communication and coordination between the SMF and CHF, enabling accurate billing and effective service management in a 5G network environment. The OCI header request can also be transmitted via a Notification Request. Consider an example scenario, where the CHF proactively informs the SMF about the user's data consumption status through a notification request. This communication helps ensure that the user is aware of their charging limits and allows the SMF to manage the session effectively, promoting a seamless user experience while maintaining compliance with charging policies. An HTTP client, here the CHF could at any time request the OCI information of the HTTP server, here the SMF using a Callback Request or as indicated in Fig3 by a Notification Request. Fig 3 explains this context in the scenario of SMF 305 and CHF 310. The method comprises CHF 310 generating 315 an OCI header request, which is then sent via the Notification Request 320 by CHF 310 to SMF 305. The OCI header comprises at least scope information, wherein the scope information mentions SMF 305 as the target node for which the OCI is required. The method further comprises transmitting the OCI header request via the Notification Request 320 to the SMF 305. In response, the SMF 305 generates 325 current overload information and transmits OCI header response via the Notification Response 330 to CHF 310. Practically, CHF need to be informed about the SMF's operational capacity so that CHF can make informed decisions regarding session management and charging policies, particularly during varying network conditions. The Charging Function (CHF) may send a request to the Session Management Function (SMF) to obtain Overload Control Information (OCI) in several scenarios which might include initial session establishment, periodic monitoring, during high traffic events etc. An SMF overload occurs when SMF quickly reaches its capacity limit. It is unable to handle additional requests effectively due to resource constraints (e.g., CPU, memory, or network bandwidth). Fig 4 is a flowchart of a method according to an embodiment, performed at the first node, such as the first node of Fig ib.

[0070] At Step S402, the first node 105 generates an OCI header request comprising at least scope information wherein the scope information mentions a second node 110 for which the OCI is required. The scope information indicates the target entity whose overload information is required. Scope information could also indicate an intermediate NF / instance which acts as proxy during the SBA Communication between two NFs.

[0071] At step S404, the first node 105 transmits the OCI header request to the second node 110.

[0072] At step S406, the first node 105 receives an OCI header response from the second node 110, wherein the OCI header response comprises current overload information of the second node 110. Understanding of the overload information prompts both Nodes to adjust their behavior to maintain network stability and service continuity. This also enables overload management in maintaining efficient communication within the network.

[0073] It is possible for the first node to send single OCI header request targeting multiple second nodes in order to know the OCI information of the respective second nodes. One possible way of implementing this is indicating these multiple nodes for which OCI is required in the scope information.

[0074] Similarly, Fig 5 is a flowchart of a method according to an embodiment performed at the second node, such as the second node 110 of Fig ib.

[0075] At step S502, the second node 110 receives from a first node 105 an OCI header request (via a Service Request 120) comprising at least a scope information wherein the scope information mentions a second node 110 for which the OCI is required.

[0076] At step S504, the second node 110 generates 125 an OCI header response comprising current overload information of the second node 110.

[0077] At step S506, the second node 110 transmits the OCI header response via a Service Response 130 to the first node 105. In the communication between the SMF and CHF as explained above, the presence of intermediate nodes like the SCP and SEPP enhances the overall reliability, security, and efficiency of the service requests and OCI information exchange. For example, when the SMF sends a service request to the CHF, the SCP routes the request to the appropriate CHF instance based on current load and availability. Hence it might be important for an intermediate node to be aware of the load information of the NFs involved in the service request. There could even be multiple intermediate nodes in the communication path. The SEPP plays a critical role when NF-to-NF communication occurs across different Public Land Mobile Networks (PLMNs), i.e., between operators, especially in roaming scenarios. When SMF and CHF belong to different networks (e.g., home and visited networks), the SEPP ensures secure and controlled communication. When a session management function like the SMF communicates with a charging function like the CHF, especially in a roaming or multi-network scenario, both SCP and SEPP work together as intermediate nodes for load balancing and to ensure guaranteed secure communication.

[0078] Fig 6a is a flow diagram illustrating an example embodiment handling overload control information between a first node, SMF and a second node, CHF via an intermediate node, SCP using a Service Request. In this context, SMF wants to know the overload information of CHF. Considering SMF as an H'ITP client and CHF as an HTTP server in this scenario; the method comprises the following steps.

[0079] The SMF first generates 603 and transmits the OCI header request along with the Service Request 615 to SCP 608, wherein the scope information in the OCI header request mentions CHF 610 as the target node for which the OCI is required. SCP 608 on receiving the OCI header request forwards the Service Request 620 to the CHF 610. In response to the received OCI header request, the CHF 610 generates 606 its current overload information, which is required by the SMF 605. CHF 610 sent OCI header response back via a Service Response 625 with the generated 606 overload information of the CHF in the existing header to SCP 608. SCP further forwards the Service Response 630 to SMF 605. Since the intermediate node SCP interprets the message transferred via it, it is very much possible for the intermediate node to understand the context of the messages and understand the overload information of the target, which in this case is the overload information of CHF 610. The intermediate node in this context could also be a Security Edge Protection Proxy (SEPP).

[0080] In the context of 3GPP standards, particularly in the Service-Based Architecture (SBA), NF Consumer and NF Producer are key concepts that define the roles of network functions (NFs) in service interactions. An NF Consumer is a network function that requests services or resources from another network function. Essentially, it "consumes" the services provided by an NF Producer. An NF Producer is a network function that offers services or resources to other network functions. It "produces" services that can be consumed by NF Consumers.

[0081] Fig 6b is a flow diagram illustrating an example embodiment handling overload control information between an NF producer, CHF and an NF consumer, SMF via an intermediate node, SCP using notification. Though Fig 6a explained a service context between CHF and SMF using a Service Request and Response, Fig 6b explains another service context using Notification Request and Response. As also mentioned earlier one of the typical example scenarios is where the CHF proactively informs the SMF about the user's data consumption status through a notification request. Another example could be where SMF as an NF Consumer would have subscribed to the CHF as an NF Producer to receive notifications about charging status of a particular user. This scenario demonstrates how the CHF acts as an NF producer by sending notifications, and the SMF acts as an NF consumer by subscribing to and processing these notifications. Here, the communication needs to pass through at least one intermediate node, SCP as shown.

[0082] Here NF producer, CHF 670 like to have the overload information of the NF consumer, SMF 650. For this CHF generates 653 an OCI header request first. To get the overload information of SMF 650, the CHF 670 request the overload information in Notification or Callback Request 675 using the generated OCI header request(e.g.3gpp-Sbi-0ci-Request) with scope information mentioning SMF 650 as the target node for which the OCI is requested. Since an intermediate node SCP 660 is involved, the SCP forwards Notification Request 680 and OCI header to NF consumer SMF 650. In response, the SMF 650 transmits OCI header response via the Notification Response 685 to SCP 660 which further forwards the Notification Response 690 to the NF producer, CHF 670. This OCI header response comprises current overload information of SMF 650.

[0083] Fig 7 is a flow diagram illustrating an example embodiment handling overload control information of an intermediate node.

[0084] Consider a scenario where a mobile network is experiencing congestion due to a major event, such as a large public gathering. As a result, the SMF needs to handle a high volume of requests, and it is crucial for the SMF to know the load conditions of the SCP to ensure effective request handling. As users begin to connect to data services, multiple SMFs receive session establishment requests. The SMFs must communicate with the SCP to route these requests to the appropriate network functions (e.g., CHF). The SCP is receiving a high volume of requests due to the surge in user activity. The SMF, aware of this traffic increase, needs to assess whether the SCP can handle additional requests and hence decides to query the SCP for its OCI. This information helps the SMF understand the current load conditions of the SCP and make informed decisions about whether to proceed with the request or manage it differently.

[0085] Here, SMF 705 wants to retrieve the overload information of the intermediate node SCP 708. For this SMF 705 generates 703 an OCI header request first. Through a Service Request 715 intended for another node, in this case for CHF 710, the SMF 705 transmits the generated 703 OCI header request to the intermediate node SCP 708. The scope information in the OCI header request mentions SCP 708 as the target node for which the OCI is required. On receiving this, SCP 708 generates 706 its current overload information.

[0086] SCP further forwards the Service Request 720 to the intended CHF and get a Service Response 725. As part of the Service Response 730, the SCP 708 respond back with its generated 706 overload information in the existing header to SMF 705 via a OCI header response.

[0087] In practice there could exist multiple intermediate nodes and it is very much possible to retrieve the overload information of any of the intermediate node by appropriately configuring the scope information in the OCI header request. That is achieved by setting the appropriate intermediate SCP node as the target node in the scope information. The intermediate node in this context could also be a Security Edge Protection Proxy (SEPP).

[0088] Fig 8 is a flow diagram illustrating an example embodiment handling overload control information of a target node by an intermediate node.

[0089] Consider a scenario where a mobile network operator experiences a sudden surge in data usage due to a popular event, such as a live concert. Many users are streaming video and using data-heavy applications, which leads to a significant increase in service requests to the CHF for charging information. The SMF attempts to send a service request to the CHF to retrieve charging rules for a new data session. Given the high demand, there’s a risk that the CHF could become overloaded. Before routing the service request from the SMF to the CHF, an intermediate node the SCP checks the current load and performance metrics of the CHF, including its OCI. This allows the SCP to make informed decisions about how to route the request. The SCP may send a request to the CHF to retrieve its OCI to assess its current load status. This step is crucial to determine whether the CHF can handle additional requests without degrading service quality. As shown on Fig 8, the intermediate node SCP 8o8 wants to retrieve the overload information of the CHF, 810. Through a Service Request 820, which is an outcome of the initial Service Request 815 received from another node, in this case for SMF 805, the SCP 808 transmits a generated 803 OCI header request to the CHF 810. The scope information in the OCI header request mentions CHF 810 as the target node for which the OCI is required. On receiving this, CHF 810 generates 806 a current overload information. The CHF also generates OCI header response and respond via a Service Response 825 back with the generated 806 overload information of the CHF in the existing header to SCP 808. SCP further forwards the Service Response 830 to the SMF as a response to the initial service Request 815.

[0090] Fig. 9 schematically illustrates, in terms of a number of structural units, the components of a first node 900 according to an embodiment. The first node 900 may take the role of either an NF consumer, NF producer or an H’ITP client. Processing circuitry 910 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1210a (as in Fig. 12), e.g. in the form of a storage medium or memory 930.

[0091] The processing circuitry 910 may further be provided as at least one ASIC, or FPGA.

[0092] Particularly, the processing circuitry 910 is configured to cause the first node 900 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 930 may store the set of operations, and the processing circuitry 910 maybe configured to retrieve the set of operations from the storage medium 930 to cause the first node 900 to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus, the processing circuitry 910 is thereby arranged to execute methods as herein disclosed.

[0093] The storage medium or memory 930 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

[0094] The first node 900 may further comprise a communications (Comm) interface 920 for communications with other entities, functions, nodes, and devices, as in Figs. 1, 2 and 3. As such the communications interface 920 may comprise one or more transmitters and receivers, comprising analogue and digital components.

[0095] The processing circuitry 910 controls the general operation of the first node 900 e.g. by sending data and control signals to the communications interface 920 and the storage medium 930, by receiving data and reports from the communications interface 920, and by retrieving data and instructions from the storage medium 930. The processing circuitry also comprises of a generator 915, which could also generate an OCI header request or response. The generator 915 is also capable of generating overload information. Other components, as well as the related functionality, of the first node 900 are omitted in order not to obscure the concepts presented herein.

[0096] Fig. 10 schematically illustrates, in terms of a number of structural units, the components of a second node 1000 according to an embodiment. The second node 1000 may take the role of either an NF consumer, NF producer or an HTTP server. Processing circuitry 1010 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1210b (as in Fig. 12), e.g. in the form of a storage medium or memory 1030. The processing circuitry 1010 may further be provided as at least one ASIC, or FPGA.

[0097] Particularly, the processing circuitry 1010 is configured to cause the second node 1000 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 1030 may store the set of operations, and the processing circuitry 1010 may be configured to retrieve the set of operations from the storage medium 1030 to cause the second node 1000 to perform the set of operations. The set of operations maybe provided as a set of executable instructions. Thus, the processing circuitry 1010 is thereby arranged to execute methods as herein disclosed.

[0098] The storage medium or memory 1030 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

[0099] The second node 1000 may further comprise a communications (Comm) interface 1020 for communications with other entities, functions, nodes, and devices, as in Figs. 1, 2 and 3. As such the communications interface 1020 may comprise one or more transmitters and receivers, comprising analogue and digital components.

[0100] The processing circuitry 1010 controls the general operation of the second node 1000 e.g. by sending data and control signals to the communications interface 1020 and the storage medium 1030, by receiving data and reports from the communications interface 1020, and by retrieving data and instructions from the storage medium 1030. The processing circuitry also comprises of a generator 1015, which can also generate an OCI header request or response. The generator 1015 is also capable of generating overload information. Other components, as well as the related functionality, of the second node 1000 are omitted in order not to obscure the concepts presented herein.

[0101] Fig. 11 schematically illustrates, in terms of a number of structural units, the components of an intermediate node 1100 according to an embodiment. There could be multiple intermediate nodes between a NF consumer and a NF producer. Processing circuitry 1110 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1210c (as in Fig. 12), e.g. in the form of a storage medium or memory 1130. The processing circuitry 1110 may further be provided as at least one ASIC, or FPGA.

[0102] Particularly, the processing circuitry 1110 is configured to cause the intermediate node 1100 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 1130 may store the set of operations, and the processing circuitry 1110 may be configured to retrieve the set of operations from the storage medium 1130 to cause the intermediate node 1100 to perform the set of operations. The set of operations maybe provided as a set of executable instructions. Thus, the processing circuitiy 1110 is thereby arranged to execute methods as herein disclosed.

[0103] The storage medium or memory 1130 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

[0104] The intermediate node 1100 may further comprise a communications (Comm) interface 1120 for communications with other entities, functions, nodes, and devices, as in Figs. 6a, 6b, 7 and 8. As such the communications interface 1120 may comprise one or more transmitters and receivers, comprising analogue and digital components.

[0105] The processing circuitry 1110 controls the general operation of the intermediate node 1100 e.g. by sending data and control signals to the communications interface 1120 and the storage medium 1130, by receiving data and reports from the communications interface 1120, and by retrieving data and instructions from the storage medium 1130. The processing circuitry also comprises of a generator 1115, which can also generate an OCI header request or response. The generator 1115 is also capable of generating overload information. In an implementation where the intermediate node just only acts as a node transferring the service or notification messages between the NF consumer and producer as shown in Fig 6a and 6b, the said generator 1115 in the intermediate node might be optional. Other components, as well as the related functionality, of the intermediate node 1100 are omitted in order not to obscure the concepts presented herein. Fig. 12 shows one example of a computer program product 1210a, 1210b, 1210c comprising computer readable means 1230. On this computer readable means 1230, a computer program 1320a can be stored, which computer program 1220a can cause the processing circuitry 910 of the first node 900 and thereto operatively coupled entities and devices, such as the communications interface 920, the storage medium 930 and generator 915 to execute methods according to embodiments described herein. The computer program 1220a and / or computer program product 1210a may thus provide means for performing any steps of the first node 900 as herein disclosed. On this computer readable means 1230, a computer program 1220b can be stored, which computer program 1220b can cause the processing circuitry 1010 of a second node 1000 and thereto operatively coupled entities and devices, such as the communications interface 1020, the storage medium 1030 and generator 1015, to execute methods according to embodiments described herein. The computer program 1220b and / or computer program product 1210b may thus provide means for performing any steps of the second node 1000 as herein disclosed. On this computer readable means 1230, a computer program 1220c can be stored, which computer program 1220c can cause the processing circuitry 1110 of the intermediate node 1100 and thereto operatively coupled entities and devices, such as the communications interface 1120, the storage medium 430 and generator 1115, to execute methods according to embodiments described herein. The computer program 1220c and / or computer program product 1210c may thus provide means for performing any steps of the intermediate node 1100 as herein disclosed.

[0106] In the example of Fig. 12, the computer program product 1210a, 1210b, 1210c is illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. The computer program product 1210a, 1210b, 1210c could also be embodied as a memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory or a Flash memory, such as a compact Flash memory. Thus, while the computer program 1220a, 1220b, 1220c is here schematically shown as a track on the depicted optical disk, the computer program 1220a, 1220b, 1220c can be stored in any way which is suitable for the computer program product 1210a, 1210b, 1210c.

[0107] The inventive concept has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the inventive concept, as defined by the appended patent claims.

Claims

CLAIMS1. A method for handling Overload Control Information (OCI) in a telecommunications network, the method performed by a first node (105,605,900) and the method comprising: generating (S402) an OCI header request comprising at least scope information wherein the scope information mentions a second node (110) for which the OCI is required; transmitting (S404) the OCI header request to the second node (110); and receiving (S406) an OCI header response from the second node, wherein the OCI header response comprises current overload information of the second node (110).

2. The method of claim 1, wherein the OCI header request is transmitted as part of a service request (120) or a notification (320).

3. The method of any of claims 1-2, wherein the OCI header request is transmitted from the first node (105,605,900) to the second node (110,610,1000) via an intermediate node (608,1100).4.The method of any of claims 1-3, wherein the first node (105,605,900) is an intermediate node (608,1100).

5. The method of claims 4, wherein the intermediate node (608,1100) is one of a Service Communication Proxy (SCP) or a Security Edge Protection Proxy (SEPP).

6. The method according to any of the preceding claims, wherein the first node (105,605,900) is an http client.

7. The method according to any of the preceding claims, wherein the second node (110,610,1000) is an http server.

8. A method for handling Overload Control Information (OCI) in a telecommunications network, the method performed by a second node (110,610,1000) and the method comprising:receiving (S502) from a first node (105) an OCI header request comprising at least a scope information wherein the scope information mentions the second node (110) for which the OCI is required; generating (S504) an OCI header response comprising current overload information of the second node (110); and transmitting (S506) the OCI header response to the first node (105).

9. The method according to claim 8, wherein the OCI header response is transmitted from the second node (110,610,1000) to the first node (105,605,900) via an intermediate node (608,1100).10.The method according to any of the claims 8-9, wherein the second node (110,610,1000) is an intermediate node (608,1100).11.A first node (105,605,900) for handling Overload Control Information (OCI) in a telecommunications network, the first node (105,605,900) comprising: processing circuitry (910), a memory (930) coupled to the processing circuitry (910), the memoiy (930) storing instructions that, when executed by the processing circuitry (910), cause the first node (105,605,900) to: generate an OCI header request comprising at least scope information wherein the scope information mentions a second node (110,610,1000) for which the OCI is required; transmit the OCI header request to the second node (110,610,1000); and receive an OCI header response from the second node (110,610,1000), wherein the OCI header response comprises current overload information of the second node (110,610,1000).

12. The first node (105,605,900) according to claim 11, wherein the first node(105,605,900) is configured to transmit the OCI header request from the first node(105,605,900) to the second node (110,610,1000) via an intermediate node (608,1100).

13. The first node (105,605,900) according to any of the claims 11-12, wherein the first node (105,605,900) is an intermediate node (608,1100).

14. The first node (105,605,900) according to claims 13, wherein the intermediate node (608,1100) is one of a Service Communication Proxy (SCP) or a Security Edge Protection Proxy (SEPP).

15. The first node (105,605,900) according to any of the claims 11-14, wherein the first node (105,605,900) is configured to transmit the OCI header request as part of a service request (120) or a notification (320).

16. The first node (105,605,900) according to any of the claims 11-15, wherein the first node (105,605,900) is an http client.17.A computer program product (1210a) for handling Overload Control Information (OCI) in a first node (105,605,900) of a telecommunications network, the computer program product comprising: a non-transitoiy computer-readable medium having computer-executable instructions stored thereon, the instructions, when executed by processing circuitry, causing the processing circuitry to: generate an OCI header request comprising at least scope information wherein the scope information mentions a second node (110,610,1000) for which the OCI is required; transmit the OCI header request to the second node (110,610,1000); and receive an OCI header response from the second node (110,610,1000), wherein the OCI header response comprises current overload information of the second node (110,610,1000).18.A second node (110,610,1000) for handling Overload Control Information (OCI) in a telecommunications network, the second node (110,610,1000) comprising:processor circuitry (1010), a memory (1030) coupled to the processing circuitry (1010), the memory (1030) storing instructions that, when executed by the processing circuitry (1010), cause the second node (1000) to: receive from a first node (105,900) an OCI header request comprising at least a scope information wherein the scope information mentions a second node(110,610,1000) for which the OCI is required; generate an OCI header response comprising current overload information of the second node (110,610,1000); and transmit the OCI header response to the first node (105,900).

19. The second node according to claim 18, wherein the second node (110,610,1000)) is configured to transmit the OCI header response from the second node(110,610,1000) to the first node (105,605,900) via an intermediate node (608,1100).

20. The second node according to any of the claims 18-19, wherein the second node(110,610,1000) is an intermediate node (608,1100).

21. The second node according to any of the claims 18-20, wherein the second node(110,610,1000) is an http server.22.A computer program product (1210b) for handling Overload Control Information (OCI) in a second node (110,610,1000) of a telecommunications network, the computer program product comprising: a non-transitory computer-readable medium having computer-executable instructions stored thereon, the instructions, when executed by processing circuitry, causing the processing circuitry (1010) to: receive from a first node (105,605,900) an OCI header request comprising at least a scope information wherein the scope information mentions a second node (110,610,1000) for which the OCI is required;generate an OCI header response comprising current overload information of the second node (110,610,1000); and transmit the OCI header response to the first node (105,605,900).

Images