DESCRIPTION

BACKGROUND

Field

The present invention relates to apparatuses, methods, systems, computer programs, computer program products and computer-readable media usable for controlling online charging for a communication connection.

Background Art

The following description of background art may include insights, discoveries, understandings or disclosures, or associations, together with disclosures not known to the relevant prior art, to at least some examples of embodiments of the present invention but provided by the invention. Some of such contributions of the invention may be specifically pointed out below, whereas other of such contributions of the invention will be apparent from the related context. The following meanings for the abbreviations used in thi specification apply:

3GPP 3 Generation Partnership Project

ASA: abort session answer

ASR: abort session request

AVP : attribute value pair

BS : base station

CCA: credit control answer

CCR: credit control request

CPU: central processing unit

DCCA: diameter credit control application

EPC: evolved packet core

E-UTRAN: evolved UMTS terrestrial radio access network

H-PCRF: home PCRF

H-PLMN: home PLMN

HTTP: hypertext transfer protocol

IP: Internet protocol

IP CAN: IP connectivity access network

LTE: Long Term Evolution

LTE-A: LTE Advanced

MSCC: multiple service credit control

OCS: online charging system

OFCS: offline charging system

PCEF: policy and charging enforcement function

PCRF: policy and charging rules function PGW: packet data network gateway

PLMN: public land mobile network

PS: packet switched

QoS: quality of service

RAA: re-authentication answer

RAR: re-authentication request

SGW: serving gateway

TDF: traffic detection function

UE: user equipment

UMTS: universal mobile telecommunication services

VNF: virtual network function

V-PCRF: visited PCRF

V-PLMN: visited PLMN

Embodiments of the present invention are related to a communication system in which a procedure can be implemented for controlling online charging of a communication connection, in particular, for example, in an inter PLMN PS domain online charging scenario.

SUMMARY

According to an example of an embodiment, there is provided, for example, an apparatus comprising at least one processing circuitry, and at least one memory for storing instructions to be executed by the processing circuitry, wherein the at least one memory and the instructions are configured to, with the at least one processing circuitry, cause the apparatus at least: to identify at least one of a type of the command being received from an online charging system and related to a communication connection of a communication element, and an identity of the online charging system as being an online charging system of an own communication network or another communication network, and to conduct, in case the type of the command being received is a specific type of command and the identity of the online charging system indicates that the online charging system is of another communication network, a specific processing triggered by the command being received, wherein the specific processing is different to a default processing triggered by the identified type of command .

Furthermore, according to an example of an embodiment, there is provided, for example, a method comprising identifying at least one of a type of the command being received from an online charging system and related to a communication connection of a communication element, and an identity of the online charging system as being an online charging system of an own communication network or another communication network, and conducting, in case the type of the command being received is a specific type of command and the identity of the online charging system indicates that the online charging system is of another communication network, a specific processing triggered by the command being received, wherein the specific processing is different to a default processing triggered by the identified type of command.

According to further refinements, these examples may include one or more of the following features: - in case at least one of the type of the command being received is different to the specific type of command and the identity of the online charging system indicates that the online charging system is of the own communication network, a default processing triggered by the command being received may be conducted;

- a processing for identifying the type of the command being received from the online charging system may be conducted after conducting a processing for identifying the identity of the online charging system as being an online charging system of an own communication network or another communication network, or a processing for identifying the type of the command being received from the online charging system may be conducted before conducting a processing for identifying the identity of the online charging system as being an online charging system of an own communication network or another communication network, or a processing for identifying the type of the command being received from the online charging system may be conducted in parallel to conducting a processing for identifying the identity of the online charging system as being an online charging system of an own communication network or another communication network;

- the specific type of command may concern a bearer control for the communication connection of the communication element;

- the specific type of command may be related to one of a termination of a bearer and a re-authentication procedure ; - for identifying the type of the command being received from the online charging system, a result code comprised in the command or an error indication forcing a bearer control processing may be determined, wherein the command may be received in one of a credit control answer, a re-authentication request or an abort session request; - for identifying the identity of the online charging system as being an online charging system of the own communication network or another communication network, at least one of an identifier received from the online charging system, preconfigured addresses of online charging systems being stored beforehand or provided by an external network node may be determined;

- as the specific processing triggered by the command being received, a re-interpretation of the default command in which bearer related actions are exchanged by alternative actions related to at least one of service data flows being reported to the online charging system and the bearer may be conducted; information indicating a service data flow being reported to an online charging system of another communication network may be stored;

- as the specific processing triggered by the command being received, at least one of stopping of traffic for service data flows being reported to the online charging system, and inhibiting a further communication to the online charging system for a duration of a bearer of the communication connection may be conducted;

- as the specific processing triggered by the command being received, at least one of terminating credit control instances being reported to the online charging system, and terminating credit control application sessions related to the communication connection may be conducted;

- the processing described above may be implemented in a communication network control element configured to act as at least one of a packet data network gateway and a policy and charging enforcement function of own communication network, wherein the communication element may be visiting the own communication network and belong to the another communication network, wherein the communication element may include at least one of a terminal device or user equipment.

In addition, according to embodiments, there is provided, for example, a computer program product for a computer, including software code portions for performing the steps of the above defined methods, when said product is run on the computer. The computer program product may include a computer-readable medium on which said software code portions are stored. Furthermore, the computer program product may be directly loadable into the internal memory of the computer and/or transmittable via a network by means of at least one of upload, download and push procedures.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments of the present invention are described below, by way of example only, with reference to the accompanying drawings, in which: Fig. 1 shows a diagram illustrating an architecture of a communication system part where some examples of embodiments are implementable ;

