OCS, SDN DEVICE, AND OCS

TECHNICAL FIELD

The present invention relates to the communication field and, in particular, relates to a communication method for use between a software-defined networking (SDN) device and an online charging system (OCS), an SDN device, and an OCS.

BACKGROUND

Smart Data Charging (SDC) plays an increasingly vital role in the future of mobile, broadband internet, and data content. It provides dynamic context-dependent mechanism used by a service or content provider to set the price charged to an end user in exchange for handling a content (data) request. The context from which the price is computed may incorporate variety of aspects, such as: the request time, user location, application originating the request, the current data usage pattern on the network, the overall level of network congestion, the type of data being requested, or any other potentially relevant aspect of the content request.

Currently, there is no interface between SDN and OCS (i.e. Online Charging System) to support the smart data charging policy. That is, providing context-dependent traffic plan for different SDN service/path, reporting the traffic change for the SDN service/path base on the reporting criteria from SDN network when dynamic context is changed, providing comments associated with the SDN routing from the view of charging. To support it, a new charging interface and related handling on both SND network and OCS is required.

SUMMARY

To provide an innovative solution to extend the current SDN charging architecture to policy that supports dynamically control SDN routing, the present invention proposes a communication method between an SDN device and an OCS, an SDN device, and an OCS.

According to a first aspect of the present invention, there is provided communication method for use between a SDN device and an OCS, comprising the following steps performed by the SDN device:

sending a SDN Service Traffic Request (SSTR) including a list of network elements from which the traffic to be requested by a user comes to the OCS;

receiving a SDN Service Traffic Answer (SSTA) including tariff information associated with the network elements from the OCS; and

selecting an appropriate network element according to the SSTA to determine a routing path for providing data flow to a user device.

According to another aspect of the present invention, there is provided a communication method for use between a SDN device and an OCS, comprising the following steps performed by the OCS:

receiving an SDN Service Traffic Request (SSTR) including a list of network elements from which the traffic to be requested by a user comes from the SDN device;

sending an SSTA to the SDN device such that the SDN device selects an appropriate network element according to the SSTA to determine a routing path for providing data flow to a user device according to the SSTA, wherein the SSTA including tariff information associated with the network elements.

According to a further aspect of the present invention, there is provided a SDN device for communicating with an OCS, comprising:

a transmitting means, configured to send an SDN Service Traffic Request (SSTR) including a list of network elements from which the traffic to be requested by a user comes to the OCS; a receiving means, configured to receive a Software Defined Network (SDN) Service Traffic Answer (SSTA) including tariff information associated with the network elements from the OCS; and

a processing means, configured to select an appropriate network element according to the SSTA to determine a routing path for providing data flow to a user device.

According to yet another aspect of the present invention, there is provided an OCS for communicating with a SDN device, comprising:

a receiving means, configured to receive an SDN Service Traffic Request (SSTR) including a list of network elements from which the traffic to be requested by a user comes from the SDN device;

a transmitting means, configured to send an SSTA to the SDN device such that the SDN device selects an appropriate network element according to the SSTA to determine a routing path for providing data flow to a user device according to the SSTA, wherein the SSTA including tariff information associated with the network elements.

The communication method for use between the SDN device and the OCS, the SDN device and the OCS provided by the present invention enable the operators to provide dynamic routing path selection in SDN network base on context-dependent traffic. It meets the demand of using less expensive routing for end user, and benefit service provider with non-flat traffic of routing path selection and get more revenues.

BRIEF DESCRIPTION OF THE DRAWINGS

The foresaid and other features and advantages of the present are best understood by reference to the following detailed description of the embodiments when read in conjunction with the accompanying drawings, in which:

Fig. l is an architecture overview illustrating the application of a new charging policy interface for use in SDN network provided by the present invention; Fig.2 is a flowchart illustrating an embodiment of a communication method for use between an SDN device and an OCS provided by the present invention;

Fig.3 illustrates the flow of SDN routing with the new charging interface;

Fig.4 illustrates a use case of the flow of SDN routing with the new charging interface;

Fig.5 is a flowchart illustrating another embodiment of a communication method for use between an SDN device and an OCS provided by the present invention;

Fig.6 is a block diagram illustrating an embodiment of an SDN device for communicating with the OCS provided by the present invention; and

Fig.7 is a block diagram illustrating an embodiment of an OCS for communicating with the SDN device provided by the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The embodiments of the present invention are described in detail with reference to the accompanying drawings. Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present invention should be or are in any single embodiment of the invention. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Furthermore, the described features, advantages, and characteristics of the invention may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize that the invention may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the invention.

This patent invention proposes a new charging policy interface for SDN network and traffic controlled SDN routing accordingly. The new interface provides the following functionalities:

