Patent Application
20150319058
The present invention relates to methods for reporting events in a mobile telecommunications network and to corresponding devices.
In mobile telecommunications networks, event reporting may be used for providing inputs to certain control processes. For example, in 3GPP (3rd Generation Partnership Project) mobile networks, e.g., GSM (Global System for Mobile communications), UMTS (Universal Mobile Telecommunications System), or LTE (Long Term Evolution) networks, a reported event may trigger establishment or configuration of a bearer for carrying data of a packet based service to or from a user equipment (UE).
In 3GPP mobile networks, a policy and charging control (PCC) architecture as defined in 3GPP Technical Specification 23.203 may be provided so as to support such event reporting and control processes. This PCC architecture may be used for controlling various types of radio access technology (RAT) and corresponding radio access networks, including 3GPP accesses such as GERAN (GSM Radio Access Network), UTRAN (UMTS Terrestrial Radio Access Network) and E-UTRAN (Evolved UTRAN), and non-3GPP accesses, e.g., based on WLAN (Wireless Local Area Network). In the following, such designations of radio access networks will also be used to designate the underlying RAT. One type of event which may be reported in a mobile network implementing two or more of such RAT types may be a change of the RAT type used by the UE for connecting to the mobile network. Other events which may be reported are for example changes in the location of the UE. In such cases, for example a node referred to as Policy and Charging Rules Function (PCRF) may subscribe to reporting of such events by a node referred to as Policy and Charging Enforcement Function (PCEF). If the specified type of event is detected by the PCEF, the PCEF reports the event to the PCRF.
For certain control processes, the PCRF may obtain input information by subscribing to event reporting by the PCEF. For example, some policies applied by the PCRF may depend on whether the UE presently uses a specific RAT type, e.g., E-UTRAN, and therefore subscribe to reporting of RAT type changes by the PCEF. The reported RAT type change may at the same time also indicate the new RAT type. For example, establishing dedicated bearers may be supported only in E-UTRAN, and through reporting of RAT type changes the PCRF may become aware whether the UE uses E-UTRAN for accessing the mobile network or not. Based on this information, the PCRF may for example decide whether to initiate establishment of a new dedicated bearer (if the presently used access is E-UTRAN) or to modify an existing default bearer (if the presently used access is not E-UTRAN) so as to provide a desired Quality of Service (QoS) for data traffic to or from the UE.
However, the above way of learning about the current status of the UE through reported events may in some cases be inefficient or even not possible. For example, in some scenarios there may be a large amount of handovers between GERAN and UTRAN, e.g., if a high load in the UMTS network part or certain environmental factors, e.g., dense buildings, cause temporal or local variations in UMTS coverage.
Accordingly, there is a need for techniques which allow for efficiently reporting events in a mobile telecommunications network.
According to an embodiment of the invention, a method of event reporting between a first node and a second node of a mobile telecommunications network is provided. According to the method, the first node receives an indication from the second node. The indication specifies that a change in type of RAT used by a UE for connecting to the telecommunications network is to be reported from the first node to the second node. Further, the first node receives additional information from the second node. The additional information specifies at least one type of RAT. In response to the first node detecting a change of the UE to or from said at least one type of RAT, the first node sends a report of the detected change in type of RAT to the second node.
According to a further embodiment of the invention, a method of event reporting between a first node and a second node of a mobile telecommunications network is provided. According to the method, the second node sends an indication to the first node. The indication specifies that a change in type of RAT used by a UE for connecting to the telecommunications network is to be reported from the first node to the second node. Further, the second node sends additional information to the first node. The additional information specifies at least one type of RAT. In response to a change of the UE to or from said at least one type of RAT, the second node receives a report of the detected change in type of RAT from the first node.
According to a further embodiment of the invention, a method of event reporting between a first node and a second node of a mobile telecommunications network is provided. According to the method, the first node receives a first information element from the second node. The first information element specifies a type of an event which is to be reported from the first node to the second node. Further, the first node receives a second information element from the second node. The second information element comprises additional information for specifying a subtype of the event to be reported. The second information element is associated with the first information element by comprising an indication of the type of event specified in the first information element. In response to the first node detecting the event of said type and subtype, the first node sends a report of the detected event to the second node.
According to a further embodiment of the invention, a method of event reporting between a first node and a second node of a mobile telecommunications network is provided. According to the method, the second node sends a first information element to the first node. The first information element specifies a type of an event which is to be reported from the first node to the second node. Further, the second node sends a second information element to the first node. The second information element comprises additional information for specifying a subtype of the event to be reported. The second information element is associated with the first information element by comprising an indication of the type of event specified in the first information element. In response to the event of said type and subtype, the second node receives a report of the detected event from the first node.
According to a further embodiment of the invention, a node for a mobile telecommunications network is provided. The node comprises an interface with respect to a further node of the telecommunications network and a processor. The processor is configured to:
According to a further embodiment of the invention, a node for a mobile telecommunications network is provided. The node comprises an interface with respect to a further node of the telecommunications network and a processor. The processor is configured to:
According to a further embodiment of the invention, a node for a mobile telecommunications network is provided. The node comprises an interface with respect to a further node of the telecommunications network and a processor. The processor is configured to:
According to a further embodiment of the invention, a node for a mobile telecommunications network is provided. The node comprises an interface with respect to a further node of the telecommunications network and a processor. The processor is configured to:
According to a further embodiment of the invention, a system for event reporting in a mobile telecommunications network is provided. The system comprises a first node and a second node operating in accordance with one of the above methods.
According to a further embodiment of the invention, a computer program product is provided, e.g., in the form of a computer readable storage medium, the computer program product comprises computer readable program code that, when executed by a processor of a node of a mobile telecommunications network, causes the node to operate as the first node or second node of any of the above methods.
In the following, concepts in accordance with exemplary embodiments of the invention will be explained in more detail by to the accompanying drawings. The illustrated embodiments relate to concepts for traffic monitoring in a mobile network implementing different RAT types, e.g., 3GPP RAT types such as GERAN, UTRAN, and/or E-UTRAN. However, other RAT types could be used as well, including non-3GPP RAT types such as WLAN. The concepts in particular have the purpose of providing efficient reporting of events related to a UE connected to the mobile network.
The PCC architecture may also include a Traffic Detection Function (TDF) 46. The TDF 46 may be implemented as a stand-alone node, e.g., in a traffic monitoring device, with access to data traffic of the UE or may be co-located with a gateway routing the data packets to or from the UE. For example, the TDF 46 may be co-located in the same gateway with the PCEF 42.
Still further, the PCC architecture may include an Online Charging System (OCS) 62, and/or an Offline Charging System (OFCS) 64 which may be used for integrating online and offline charging processes.
As further illustrated, the PCC architecture may also include a repository 38. In the illustrated example, the repository 38 corresponds to a Subscriber Profile Repository (SPR). However, it is to be understood that other types of repository could be used as well, e.g., a User Data Repository (UDR). The repository 38, which may be a standalone database or integrated into an existing subscriber database such as a Home Subscriber Server (HSS), may include information such as entitlements, rate plans, etc. The repository 38 may provide subscription data such as a subscriber's allowed services, a pre-emption priority for each allowed service, information on a subscriber's QoS parameters, e.g., a subscribed guaranteed bandwidth QoS, a subscriber's charging related information, e.g., location information relevant for charging, a QoS related subscriber category, e.g., whether the subscriber is a gold user to be provided with a high QoS or a silver or bronze user to be provided with lower QoS.
The PCRF 30 may be configured to perform policy control decision and/or flow based charging control. The PCRF 30 may provide network control regarding detection of service data flow detection, gating, and/or QoS towards the PCEF 42 and/or BBERF 44. With respect to the PCEF 42, the PCRF 30 may also provide network control regarding flow based charging. The PCRF 30 may be responsible for managing individual policies defining network, application, and subscriber conditions that must be met in order to successfully deliver a service or maintain the QoS of a given service. For this purpose, the PCRF 30 may signal PCC rules to the PCEF 42 and/or may signal QoS rules to the BBERF 44.
In the illustrated implementation, the PCEF 42 may be responsible for enforcing policies with respect to authorization to access and services, accounting and mobility. Such policies may be provided by the PCRF through PCC rules. The PCEF 42 may be configured to perform service data flow detection, policy enforcement and flow based charging functionalities, which is typically accomplished by applying the PCC rules as signaled by the PCRF 30. Further, the PCEF 42 may also implement functionalities of packet inspection, such as Deep Packet Inspection (DPI), and service classification. In this way data packets may be classified according to PCC rules defined in the PCEF 42 and be assigned to a certain service. The BBERF 44 may provide similar functionalities as the PCEF 42 by enforcing the QoS rules signaled by the PCRF 30. However, flow based charging and DPI are typically not supported by the BBERF 44.
Basic functionalities of the TDF 46 may include monitoring the data traffic of a UE so as to detect usage of specific services. This monitoring may for example be based on DPI. Here, DPI may include inspection and analysis of data packet content and service classification based on said analysis. This may be accomplished on the basis of a configured tree of classification rules, e.g., provided by the PCRF 30 through ADC rules. The TDF 46 allows for defining policies with regard to the detected services. Further details of the TDF 46 may be as described in 3GPP TS 23.203.
As further illustrated in
In the above PCC architecture, reporting of events between nodes may be supported. For example, the PCRF 30 may subscribe to event reporting at the PCEF 42, using the Gx interface. Similarly, the PCRF 30 may subscribe to event reporting by the BBERF 44, using the Gxx reference point. Still further, the AF 50 may subscribe to event reporting by the PCRF 30, using the Rx interface. Moreover, the TDF 46 may subscribe to event reporting by the PCRF 30, using the Sd interface. In each case, the node subscribing to the event reporting at another node will send an indication of the type of event to be reported to the other node, and the other node will return a report if an event of the specified type occurs. An exemplary type of event to be reported is a change of RAT type. The latter type of event may for example be useful if certain control operations performed by the subscribing node depend on the presently utilized RAT type. On the other hand, event reporting may cause significant load on the participating nodes and the interface therebetween.
For example, in some scenarios the PCRF 30 may perform policy decisions on the basis of the RAT type presently used by a UE for connecting to the telecommunications network, e.g., when providing PCC rules to the PCEF 42. The PCRF 30 may therefore subscribe at the PCEF 42 to reporting of changes in the RAT type used by the UE. In this way, the PCRF 30 may become aware of the presently utilized RAT type. However, if there are frequent changes of RAT type, this may also cause significant load on the Gx interface, the PCEF 42, and in particular the PCRF 30. To address such issues, concepts according to embodiments of the invention as described in the following utilize that the PCRF 30 may only need to be aware of a certain RAT type being utilized, e.g., E-UTRAN, to apply the corresponding policies, so that not all RAT type changes, but only changes to or from this certain RAT type are relevant.
For example, in those scenarios where dedicated bearers are only supported in LTE, i.e., for E-UTRAN accesses, the PCRF 30 may be interested in RAT type changes from any RAT type to E-UTRAN and vice-versa in order to perform a policy decision on the establishment of a dedicated bearer. Such policy decision could for example result in establishing a dedicated bearer if the UE starts using a given service and the utilized RAT type is E-UTRAN or alternatively to modify the QoS of a default bearer if the UE uses another RAT type, e.g., UTRAN access or GERAN.
In the following, mechanisms will be further described which allow for implementing event reporting in an efficient manner by supporting selective reporting of a subtype of a given event type. For example, such mechanisms may be used for reporting only changes to or from a certain RAT type, e.g., to or from E-UTRAN. In this way, the load on the nodes involved in the event reporting may be reduced significantly. In the following, this mechanism will be illustrated by referring to the reporting of a change in RAT type between the PCEF 42 and the PCRF 30, using the Gx interface. However, it should be understood that the illustrated mechanism may be applied in a corresponding manner to the reporting of other event types, e.g., a change in the Public Land Mobile Network (PLMN) used by the UE, a change of the time zone in which the UE is located, a change in the location of the UE, or the like. Further, the mechanism could also be applied in a corresponding manner between other nodes, e.g., for reporting of events from the BBERF 44 to the PCRF 30, using the Gxx interface, for reporting of events from the PCRF 30 to the AF 50, using the Rx interface, and/or for reporting of events from the PCRF 30 to the TDF 46, using the Sd interface.
According to the illustrated mechanism, the PCRF 30 may subscribe at the PCEF 42 to reporting of changes in the RAT type used by the UE. For this purpose, the PCRF 30 may indicate to the PCEF 42 that PCC rules shall be requested by the PCEF 42 when the RAT type used by the UE changes to or from a given RAT type, e.g., E-UTRAN. This is accomplished by providing the PCEF 42 not only with information on the type of the event to be reported, i.e., a change in the RAT type used by the UE, but also with additional information on a subtype of the event to be reported, e.g., by specifying one or more specific RAT types. The PCEF 42 may then selectively report events corresponding to the specified event type and subtype, e.g., only changes to or from a certain RAT type specified in the additional information, or changes between two RAT types specified in the additional information. In this way, the load on the PCEF 42, the Gx interface, and in particular the PCRF 30 may be significantly reduced as compared to reporting of all changes in the RAT type.
According to an exemplary implementation, the additional information may be provided in a corresponding Attribute Value Pair (AVP) of the Diameter based protocol on the Gx interface. The PCRF 30 may optionally include this AVP into a protocol message to the PCEF 42 if selective reporting of only a certain event subtype is needed. Examples of such protocol messages are illustrated in
As illustrated in
For example, if additional information for selectively reporting a subtype of RAT type changes are provided in the AVP “Event Trigger Information” 250, the subordinate AVP “Event Trigger” may indicate “RAT Change” and the additional information may be provided in one or more instances of the subordinate AVP “RAT Type”. If two instances of the subordinate AVP “RAT Type” are provided, this may indicate that changes between these two RAT types should be selectively reported. If additional information for selective reporting of a subtype of PLMN changes are provided in the AVP “Event Trigger Information” 250, the subordinate AVP “Event Trigger” may indicate “PLMN Change” and the additional information may be provided one or more instances of a subordinate AVP referred to as “3GPP-SGSN-MCC-MNC” to identify one or more specific PLMNs for which changes are to be reported in a selective manner. If additional information for selective reporting of a subtype of time zone changes are provided in the AVP “Event Trigger Information” 250, the subordinate AVP “Event Trigger” may indicate “UE Time Zone Change” and the additional information may be provided in one or more instances of a subordinate AVP referred to as “3GPP-MS-TimeZone” to identify one or more specific time zones for which changes are to be reported in a selective manner.
The AVP “Event Trigger Information” 250 may be sent from the PCRF 30 to the PCEF 42 to indicate that when the event included within the AVP “Event Trigger” is detected by the PCEF 42 and corresponds to the specified subtype, e.g., matches a RAT type as specified in one of the subordinate AVPs “RAT Type”, the PCEF 42 should notify the PCRF 30 by sending a report. Other RAT type changes would not be reported.
In the following, the above concepts will be further explained by referring to exemplary procedures as illustrated in
Initially, the UE 10 and the PGW 40 may transmit messages 401 for initiating IP-CAN session establishment. The PGW 40 may then proceed by sending message 402 to the PCRF 30 so as to request authorization of the IP-CAN session. Message 402 may also indicate the RAT type currently used by the UE 10. In the illustrated example, this RAT type is assumed to be E-UTRAN. Message 402 may be an initial Credit Control Request (CCR) message of the Diameter based protocol on the Gx interface. The PCRF 30 may respond to the PGW 40 with message 403, so as to indicate whether the IP-CAN session is authorized. Message 403 may be an initial CCA message of the Diameter based protocol on the Gx interface.
As explained in connection with
Step 404 indicates a handover of the UE 10 from E-UTRAN to UTRAN. Since this handover corresponds to a change to or from the RAT type specified in message 403, the PGW 40 detects the RAT type change as event to be reported and sends message 405 to the PCRF 30. Message 405 may be an update CCR message of the Diameter based protocol on the Gx interface. Message 405 may report the change in RAT type by including the AVP “Event Trigger” with value “RAT Type” and the AVP “RAT Type” with value “UTRAN” to indicate that the new RAT type is UTRAN. In this way, the PCRF 30 becomes aware that the UE 10 now using UTRAN for connecting to the telecommunications network. The PCRF 30 may use this information for performing a policy decision. For example, the PCRF 30 may decide to remove or otherwise modify a previously installed PCC rule, e.g., as installed with message 403. The PCRF 30 may indicate the policy decision to the PGW 40 by sending message 406 to the PGW 40. Message 406 may be an update CCA message of the Diameter based protocol on the Gx interface. For example, message 406 may request removal or other modification of the PCC rule installed with message 403, e.g., because this PCC rule is not applicable for other RAT types than E-UTRAN.
Step 407 indicates a further handover of the UE 10 from UTRAN to GERAN. Since this handover does not correspond to a change to or from the RAT type specified in message 403, the PGW 40 does not detect the RAT type change as event to be reported and does send a report to the PCRF 30.
Step 408 indicates a still further handover of the UE 10 from GERAN to E-UTRAN. Since this handover corresponds to a change to or from the RAT type specified in message 403, the PGW 40 detects the RAT type change as event to be reported and sends message 409 to the PCRF 30. Message 409 may be an update CCR message of the Diameter based protocol on the Gx interface. Message 409 may report the change in RAT type by including the AVP “Event Trigger” with value “RAT Type” and the AVP “RAT Type” with value “E-UTRAN” to indicate that the new RAT type is E-UTRAN. In this way, the PCRF 30 becomes aware that the UE 10 now uses E-UTRAN for connecting to the telecommunications network. The PCRF 30 may use this information for performing a further policy decision. For example, the PCRF 30 may decide to install or configure a PCC rule in the PGW 40, e.g., to configurw a dedicated bearer between the UE 10 and the PGW 40 with certain QoS parameters. The PCRF 30 may indicate the policy decision to the PGW 40 by sending message 410 to the PGW 40. Message 410 may be an update CCA message of the Diameter based protocol on the Gx interface.
As can be seen, the selective reporting allows for avoiding event reports conveying information not needed at the PCRF 30. It should also be understood that procedures which are similar to those as illustrated in
At step 510, the first node receives an indication from the second node. The indication specifies a type of an event which is to be reported from the first node to the second node. The event type may for example be a change in RAT type used by the UE for connecting to the telecommunications network, a change of the PLMN used by the UE for connecting to the telecommunications network, a change in the time zone in which the UE is located, or a change in the location of the UE, e.g., a cell change, a change of Routing Area (RA), or a change of Service Area (SA). Other types of events are possible as well, e.g., as specified in 3GPP TS 23.203, 29.212, or 29.214. For example, this indication may be received in a message of a Diameter based protocol. The indication may be included in a corresponding information element, e.g., in an AVP.
At step 520, the first node receives additional information from the second node. The additional information has the purpose of specifying a subtype of the event to be reported. In particular, if the type of event to be reported is a change in RAT type, the additional information may specify at least one RAT type. The subtype of the event may then be a change to or from this specific RAT type. If the additional information specifies two RAT types, the subtype of the event may be a change between these two RAT type. If the type of event to be reported is a change of PLMN, the additional information may specify at least one PLMN, e.g., by using an identifier of the PLMN such as the Mobile Country Code (MCC) and Mobile Network Code (MNC). The subtype of the event may then be a change to or from this specific PLMN. If the additional information specifies two PLMNs, the subtype of the event may be a change between these two PLMNs. If the type of event to be reported is a change of time zone, the additional information may specify at least one time zone, e.g., in terms of a time zone identifier and/or an offset from Coordinated Universal Time (UTC). The subtype of the event may then be a change to or from this specific time zone. If the additional information specifies two time zones, the subtype of the event may be a change between these two time zones. If the type of event to be reported is a change in location, the additional information may specify at least one area, e.g., in terms of a Cell Global Identifier (CGI), a Routing Area Identifier (RAI), or a Service Area Identifier (SAD. The subtype of the event may then be a change to or from this specific area. If the additional information specifies two areas, the subtype of the event may be a change between these two areas.
The additional information may be included in a second information element which is associated with the above-mentioned first information element by including an indication of the type of event specified in the first information element. The second information element may be a further AVP. The second information element, or more generally the additional information, may be included in a message of a Diameter based protocol, e.g., in the same message as mentioned in connection with step 510.
At step 530, the first node detects an event. At step 540, the first node checks whether the event corresponds to the event type specified by the indication of step 510 and to the subtype specified by the additional information, i.e., whether the detected event matches the additional information. If this is the case, the event is detected as event of the specified event type and subtype and the method may proceed with step 550, as indicated by branch “Y”.
At step 550, in response to detecting the event of the specified event type and subtype, the first node sends a report of the detected event to the second node. This may be accomplished in a message of a Diameter based protocol. The report may indicate that an event of the specified event type and specified subtype occurred. Further, the report may also include further information on the detected event. For example, if the detected event is a change in RAT type, the report may indicate the new RAT type after the change. If the detected event is a change of PLMN, the report may indicate the new PLMN after the change. If the detected event is a change of time zone, the report may indicate the new time zone after the change. If the detected event is a change in location, the report may indicate the new location after the change.
If the check of step 540 reveals that the event does not correspond to the specified event type and subtype the method may proceed with step 560, as indicated by branch “N”. In this case, as illustrated by step 560, the first node does not send a report of the detected event.
As can be seen, the method of
At step 610, the second node sends an indication to the first node. The indication specifies a type of an event which is to be reported from the first node to the second node. The event type may for example be a change in RAT type used by the UE for connecting to the telecommunications network, a change of the PLMN used by the UE for connecting to the telecommunications network, a change in the time zone in which the UE is located, or a change in the location of the UE, e.g., a cell change, a change of RA, or a change of SA. Other types of events are possible as well, e.g., as specified in 3GPP TS 23.203, 29.212, or 29.214. For example, this indication may be received in a message of a Diameter based protocol. The indication may be included in a corresponding information element, e.g., in an AVP.
At step 620, the second node sends additional information to the second node. The additional information has the purpose of specifying a subtype of the event to be reported. In particular, if the type of event to be reported is a change in RAT type, the additional information may specify at least one RAT type. The subtype of the event may then be a change to or from this specific RAT type. If the additional information specifies two RAT types, the subtype of the event may be a change between these two RAT type. If the type of event to be reported is a change of PLMN, the additional information may specify at least one PLMN, e.g., by using an identifier of the PLMN such as the MCC and MNC. The subtype of the event may then be a change to or from this specific PLMN. If the additional information specifies two PLMNs, the subtype of the event may be a change between these two PLMNs. If the type of event to be reported is a change of time zone, the additional information may specify at least one time zone, e.g., in terms of a time zone identifier and/or an offset from UTC. The subtype of the event may then be a change to or from this specific time zone. If the additional information specifies two time zones, the subtype of the event may be a change between these two time zones. If the type of event to be reported is a change in location, the additional information may specify at least one area, e.g., in terms of a CGI, a RAI, or a SAI. The subtype of the event may then be a change to or from this specific area. If the additional information specifies two areas, the subtype of the event may be a change between these two areas.
The additional information may be included in a second information element which is associated with the above-mentioned first information element by including an indication of the type of event specified in the first information element. The second information element may be a further AVP. The second information element, or more generally the additional information, may be included in a message of a Diameter based protocol, e.g., in the same message as mentioned in connection with step 610.
At step 630, in response to an event of the event type specified by the indication of step 610 and of the subtype specified by the additional information, the second node receives a report of the detected event from the first node. This may be accomplished in a message of a Diameter based protocol. The report may indicate that an event of the indicated event type and specified subtype occurred. Further, the report may also include further information on the detected event. For example, if the detected event is a change in RAT type, the report may indicate the new RAT type after the change. If the detected event is a change of PLMN, the report may indicate the new PLMN after the change. If the detected event is a change of time zone, the report may indicate the new time zone after the change. If the detected event is a change in location, the report may indicate the new location after the change.
As can be seen, the methods of
As illustrated, the node may include a first interface 720 and a second interface 730. The first interface 720 may be associated with typical functionalities of the node, e.g., control functionalities or traffic processing functionalities. For example, if the node implements the PCRF 30, the first interface 720 may correspond to one of the above-described interfaces of the PCRF 30, e.g., the Rx interface, the Gx interface, the Gxx interface, the Sd interface, the Sy interface, or the Sp interface. If the node implements the AF 50, the first interface 720 may correspond to an interface for application layer signaling. If the node implements the TDF 46, the first interface 720 may correspond to an interface for receiving, and optionally also forwarding, user plane data traffic monitored by the TDF 46. The second interface 730 may be used for implementing the event reporting functionalities as described herein, i.e., for sending the indication of the event type to be reported and additional information, and also for receiving the report of the detected event. For example, if the node implements the PCRF 30, the second interface 730 may correspond to the Gx interface or to the Gxx interface. If the node implements the AF 50, the second interface 730 may correspond to the Rx interface. If the node implements the TDF 46, the second interface 730 may correspond to the Sd interface.
Further, the node includes a processor 750 coupled to the interfaces 720, 730 and a memory 760 coupled to the processor 750. The memory 760 may include a read-only memory (ROM), e.g., a flash ROM, a random-access memory (RAM), e.g., a Dynamic RAM (DRAM) or static RAM (SRAM), a mass storage, e.g., a hard disk or solid state disk, or the like. The memory 760 includes suitably configured program code to be executed by the processor 750 so as to implement the above-described functionalities of the subscribing node. More specifically, the memory 760 may include an event reporting control module 770 so as to implement the above-described functionalities for subscribing to event reporting at a further node and providing the additional information for selectively controlling the event reporting. Further, the memory 760 may also include a control module 780 for implementing general control functionalities of the node. Such control functionalities may in particular involve receiving one or more reports of a detected event from the further node.
It is to be understood that the structure as illustrated in
As illustrated, the node may include a first interface 820 and a second interface 830. The first interface 820 may be associated with typical functionalities of the node, e.g., control functionalities or traffic processing functionalities. For example, if the node implements the PCEF 42 or BBERF 44, the first interface 820 may correspond to an interface for receiving and forwarding user plane data traffic of a UE. If the node implements the PCRF 30, the first interface 720 may correspond to one of the above-described interfaces of the PCRF 30, e.g., the Rx interface, the Gx interface, the Gxx interface, the Sd interface, the Sy interface, or the Sp interface. The second interface 830 may be used for implementing the event reporting functionalities as described herein, i.e., for receiving the indication of the event type to be reported and additional information, and also for sending the report of the detected event. For example, if the node implements the PCEF 42, the second interface 830 may correspond to the Gx interface. If the node implements the BBERF 44, the second interface 830 may correspond to the Gxx interface. If the node implements the PCRF 30, the second interface 830 may correspond to the Rx interface or to the Sd interface.
Further, the node includes a processor 850 coupled to the interfaces 820, 830 and a memory 860 coupled to the processor 850. The memory 860 may include a ROM, e.g., a flash ROM, a RAM, e.g., a DRAM or SRAM, a mass storage, e.g., a hard disk or solid state disk, or the like. The memory 860 includes suitably configured program code to be executed by the processor 850 so as to implement the above-described functionalities of the reporting node. More specifically, the memory 860 may include a event reporting control module 870 so as to implement the above-described functionalities for selective event reporting on the basis of an event type and additional information specifying an event subtype as provided by a further node. Further, the memory 860 may also include a control module 880 for implementing general control functionalities of the node.
It is to be understood that the structure as illustrated in
As can be seen, the concepts as described above may be used for implementing event reporting in an efficient manner. In particular, the concepts may be used for applying event reporting also with respect to frequently occurring event types.
It is to be understood that the examples and embodiments as explained above are merely illustrative and susceptible to various modifications. For example, the concepts as described herein could be used in various types of telecommunications networks, e.g., combining different types of access technology, including non-cellular broadband access technology. Further, it should be noted that in some implementations of the a node may act both as a subscribing node and a reporting node. For example, the PCRF 30 may subscribe to event reporting by the PCEF 42 or BBERF 44 while at the same time selectively reporting events to the AF 50 or TDF 46. Moreover, it is to be understood that the above concepts may be implemented by using correspondingly designed software to be executed by a processor of an existing device, or by using dedicated device hardware. Still further, it is to be understood that the above-mentioned nodes such as the AF 50, PCRF 30, PCEF 42, BBERF 44, or TDF 46 may each be implemented by a single device or by multiple devices, e.g., by a device cloud or the like.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2012/074815 | 12/7/2012 | WO | 00 |