Fig. 2 shows a signaling diagram illustrating a signal exchange according to some examples of embodiments;

Figs. 3a and 3b show signaling diagrams illustrating a signal exchange according to a comparative example and according to some examples of embodiments;

Fig. 4 shows a flow chart of a processing conducted in a communication network control element or function according to some examples of embodiments; and

Fig. 5 shows a diagram of a network element acting as a communication network control element or function according to some examples of embodiments; and

DESCRIPTION OF EMBODIMENTS

In the last years, an increasing extension of communication networks, e.g. of wire based communication networks, such as the Integrated Services Digital Network (ISDN), DSL, or wireless communication networks, such as the cdma2000 (code division multiple access) system, cellular 3rd generation (3G) like the Universal Mobile Telecommunications System (UMTS) , fourth generation (4G) communication networks or enhanced communication networks based e.g. on LTE or LTE-A, fifth generation (5G) communication networks, cellular 2nd generation (2G) communication networks like the Global System for Mobile communications (GSM) , the General Packet Radio System (GPRS) , the Enhanced Data Rates for Global Evolution (EDGE) , or other wireless communication system, such as the Wireless Local Area Network (WLAN) , Bluetooth or Worldwide Interoperability for Microwave Access (WiMAX) , took place all over the world. Various organizations, such as the 3rd Generation Partnership Project (3GPP) , Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN) , the International Telecommunication Union (ITU), 3rd Generation Partnership Project 2 (3GPP2), Internet Engineering Task Force (IETF), the IEEE (Institute of Electrical and Electronics Engineers) , the WiMAX Forum and the like are working on standards or specifications for telecommunication network and access environments.

Embodiments as well as principles described below are applicable in connection with any communication element or terminal device, network element, relay node, server, node, corresponding component, and/or to any communication system or any combination of different communication systems that support required functionalities. The communication systems may be any one or any combination of a fixed communication system, a wireless communication system or a communication system utilizing both fixed networks and wireless networks. The protocols used, the specifications of communication systems, apparatuses, such as nodes, servers and user terminals, especially in wireless communication, develop rapidly. Such development may require extra changes to an embodiment. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, embodiments.

In the following, different exemplifying embodiments will be described using, as an example of an access architecture to which the embodiments may be applied, a radio access architecture based on 3GPP standards, such as a third generation or fourth generation (like LTE or LTE-A) communication network, without restricting the embodiments to such architectures, however. It is obvious for a person skilled in the art that the embodiments may also be applied to other kinds of communications networks having suitable means by adjusting parameters and procedures appropriately, e.g. WiFi, worldwide interoperability for microwave access

(WiMAX) , Bluetooth®, personal communications services (PCS) , ZigBee®, wideband code division multiple access (WCDMA) , systems using ultra-wideband (UWB) technology, sensor networks, and mobile ad-hoc networks (MANETs) .

The following examples and embodiments are to be understood only as illustrative examples. Although the specification may refer to "an", "one", or "some" example (s) or embodiment ( s ) in several locations, this does not necessarily mean that each such reference is related to the same example (s) or embodiment ( s ) , or that the feature only applies to a single example or embodiment. Single features of different embodiments may also be combined to provide other embodiments. Furthermore, terms like "comprising" and "including" should be understood as not limiting the described embodiments to consist of only those features that have been mentioned; such examples and embodiments may also contain features, structures, units, modules etc. that have not been specifically mentioned.

A basic system architecture of a communication system where some examples of embodiments are applicable may include an architecture of communication networks including a wired or wireless access network subsystem and a core network. Such an architecture may include one or more communication network control elements, access network elements, radio access network elements, access service network gateways or base transceiver stations, such as a base station (BS) , an access point (AP) or an eNB, which control a respective coverage area or cell (s) and with which one or more communication elements, user devices or terminal devices, such as a UE, or another device having a similar function, such as a modem chipset, a chip, a module etc., which can also be part of an element, function or application capable of conducting a communication, such as a UE, an element or function usable in a machine-to-machine communication architecture, or attached as a separate element to such an element, function or application capable of conducting a communication, or the like, are capable to communicate via one or more channels for transmitting several types of data. Furthermore, core network elements such as gateway network elements, policy and charging control network elements are included.

The general functions and interconnections of the described elements, which also depend on the actual network type, are known to those skilled in the art and described in corresponding specifications, so that a detailed description thereof is omitted herein. However, it is to be noted that several additional network elements and signaling links may be employed for controlling and/or charging a communication to or from an element, function or application, like a communication element, such as a UE, a communication network control element, such as an server, and other elements of the same or other communication networks besides those described in detail herein below.

A communication network as described in examples of embodiments may also be able to communicate with other networks, such as a public switched telephone network or the Internet. The communication network may also be able to support the usage of cloud services. It should be appreciated that network elements of an access system, of a core network etc., and/or respective functionalities may be implemented by using any node, host, server, access node or entity etc. being suitable for such a usage.