- providing traffic for SDN service/path base on the request from SDN controller;

- reporting the traffic change for the requested SDN service/path base on the reporting criteria from SDN network when dynamic context is changed;

- providing comments associated with SDN service network element/path selection from the view of charging.

SDN controller is enhanced to support the new charging policy interface, which provides the following functionalities:

- requesting traffic plan for the SDN service/path which is available for the data flow, the traffic plan may include, for example, the tariff of the related network elements/path, user's balance, traffic used etc;

- if the traffic plan is context-dependent, i.e., dynamic, determine the reporting criteria and subscribe it;

- determining SDN routing path selection with the consideration of traffic info and, if the traffic change report is received from OCS for some context change (e.g. Low-Balance, network status change, traffic delivered is greater than the number of threshold, etc), re-select appropriate routing path.

OCS is also enhanced to support the new charging policy interface, which provides the following functionalities:

- upon reception of the request from SDN controller, providing traffic for SDN service/path, an indicator is included in the response to indicate which traffic is context-dependent;

- providing comments associated with SDN service network element/path selection from the view of charging;

- reporting the traffic change for the requested SDN service/path base on the reporting criteria from SDN network when dynamic context is changed.

Figure 1 shows the architecture overview of this solution. Note that Ro/Rf is the charging interface between the OCS/OFCS (offline charging system). According to an embodiment, a new Diameter based interface Sx is introduced between SDN controller and OCS/OFCS. Both SDN controller and OCS are enhanced to support the new charging policy interface. Base on the traffic report/routing opinion from OCS, traffic controlled SDN routing will apply with the consideration of it.

Based on the above mentioned concept, the present invention proposes a communication method for use between an SDN device and an OCS. As shown in Fig.2, the method comprises the following steps performed by the SDN device: at step 101, sending an SDN Service Traffic Request (SSTR) including a list of network elements from which the traffic to be requested by a user comes to the OCS; at step 102, receiving an SSTA including tariff information associated with the network elements from the OCS, such as charging rate of each network element in each network context (e.g., non-congestion, general congestion, serious congestion); and at step 103, selecting an appropriate network element according to the SSTA to determine a routing path for providing data flow to a user device. Accordingly, an interface is formed between the SDN device and the OCS, through which the SDN device may obtain the related charging information in order to determine the optimal SDN routing from the view of charging.

In step 101 , the SSTR may be sent from the SDN controller to the OCS in order to request the traffic of SDN service.

In determining the SDN routing path (e.g. Flow Table Entries) for a specific data flow, SDN controller will identify all the available SDN service network element for this flow and include them in the message SSTR to OCS.

The SSTR may include the following information elements (IE):

- User Identity, this IE contains the identity of the user; and

- SDN Service network element List, this IE indicates the list of SDN Service network element that SDN controller wants to request the traffic from OCS.

In step 102, the SSTA is sent from OCS to SDN controller to answer the traffic request for SDN service.

The SSTA may include the following IE:

- Traffic of SDN Service network element. This information element contains a current tariff of each SDN Service network element accordingly and the validation period of this traffic. An indicator is included for each traffic to indicate charging rate of which network element is context-dependent. Optionally, OCS can also mark comments associated with the SDN service network element/path selection from the view of charging. For example, a preference value field can be added for each SDN Service network element, if there are 2 SDN Service network element can provide the same network function (e.g. Video Optimizer), the preference value can be considered in the SDN Service network element selection.

According to an embodiment, the method may further comprise: at step 104, sending a Traffic-Change-Notify-Request (TCNR) including reporting criteria; at step 105, receiving a Traffic-Change-Report (TCR) if the context change of the traffic meets the reporting criteria; and at step 106, updating the routing path according to the TCR.

In step 104, the TCRN may be sent from the SDN controller to the OCS in order to request the traffic change report of SDN service.

The SDN controller may send the TCNR to OCS for the change report of context-dependent traffic. The TCNR may include the following IE:

- TCR criteria. The TCNR is configured with the traffic related event that should be reported to SDN from OCS. For example, Low-Balance for a subscriber, charging rate is increased or increased than a given threshold, etc. Traffic report may trigger the SDN controller to re-select appropriate flow routing path base on the new traffic.

In step 105, the TCR may be sent from the OCS to SDN controller to report the traffic change event of requested SDN service. The SDN controller may subscribe the traffic change of a list of available SDN service network elements (including the SDN service network element in using and the alternative ones) for a specific data flow.

Upon reception of the traffic change from OCS, SDN controller may re-select appropriate routing path base on it. According to an embodiment, the TCR is received when the tariff of the network element is higher than a predetermined threshold in the reporting criteria.

According to an embodiment, the SSTR may further comprise a user identity.

According to an embodiment, the tariff information includes a current tariff and the validation period thereof, and the SSTA further includes comments associated with the network element/path selection, such as the preferred network element. It is thus possible to mark comments associated with the SDN service network element/path selection from the view of charging, enabling the operators to provide dynamic routing path selection in SDN network base on context-dependent charging rate.

According to an embodiment, the method may further comprise determining whether the traffic is context-dependent before sending the TCNR, wherein the TCNR is sent if the traffic is context-dependent.

According to an embodiment, the SSTA may further include an indicator which indicates the network elements whose traffic is context-dependent.

According to an embodiment, the method may further comprise identifying the network element from which the traffic to be requested by the user comes before sending the SSTR to the OCS.

Fig.3 illustrates the flow of SDN routing with the new charging interface. In determining the SDN routing path (e.g. Flow Table Entries) for a specific data flow, SDN controller will identify all the available SDN service network elements for this flow. The OCS will query the traffic of each requested SDN service network element and send it back by SSTA. An indicator is included for each traffic to indicate which traffic is context-dependent. Optionally, it can also mark comments associated with the SDN service network element/path selection from the view of charging.

The SDN controller may subscribe the traffic change of a list of available SDN service network elements (including the SDN service network element is selected and the alternative ones available for future using) for the data flow.

Base on the input from OCS, local provision, business applications or others network elements, SDN controller determine SDN flow routing path selection with the consideration of flow path traffic. For example, choose the less expensive routing path.

OCS reports the traffic change for the requested SDN service network element base on the reporting criteria from SDN network when dynamic context is changed.

Base on the charging event report and other input, SDN controller may update related SDN routing path, re-select appropriate flow routing path. And then, apply the flow path changing to related service network element through enhanced open flow.

A use case of the SDN Routing with the new charging interface is described below by way of example.

Fig.4 illustrates a use case of the flow of SDN routing with the new charging interface. In this example, Service network element #1 and Service network element #2 can provide the same network function (e.g. Video Optimizer). However, they have different traffic for data flow 1.

Traffic for network element #1

Criterion of network conditions Charging rate

Service network element $1.50 per Gb

Congestion Level 1

Service network element $3.00 per Gb

Congestion Level 2

No Congestion $0.50 per Gb Traffic for network element #2

SDN controller identified all the available SDN service network elements for this flow and includes them in the message SSTR to OCS for the traffic. In this example, both Service network element #1 and Service network element #2 are available, SDN controller request the traffic for both of them. Base on the traffic received, SDN controller chooses Service network element #1 for data flow 1 since it requires using less expensive routing and Service network element #1 can provide lowest charging rate (i.e. $0.50 per Gb) currently. Since the traffic of Service network element #1 is context-dependent, SDN controller request the traffic change notify of Service network element #1 during the valid period of this SDN routing path. To make sure the less expensive routing is applied for data flow 1 , the criteria of TCNR determined by SDN controller is: charging rate >=$1.25 per Gb. (that is, report the traffic if its charging rate is higher than alternative SDN service enabler). Then, if the charging rate of the traffic of Service network element #1 is beyond $1.25 per Gb, OCS should report it to SDN controller. When Service network element #1 congestion happens (i.e. Service network element Congestion Level 1), the new charging rate $1.50 per Gb is applied. According to event report configuration on OCS, OCS reports it to SDN controller.

SDN controller routes the call to Service network element #2 since it's the less expensive data service (i.e. $1.25 per Gb) now.

The present invention further provides a communication method for use between an SDN device and an OCS, comprising the following steps performed by the OCS: at step 201, receiving an SDN Service Traffic Request (SSTR) including a list of network elements from which the traffic to be requested by a user comes from the SDN device; at step 202, sending an SSTA to the SDN device such that the SDN device selects an appropriate network element according to the SSTA to determine a routing path for providing data flow to a user device according to the SSTA, wherein the SSTA including tariff information associated with the network elements.

According to an embodiment, the method may further comprise: at step 203, receiving a Traffic Change Notify Request (TCNR) including reporting criteria from the SDN device; a step 204 of determining whether the context change of the traffic meets the reporting criteria; and at step 205, sending the SDN device a Traffic Change Report (TCR) if the context change of the traffic meets the reporting criteria, such that the SDN device updates the routing path according to the TCR. The TCNR is sent during the valid period of this SDN routing path.

According to an embodiment, the TCR is sent when the tariff of the network element is higher than a predetermined threshold in the reporting criteria.

According to an embodiment, the SSTR may further comprise a user identity.

According to an embodiment, the tariff information includes a current tariff and the validation period thereof, and the SSTA further includes comments associated with comments associated with the network elements/path selection, such as the preferred network element. It is thus possible to mark comments associated with the SDN service network element/path selection from the view of charging.