Furthermore, the described network elements, such as communication elements, like a UE, access network elements, communication network control elements, like a gateway or a policy and charging control element, as well as corresponding functions as described herein, and other elements, functions or applications may be implemented by software, e.g. by a computer program product for a computer, and/or by hardware. For executing their respective functions, correspondingly used devices, nodes or network elements may include several means, modules, units, components, etc. (not shown) which are required for control, processing and/or communication/signaling functionality. Such means, modules, units and components may include, for example, one or more processors or processor units including one or more processing portions for executing instructions and/or programs and/or for processing data, storage or memory units or means for storing instructions, programs and/or data, for serving as a work area of the processor or processing portion and the like (e.g. ROM, RAM, EEPROM, and the like), input or interface means for inputting data and instructions by software (e.g. floppy disc, CD-ROM, EEPROM, and the like), a user interface for providing monitor and manipulation possibilities to a user (e.g. a screen, a keyboard and the like) , other interface or means for establishing links and/or connections under the control of the processor unit or portion (e.g. wired and wireless interface means, radio interface means including e.g. an antenna unit or the like, means for forming a radio communication part etc.) and the like, wherein respective means forming an interface, such as a radio communication part, can be also located on a remote site (e.g. a radio head or a radio station etc.) . It is to be noted that in the present specification processing portions should not be only considered to represent physical portions of one or more processors, but may also be considered as a logical division of the referred processing tasks performed by one or more processors.

It should be appreciated that according to some examples, a so-called "liquid" or flexible network concept may be employed where the operations and functionalities of a communication network control element, network function, or of another entity of the communication network, may be performed in different entities or functions, such as in a node, host or server, in a flexible manner. In other words, a "division of labor" between involved network elements, functions or entities may vary case by case.

An essential functionality for every service provider, such telecommunication network operators is charging. For this purpose, communication networks comprise charging systems having set of nodes or functions being dedicated to fulfilling this task.

Generally, charging can be realized as prepaid or postpaid. Commercial communication networks usually implement both of them. Depending on the used service, such as telephony, video telephony, wireless, video on demand etc, the used charging method may vary.

Prepaid and postpaid charging methods are substantially different from the network point of view. The most important difference is that when a user wants to use a prepaid service, the network has to decide whether it should be allowed, according to the user's current account balance. Hence, before any service usage, the charging system has to be asked for permission. That is, a credit authorization has to be obtained. To make this decision, the charging system has to know an account balance of the user in real time.

Thus, an efficient way of handling credit authorization within an appropriate period of time is to be provided. This is achieved by online charging allowing real-time account updating being required in a prepaid scenario, while a postpaid charging can be handled by an offline charging .

In online charging, a subscriber account, located in an OCS, is queried prior to granting permission to use the requested network resource (s) . An OCS is, for example, an entity or function that performs real-time credit control. Credit control relates to a mechanism which directly interacts in real-time with an account and controls or monitors the charges, related to the service usage. Credit control is a process of checking if credit is available, credit reservation, deduction of credit from the end user account when service is completed and refunding of reserved credit not used. The OCS has several functionalities which include, for example, transaction handling, rating, online correlation and management of subscriber accounts/balances.

The purpose of online charging is to furnish charging information to the OCS in order to perform credit control before the network resource usage is permitted. To this end, a prepaid subscriber account has to exist in the OCS, against which the resource usage can be billed. Therefore, all activities to assess the requested resource usage, to determine its value in monetary or other units, and to debit these units from the subscriber account, has to occur prior to or at least during the resource usage—that is, online with respect to resource usage. In online charging, charging information for network resource usage is collected concurrently with that resource usage. Authorization for the network resource usage has to be obtained by the network prior to the actual resource usage to occur. This authorization is granted by the OCS upon request from the network.

When receiving a network resource usage request, the network assembles the relevant charging information and generates a charging event towards the OCS in real-time. The OCS then returns an appropriate resource usage authorization. The resource usage authorization may be limited in its scope (e.g. volume of data or duration), therefore the authorization may have to be renewed from time to time as long as the user's network resource usage persists .

For transporting requests related to charging, a protocol such as Diameter can be used.

In a PS domain, online charging may be performed by a communication network control element including a PCEF (e.g. located in a PGW) and by a TDF using a credit control application. For example, in order to provide the data required for management activities such as credit control, accounting, statistics etc., the PCEF is configured to perform online charging, for example, for charging data related to IP-CAN bearers and charging data related to service data flows (the TDF is configured, for example, to perform online charging for charging data related to TDF sessions and for charging data related to detected application traffic) .

In some communication network configurations, the OCS may be configured to send commands to a communication network control element, such as a gateway node or function, by means of which it is possible to allow, block, redirect or grant quota to a particular service data flow. Furthermore, it is also possible that the OCS is configured to send commands to the communication network control element, such as a gateway node or function, which apply not only to a particular service data flow but apply to the whole bearer. For example, a corresponding procedure is applicable to a case where a DCCA session (the purpose of DCCA is to provide a framework for real-time charging, primarily meant for the communication between gateways/control points and the OCS) is allowed to be created, a bearer creation is allowed/blocked, all traffic is blocked or the bearer is terminated at any point.

Within one and the same network, e.g. in an intra PLMN PS online charging scenario, such an operation where the OCS issues commands towards a communication network control element such as a PGW works well because so far both, the OCS and the PGW, belong to the same PLMN. In other words, an operator who owns the IP CAN session also owns the OCS so that commands issued by the OCS are aligned or can be aligned in a suitable manner to policies of the communication network. However, the situation changes when considering a scenario involving inter PLMN PS online charging. In inter PLMN PS online charging, when a communication element such as a UE is roaming to another communication network (i.e. visiting another network, i.e. a V-PLMN) , the OCS of the home network (H-PLMN) is still in charge of charging for service usage. That is, inter PLMN PS online charging refers to a roaming case when the IP Gateway (e.g. the PGW) pertains to the V-PLMN, whereas the OCS pertains to the H-PLMN.