According to an embodiment, the SSTR is received if the traffic is context-dependent.

According to an embodiment, the SSTA may further include an indicator which indicates the network elements whose traffic is context-dependent.

The present invention further provides an SDN device for communicating with an OCS, comprising: a transmitting means 110, configured to send an SDN Service Traffic Request (SSTR) including a list of network elements from which the traffic to be requested by a user comes to the OCS; a receiving means 120, configured to receive an SSTA including tariff information associated with the network elements from the OCS; and a processing means 130, configured to select an appropriate network element according to the SSTA to determine a routing path for providing data flow to a user device.

According to an embodiment, the transmitting means 110 may be further configured to send a Traffic Change Notify Request (TCNR) including reporting criteria; the receiving means 120 may be further configured to receive a Traffic Change Report (TCR) when the context change of the traffic meets the reporting criteria; and the processing means 130 may be further configured to update the routing path according to the TCR.

According to an embodiment, the TCR is received when the tariff of the network element is higher than a predetermined threshold in the reporting criteria.

According to an embodiment, the SSTR may further comprise a user identity.

According to an embodiment, the charging rate includes a current tariff and the validation period thereof, and the SSTA further includes comments associated with comments associated with the network elements/path selection.

According to an embodiment, the processing means 130 may be further configured to determine whether the traffic is context-dependent before sending the TCNR, wherein the TCNR is sent if the traffic is context-dependent.

According to an embodiment, the SSTA may further include an indicator which indicates the network elements whose traffic is context-dependent.

According to an embodiment, the processing means 130 may be further configured to identify the network element from which the traffic to be requested by the user comes before sending the SSTR to the OCS.

The present invention further provides an OCS for communicating with an SDN device, comprising: a receiving means 210, configured to receive an SDN Service Traffic Request (SSTR) including a list of network elements from which the traffic to be requested by a user comes from the SDN device; and a transmitting means 220, configured to send an SSTA to the SDN device such that the SDN device selects an appropriate network element according to the SSTA to determine a routing path for providing data flow to a user device according to the SSTA, wherein the SSTA including tariff information associated with the network elements.

According to an embodiment, the OCS may further comprise processing means 230, wherein the receiving means 210 may be further configured to receive a Traffic Change Notify Request (TCNR) including reporting criteria from the SDN device; the processing means 230 may be further configured to determine whether the context change of the traffic meets the reporting criteria; the transmitting means 220 may be further configured to send a Traffic Change Report (TCR) to the SDN device if the context change of the traffic meets the reporting criteria, such that the SDN device updates the routing path according to the TCR.

According to an embodiment, the TCR is sent when the tariff of the network element is higher than a predetermined threshold in the reporting criteria.

According to an embodiment, the SSTR may further comprise a user identity.

According to an embodiment, the charging rate includes a current tariff and the validation period thereof, and the SSTA further includes comments associated with comments associated with the network elements/path selection, such as the preferred network element. It is thus possible to mark comments associated with the SDN service network element/path selection from the view of charging.

According to an embodiment, the SSTR is received when the traffic is context-dependent.

According to an embodiment, the SSTA may further include an indicator which indicates the network elements whose traffic is context-dependent.

This solution enables the operators to provide dynamic routing path selection in SDN network base on context-dependent traffic. It meets the demand of using less expensive routing for end user, and benefit service provider with non-flat tariff of routing path selection and get more revenues.

At least one of the transmitting means 1 10, the receiving means 120, the processing means 130, the receiving means 210, the transmitting means 220 and the processing means 230 are assumed to comprise program instructions that, when executed, enable the means to operate in accordance with the exemplary embodiments, as discussed above. Any of the transmitting means 110, the receiving means 120, the processing means 130, the receiving means 210, the transmitting means 220 and the processing means 230 as discussed above may be integrated together or implemented by separated components, and may be of any type suitable to the local technical environment, and may comprise one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSP) and processors based on multi-core processor architectures, as non-limiting examples. The ROM mentioned above may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.

In general, the various exemplary embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto. While various aspects of the exemplary embodiments of this invention may be illustrated and described as block diagrams, flowcharts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof. It will be appreciated that at least some aspects of the exemplary embodiments of the inventions may be embodied in computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The computer executable instructions may be stored on a computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, random access memory (RAM), and etc. As will be realized by one of skill in the art, the functionality of the program modules may be combined or distributed as desired in various embodiments. In addition, the functionality may be embodied in whole or in part in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA), and the like.

Although specific embodiments of the invention have been disclosed, those having ordinary skill in the art will understand that changes can be made to the specific embodiments without departing from the spirit and scope of the invention. The scope of the invention is not to be restricted therefore to the specific embodiments, and it is intended that the appended claims cover any and all such applications, modifications, and embodiments within the scope of the present invention.