With regard to Fig. 1, a diagram illustrating a general architecture of a communication system is shown where some examples of embodiments are implementable . It is to be noted that the structure indicated in Fig. 1 shows only those devices, network elements and links which are useful for understanding principles underlying some examples of embodiments of the invention. As also known by those skilled in the art there may be several other network elements or devices involved in a communication in the communication system which are omitted here for the sake of simplicity .

In Fig. 1, communication networks are shown which form a general basis of the example of a communication system according to some examples of embodiments. Specifically, as a communication network, a wireless communication network based for example on a 3GPP specification is provided. Furthermore, it is assumed that at least one other communication network using the same or a similar access technology is present, wherein one of the communication networks represent a visited network (V-PLMN) for a roaming communication element while the other communication network is the home network (H-PLMN) of the roaming communication element .

It is to be noted that both the number of networks and network elements as well as the type thereof as depicted in Fig. 1 are merely intended to provide a basis for illustrating the principles of the control processing according to some examples of embodiments, while each one of the number and type of the involved network elements and types may be different to those shown in Fig. 1.

According to Fig. 1, reference sign 10 denotes a communication element, such as a UE, e.g. of a subscriber which represents one terminal point of a communication, and which "visits" (roams to) a communication network being referred to a V-PLMN.

Reference signs 20 denotes an access network subsystem, such as an E-UTRAN, allowing access to the (visited) communication network. For example, an eNB or base station (not shown) are included in the access network subsystem 20. The link between UE 10 and the access network subsystem 20 is referred to, for example, as Uu interface.

Reference sign 30 denotes a core network control element such as a SGW, which is connected to the access network subsystem 20 via an SI interface, for example. Reference sign 40 denotes a communication network control element such as a PGW. The PGW 40 acts as an "anchor" of mobility between 3GPP and non-3GPP technologies and provides connectivity from the UE to an external PDN by being the point of entry or exit of traffic for the UE . For example, the PGW 40 manages policy enforcement, packet filtration for users, charging support etc. The PGW 40 is linked to the SGW 30 by a S5 interface, for example.

Reference sign 40 denotes a communication network control element such as a PCEF. According to some examples of embodiments, the PCEF 50 can be a separate network element or function, or be integrated in the PGW 40. In the following, it is assumed that the latter configuration applies .

The PCEF 50 enforces policy decisions that are received from a PCRF (described later) and provides the PCRF with subscriber and access information. The PCEF is part of a configuration including online and offline charging, and quality of service determination. The PCEF interacts with internal charging functions, which, in turn, interacts with an OCS 100 which provides credit management for prepaid charging, as discussed above, and reports resource usage to an OFCS 60.

The OFCS 60 is linked to the PCEF 50 by means of a Gz interface, for example. The link between the PCEF 50 and an OCS (in the presented case the OCS is located in the H-PLMN of the UE 10 due to the inter PLMN PS online charging) is provided by a Gy interface, for example.

Reference sign 70 denotes a TDF, which is linked to the OFCS 60 by means of a Gzn interface, for example, and to the OCS by means of a Gyn interface, for example.

Reference sign 80 denotes the PCRF (here indicates as V- PCRF of the visited PLMN) . The data exchange with the PCEF 50 is done via a Gx interface for example. Similarly, data exchange with the TDF 70 is done via a Sd interface, for example .

The above described elements 20 to 80 belong to the visited PLMN of the roaming UE 10. On the other hand, the following elements 90 and 100 are part of the home network (H-PLMN) of the UE 10. Specifically, reference sign 90 denotes a PCRF of the home network (H-PCRF) which communicates with the V-PCRF 80 via a S9 interface, for example.

Reference sign 100 denotes the OCS having the functions as described above. The OCS 100 is connected to the H-PCRF by means of a Sy interface, for example.

Assuming now that the UE 10 establishes a communication connection, such as a voice call, a video call or the like, towards a destination (e.g. another UE (not shown)) via the V-PLMN (roaming scenario) , wherein services of the V-PLMN are to be used and thus to be charged. In this case, a charging session between the visited network (i.e. the communication network control element represented by the PGW/PCEF 40/50) and the OCS of the home network is established. In this session, requests and answer messages are exchanged between the PCEF 50 and the OCS 100 via the Gy interface. Furthermore, signal data flows being charged in this charging session are reported by the network to the OCS 100.

Fig. 2 shows a signaling diagram illustrating a general procedure for exchanging data, such as request signaling and answer signaling, between the PCEF 50 and the OCS 100.

Specifically, S10 indicates the transmission of a request from the PCEF 50 to the OCS 100, such as a CCR. S20 indicates the transmission of an answer to the request in S10 from the OCS 100 to the PCEF 50, such as a CCA.

Alternatively or additionally, S30 indicates the transmission of a request from the OCS 100 to the PCEF 50 requesting the release of the IP CAN bearer or the reauthorization for the IP CAN bearer or service data flow, such as an ASR or RAR. S40 indicates the transmission of an answer to the request in S30 from the PCEF 50 to the OCS 100, such as an ASA or RAA.

When an inter PLMN PS online charging scenario is implemented, as indicated above, the OCS (i.e. the H-PLMN' s OCS 100) is configured to send commands to a communication network control element controlling a communication of the UE in question, i.e. for which a charging session is established. For example, the OCS may be configured to send a CCA command with result codes ordering to terminate a bearer at the network. Examples of corresponding result codes comprise, for example, DIAMETER_RATING_FAILED (5031) , AUTHORI ZATION_REJECTED (5003), END_USER_SERVICE_DENIED

(4010), USER_UNKNOWN (5030), CREDIT_CONTROL_NOT_APPLICABLE (4011), CREDIT_LIMIT_REACHED (4012), protocol errors

(3xxx) , transient errors that are not listed above (4xxx) , permanent errors that are not listed above (5xxx) , any of which results in a termination of a bearer or that a bearer is not established at all, for example.

It is to be noted that there are also other ways or situations where a behavior of the OCS can trigger, for example, the release of a bearer. For example, in case a Tx timer expired (CCR is sent, but OCS does not reply) , a bearer may be released. Furthermore, in case the OCS replies with a CCA but the CCA includes an illegal AVP which makes the PCEF to treat the CCA as an error, the bearer may be released. That is, a command to be considered in the examples of embodiments of the invention is related to direct commands including e.g. result codes, and/or an error indication forcing a bearer control processing which may also include the absence of a direct instruction.

However, in the present case, the communication network control element in question is of the V-PLMN, i.e. of another network. That is, in case of an inter PLMN PS online charging scenario, the H-PLMN OCS may send a command, such as a CCA command with result codes ordering to terminate a bearer at the V-PLMN, which could lead to a situation where the V-

PLMN grants a foreign OCS decisions about its own network.

However, such a situation is not desired by network operators. Basically, it is not desired to allow that decisions of a foreign entity, such as a foreign OCS, influence or control the own network. It is acceptable that the foreign OCS (i.e. the H-PLMN OCS) is given control over service data flows which are reported to it. However, control over other network parts, such as IP CAN session and IP CAN bearers which the (roaming) UE is using, is desired to be kept under the control of the network to which they belong, i.e. to the V-PLMN and its control parts .

According to examples of embodiments, the communication network control element of the communication network where the communication connection of the (roaming) UE 10 is established, i.e. of the V-PLMN, such as the PGW/PCEF 40/50 is configured to treat commands coming over the same interface, such as the same Gy commands, in a different manner, depending if the charging system, such as the OCS which triggered the commands, belongs to a different PLMN than the PCEF. In other words, according to examples of embodiments, the communication network control element, such as the PGW/PCEF 40/50, determines whether a specific command type is received from an OCS being of the same network (i.e. of the V-PLMN) or of another PLMN (i.e. the H-PLMN) .

For example, in case a command is send from the H-PLMN OCS 100 including a result code which commands to terminate the bearer of the communication connection of the UE 10, or another of the above examples regarding behavior or action from the OCS leading to a release of the bearer applies, as it is not desired to allow a foreign OCS to control bearers in the own network, the communication network control element such as the PGW/PCEF 40/50 is configured to interpret this command in another manner. That is, actions caused by the original command transported to the PCEF from the H-PLMN OCS 100 are replaced by preconfigured actions which can apply to the bearer or only to service data flows or both.

For example, instead of terminating the bearer which may be default measure triggered by this sort of command, the command is interpreted that no further traffic is allowed for service data flows being reported to the OCS. For example, the command is interpreted to trigger a termination of e.g. credit control instances, such as all MSCC instances, which are being reported to the H-PLMN OCS.

Furthermore, the command may be interpreted that no further communication to the HPLMN OCS 100 for the duration of the bearer is allowed. For example, a DCCA session is terminated. That is, even though the DCCA session is terminated, the bearer will remain alive allowing, for example, that policies of the V-PLMN can still be applied. For example, since the bearer is still alive, only-free-of- charge traffic is still allowed, HTTP traffic can be redirected to V-PLMN Advice of Charge Server, etc..

It is to be noted that the same applies also in other procedures. For example, it can be inhibited that in case the H-PLMN OCS 100 sends any commands which applies for the whole IP CAN bearer, e.g. in case the H-PLMN OCS 100 commands are sent in RAR or ASR messages, these commands are executed by the visited network; instead the commands can be re-interpreted, as indicated above.

For identifying the OCS, i.e. to which network it belongs, the communication network control element may preconfigure the OCS addresses which belong to an Inter-PLMN network, for example. Alternatively, also other measures can be used. For example, the type of OCS (inter or intra-PLMN OCS) can be provided by other means, for example by information from the PCRF.-

In this context, it is to be noted that the order of identifying the OCS from which the command is received and identifying the type of the command may be varying in different examples of embodiments. For example, in case the OCS identity is determined first (for example, in case there is a direct connection between the PCEF and the OCS, the identity of the OCS is known since before any DCCA session has been created in the OCS) , it is possible to avoid the processing related to the type of command when it is determined that the OCS is of the same network, so that the command is to be executed in a default processing. Thus, the processing load can be reduced. On the other hand, in case the type of command is identified first (for example when the identity of the OCS is not known in advance, e.g. due to the usage of an OCS proxy or the like which allows the identification of the OCS identity only when the DCCA session is created) , the processing related to the identification of the OCS can be avoided, e.g. in case it is determined that the command is not a specific command and can be hence executed without re- interpretation. Furthermore, both processings can be executed in parallel which may accelerate the processing.

For illustrating effects according to some examples of embodiments regarding the control of bearers, Figs. 3a and 3b show signaling diagrams illustrating a signal exchange according to a comparative example and according to some examples of embodiments. Specifically, Fig. 3a shows a comparative example in which a signaling between a PCEF of a visited network and an OCS of a home network leads to the above described unwanted control of bearers by a foreign OCS, while Fig. 3b shows an example according to examples of embodiments in which a signaling between a PCEF of a visited network and an OCS of a home network leads to a control of bearers as described above.

According to Fig. 3a, in S200, an IP CAN bearer is created. In S210, a charging session with the OCS 100 is initiated by the PGW/PCEF 40/50 by a CCR-I (I stands for initiation phase) . The charging session is successfully started by sending a CCA-I (success) from the OCS 100 to the PGW/PCEF 40/50 in S220. Then in S230, delivery of free traffic is granted by the visited network.

In S240, it is assumed that the PGW/PCEF 40/50 decides to send a request for online charging to the OCS 100. For this purpose, in S250, a CCR-U (U stands for update) is transmitted to the OCS 100. Now, it assumed that the OCS 100 answers in S260 with a CCA-U signaling indicating an error. For example, the error in the OCS reply includes any OCS related error which forces the bearer be terminated, such as an error result code, Tx expired, failed AVP etc..

Thus, in S270, a termination of the bearer is triggered at the visited network side, wherein also a DCCA session is terminated, and the bearer is released.

In S280, the PGW/PCEF 40/50 sends a CCR-T (T stands for termination) signaling to the OCS, which is replied in S290 by a CCA-T (success) signaling.

Thus, as described above, in the procedure described in Fig. 3a, the OCS 100 of the foreign network controls bearers at the visited network.

On the other hand, according to Fig. 3b, similar to Fig. 3a, in S300, an IP CAN bearer is created. In S310, a charging session with the OCS 100 is initiated by the PGW/PCEF 40/50 by a CCR-I signaling. The charging session is successfully started by sending a CCA-I (success) from the OCS 100 to the PGW/PCEF 40/50 in S320. Then in S330, delivery of free traffic is granted by the visited network.

In S340, it is assumed that the PGW/PCEF 40/50 decides to send a request for online charging to the OCS 100. For this purpose, in S350, a CCR-U is transmitted to the OCS 100. Again, it assumed that the OCS 100 answers in S360 with a

CCA-U signaling indicating an error (as in case of Fig. 3a, the error in the OCS reply includes any OCS related error which forces the bearer be terminated, such as an error result code, Tx expired, failed AVP etc.) .

However, according to examples of embodiments, since the OCS 100 is of a foreign network, the command being received, when being related to a bearer, for example, is reinterpreted. Thus, according to examples of embodiments, for example, instead of terminating the bearer (as in S270 of Fig. 3a), which is triggered by the signaling in S360, in S370, on the DCCA session is terminated, for example, while the bearer is not released.

In S380, the PGW/PCEF 40/50 sends a CCR-T signal to the OCS

100, which is replied in S390 by a CCA-T (success) signaling . In S400, free traffic can be delivered while local policies (i.e. that of the PGW 40 of the visited network) can be applied, for example redirect, terminate, continue, modified QoS, etc.

Thus, in the procedure described in Fig. 3b, the OCS 100 of the foreign network is not allowed to control bearers at the visited network.

That is, according to examples of embodiments, when referring back to the result codes being used for commands, the following reinterpretation or exchange of commands applies .

In case, for example, the OCS 100 sends a CCA with result code: "DIAMETER_RATING_FAILED (5031)", while the default behavior would be to terminate the IP CAN bearer, the behavior according to examples of embodiments, in case it is determined that the OCS belongs to different network, it to apply own network policies, for example that the bearer remains active and free traffic being allowed. As another example, as part of creating the bearer, when the OCS is contacted (by CCR) to authorize the bearer to be created, and the OCS replies (by CCA) with "AUTHORI ZATION_REJECTED (5003)", the default behavior would be that the IP CAN bearer is not allowed to be created; on the other hand, the behavior according to examples of embodiments, in case the OCS belongs to different network, is, for example, to apply own network policies, for example to allow the bearer creation and to redirect it to Advice of Charge server, from the own network. It is to be noted that a corresponding processing is also applicable in case of other result codes, for example.

Fig. 4 shows a flow chart of a processing conducted in a communication network control element, such as a PGW/PCEF, according to some examples of embodiments. Specifically, the example according to Fig. 4 is related to a control procedure conducted by a communication network control element, function or node acting as a PCEF 50 in the communication network system as depicted e.g. in Fig. 1.

In S100, an identity of the OCS from which there is an active diameter connection is identified, e.g. by means of preconfiguration of the OCS address at the PCEF or the like, for example. Specifically, it is identified whether the OCS is an online charging system of an own communication network (i.e. the communication network of the PGW/PCEF) or another communication network, i.e. a foreign PLMN like the H-PLMN of the UE in question, for example .

In S110, a command (e.g. by means of CCA in S20 of Fig. 2), is received from an OCS and processed, wherein the command is related to a communication connection of a communication element, such as UE 10, where e.g. one or more service data flows are charged. As indicated above, the UE 10 may be a visiting UE making the communication network to which the communication network control element such as the PGW/PCEF 40/50 belongs a V-PLMN, while the OCS may be of the H-PLMN of the UE 10.

-In this connection, according to some examples of embodiments, an identifier or the like related to the OCS in question is determined for identifying the identity of the OCS as being an OCS of the own communication network or another communication network. For example, such an identifier may be received from the OCS 100, e.g. in combination with the command. Alternatively, according to further examples of embodiments, other means for identifying the OCS are used. For example, the identity of the OCS as being an OCS of the own communication network or another communication network can be based on preconfiguration at the PCEF of Inter PLMN OCS addresses, or it can for example be provided to the PCEF by a PCRF or by a trusted diameter proxy in the own communication network, or it can for example be provided by any other network element in the own communication network by a suitable manner.

In S120, in case the identity of the OCS is identified as being an OCS of another communication network (S120: YES), the process proceeds to S130. Otherwise, in case the identity of the OCS is identified as being an OCS of the own communication network (S120: NO), the process proceeds to S160.

In S130, a type of the command being received from the OCS and being related to a communication connection of the UE is identified. In detail, it is determined whether or not the command being received is of a specific type of command .

According to examples of embodiments, the specific type of command concerns a bearer control for the communication connection of the UE . For example, the specific type of command is related to one of a termination of a bearer and a re-authentication procedure. In this context, according to some examples of embodiments, for identifying the type of the command being received from the OCS, a result code comprised in the command is identified. Alternatively, it is determined whether an error indication forcing a bearer control processing, especially, a bearer termination, is involved, which may also include Tx expiry. It is to be noted that according to some examples of embodiments, the command is received in one of a CCA-, RAR an ASR, for example .

In S140, in case the type of the command is identified as being a specific type of command (S140: YES), the process proceeds to S150. Otherwise, in case the type of command is identified as being not of the specific type (S140: NO), the process proceeds to S160.

It is to be noted that according to some examples of embodiments, the order of processing according to S110/S120 on the one side (i.e. the identification of the OCS) and according to S130/S140 on the other side may be different to the order presented in Fig. 4, where the processing for identifying the type of the command being received from the OCS is conducted after conducting the processing for identifying the identity of the OCS as being an OCS of an own communication network or another communication network. For example, it is also possible to conduct the processing for identifying the type of the command being received from the OCS before conducting a processing for identifying the identity of the OCS as being an OCS of an own communication network or another communication network. Alternatively, it is also possible to conduct the processing for identifying the type of the command being received from the OCS in parallel to conducting a processing for identifying the identity of the OCS as being an OCS of an own communication network or another communication network.

In S150, in case the type of the command being received is a specific type of command (S140: YES) and the identity of the OCS indicates that the OCS is of another communication network (S120: YES), a specific processing triggered by the command being received is conducted. This specific processing is different to a default processing triggered by the identified type of command. According to some examples of embodiments, the specific processing triggered by the command being received comprises a re-interpretation of the default command in which bearer related actions commanded by OCS are exchanged by the own network actions, which can apply to the bearer, or only to the service data flows being reported to the online charging system, or to both. It is to be noted that according to some examples of embodiments, information indicating a service data flow being reported to an OCS of another communication network is stored beforehand. For example, according to some examples of embodiments, as the specific processing triggered by the command being received, at least one of a processing for stopping the traffic for service data flows being reported to the OCS and a processing for inhibiting a further communication to the OCS for a duration of a bearer of the communication connection is conducted. According to further examples of embodiments, as the specific processing triggered by the command being received, at least one of a processing for terminating credit control instances (e.g. MSCC instances) being reported to the OCS and a processing for terminating credit control application sessions (e.g. DCCA sessions) related to the communication connection is conducted.

As a further example of own network actions, besides the reinterpretation of result codes received from the OCS, mechanisms of failure handling (Terminate, Retry-and- Terminate, Continue) can be reinterpreted for the case where the OCS belongs to a different network. For example, if OCS doesn't reply and the DCCA session expires, if the default failure handling is to terminate the bearer, for the case when the OCS belongs to a different network, according to examples of embodiments, the failure handling is reinterpreted for own operator failure handling for errors in Inter PLMN OCS sessions. For example, instead of applying failure handling "terminate", it can apply failure-handling "continue". Otherwise, in S160, in case the type of the command being received is different to the specific type of command and/or the identity of the OCS indicates that the OCS is of the own communication network, a default processing triggered by the command being received. That is, actions being indicated in the command are executed without any re- interpretation, which also includes bearer related commands (when being instructed from the OCS of the own communication network) .

Fig. 5 shows a diagram of a communication network control element according to some examples of embodiments, which is configured to implement a control procedure as described in connection with some of the examples of embodiments. It is to be noted that the communication network control element, like the PGW/PCEF 40/50, which is shown in Fig. 5, may include further elements or functions besides those described herein below. Furthermore, even though reference is made to a communication network control element or node, the element or node may be also another device or function having a similar task, such as a chipset, a chip, a module, an application etc., which can also be part of a communication network control element or attached as a separate element to a communication network control element, or the like. It should be understood that each block and any combination thereof may be implemented by various means or their combinations, such as hardware, software, firmware, one or more processors and/or circuitry . The communication network control element shown in Fig. 5 may include a processing circuitry, a processing function, a control unit or a processor 51, such as a CPU or the like, which is suitable for executing instructions given by programs or the like related to the control procedure. The processor 51 may include one or more processing portions or functions dedicated to specific processing as described below, or the processing may be run in a single processor or processing function. Portions for executing such specific processing may be also provided as discrete elements or within one or more further processors, processing functions or processing portions, such as in one physical processor like a CPU or in one or more physical or virtual entities, for example. Reference sign 52 denotes transceiver or input/output (I/O) units or functions

(interfaces) connected to the processor or processing function 51. The I/O units 52 may be used for communicating with other elements of the communication network, such as a communication network as shown in Fig. 1, and in particular with an online charging system, such as the OCS 100. The

I/O units 52 may be a combined unit including communication equipment towards several network elements, or may include a distributed structure with a plurality of different interfaces for different network elements. Reference sign 54 denotes a memory usable, for example, for storing data and programs to be executed by the processor or processing function 51 and/or as a working storage of the processor or processing function 51. It is to be noted that the memory 54 may be implemented by using one or more memory portions of the same or different type of memory. The processor or processing function 51 is configured to execute processing related to the above described control procedure. In particular, the processor or processing circuitry or function 51 includes one or more of the following sub-portions. Sub-portion 510 is a processing portion which is usable for identifying an OCS identity. The portion 510 may be configured to perform processing according to S100 and S120 of Fig. 4. Furthermore, the processor or processing circuitry or function 51 may include a sub-portion 511 usable as a portion for identifying a type of command being received. The portion 511 may be configured to perform a processing according to S130 and S140 of Fig. 4. In addition, the processor or processing circuitry or function 51 may include a sub- portion 512 usable as a portion for selecting and conducting a processing triggered by the command. The portion 512 may be configured to perform a processing according to S150 and S160 of Fig. 4.

It is to be noted that some or all of the examples of embodiments described above may be applied to a partly or fully virtualized environment comprising one or more VNFs .

In addition, according to another example of embodiments, there is provided an apparatus comprising means for identifying at least one of a type of the command being received from an online charging system and related to a communication connection of a communication element, and an identity of the online charging system as being an online charging system of an own communication network or another communication network, and means for conducting, in case the type of the command being received is a specific type of command and the identity of the online charging system indicates that the online charging system is of another communication network, a specific processing triggered by the command being received, wherein the specific processing is different to a default processing triggered by the identified type of command.

Furthermore, according to some other examples of embodiments, the above defined apparatus may further comprise means for conducting at least one of the processings defined in the above described methods, for example a method according that described in connection with Fig 4.

As indicated above, by means of the measures described above for controlling online charging for a communication connection, it is possible to inhibit that an OCS of another communication network (such as a home network of a visiting UE) issues commands to the visited network which concern bearer handling or the like (e.g. termination of a bearer) which are then executed by the network. In other words, it is possible to inhibit that a network grants decision of a foreign OCS or the like about the own network.

It should be appreciated that

- an access technology via which traffic is transferred to and from a network element may be any suitable present or future technology, such as WLAN (Wireless Local Access Network) , WiMAX (Worldwide Interoperability for Microwave Access) , LTE, LTE-A, Bluetooth, Infrared, and the like may be used; additionally, embodiments may also apply wired technologies, e.g. IP based access technologies like cable networks or fixed lines. a user device (also called UE, user equipment, user terminal, terminal device, etc.) illustrates one type of an apparatus to which resources on the air interface may be allocated and assigned, and thus any feature described herein with a user equipment may be implemented with a corresponding apparatus, such as a relay node. An example of such a relay node is a layer 3 relay ( self-backhauling relay) towards a base station or eNB . The user device typically refers to a portable computing device that includes wireless mobile communication devices operating with or without a subscriber identification module (SIM) , including, but not limited to, the following types of devices: a mobile station (mobile phone), smart phone, personal digital assistant (PDA) , handset, device using a wireless modem (alarm or measurement device, etc.), laptop and/or touch screen computer, tablet, game console, notebook, and multimedia device. It should be appreciated that a user device may also be a nearly exclusive uplink only device, of which an example is a camera or video camera loading images or video clips to a network, or a nearly exclusive downlink only device, such as a portable video player. Also equipment used for measuring certain values, such as sensors which can measure a temperature, a pressure etc., can be used as a corresponding user device.

It should be appreciated that a device may be regarded as an apparatus or as an assembly of more than one apparatus, whether functionally in cooperation with each other or functionally independently of each other but in a same device housing.

- embodiments suitable to be implemented as software code or portions of it and being run using a processor or processing function are software code independent and can be specified using any known or future developed programming language, such as a high-level programming language, such as objective-C, C, C++, C#, Java, Python, Javascript, other scripting languages etc., or a low-level programming language, such as a machine language, or an assembler .

- implementation of embodiments is hardware independent and may be implemented using any known or future developed hardware technology or any hybrids of these, such as a microprocessor or CPU (Central Processing Unit) , MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), and/or TTL (Transistor-Transistor Logic). - embodiments may be implemented as individual devices, apparatuses, units, means or functions, or in a distributed fashion, for example, one or more processors or processing functions may be used or shared in the processing, or one or more processing sections or processing portions may be used and shared in the processing, wherein one physical processor or more than one physical processor may be used for implementing one or more processing portions dedicated to specific processing as described,

- an apparatus may be implemented by a semiconductor chip, a chipset, or a (hardware) module including such chip or chipset ; - embodiments may also be implemented as any combination of hardware and software, such as ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field- programmable Gate Arrays) or CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components .

- embodiments may also be implemented as computer program products, including a computer usable medium having a computer readable program code embodied therein, the computer readable program code adapted to execute a process as described in embodiments, wherein the computer usable medium may be a non-transitory medium.

Although the present invention has been described herein before with reference to particular embodiments thereof, the present invention is not limited thereto and various modifications can be made thereto.