Patent Application
20150236914
The present invention relates to a method and a node for controlling resources for a media service in a policy and charging system of a communication network as well as to a corresponding system and computer program, and in particular to a method for controlling resources for a media service carried out by a network node including a policy and charging rules function obtaining information from another node including a policy and charging enforcement function and/or traffic detection function.
In communication networks, such as telecommunication networks, a call or a service often involves, on the one hand, a control plane or signalling plane and, on the other hand, a user plane or media plane. The control plane or signalling plane is in charge of establishing and managing a connection between two points of the network. The user plane or media plane is in charge of transporting user data or service data.
Network operators have the desire to define and enforce a set of rules in the network. A set of rules constitutes policies. A policy framework for managing and enforcing these policies usually includes at least three elements or functions: a policy repository for storing policy rules, which may be user-specific, a policy decision element or function and a policy enforcement element or function. The purpose of a policy framework includes controlling subscriber access to networks and services as well as the kind of access, i.e. its characteristics.
A policy framework notably addresses the decisions as to whether the subscriber is entitled, or authorized, to enjoy a service, and whether the network can provide the service to the subscriber, and particularly whether the network can provide the service to the subscriber with the desired Quality of Service (QoS).
Policy and charging control architectures, such as, but not limited to, the architecture described in 3GPP TS 23.203 version 11.1.0 (2011-03), Technical Specification Group Services and System Aspects; Policy and charging control architecture (release 11) (available on http://www.3gpp.org/ftp/Specs/2011-03/Rel-11/23_series/), integrate policy and charging control.
One aim of a policy framework is to set up and enforce rules dependent on subscribers and/or desired services to ensure efficient usage of network resources among all subscribers.
An architecture that supports Policy and Charging Control (PCC) functionality is depicted in
The PCRF shall provision PCC Rules to the PCEF via the Gx reference point and may provision QoS Rules to the Bearer Binding and Event Reporting Function (BBERF) 130 via the S7x reference point.
In the architecture 100 of
The Gx reference point is defined in 3GPP TS 29.212 “Policy and charging control over Gx reference point”, and lies between the PCRF and the PCEF. The Gx reference point is used for provisioning and removal of PCC Rules from the PCRF to the PCEF and the transmission of traffic plane events from the PCEF to the PCRF. The Gx reference point can be used for charging control, policy control or both.
The Rx reference point is defined in 3GPP TS 29.214 “Policy and charging control over Rx reference point” and is used to exchange application level session information between the PCRF and the AF. An example of a PCRF is the Ericsson Service-Aware Policy Controller (SAPC), see for example F. Castro et al., “SAPC: Ericsson's Convergent Policy Controller”, Ericsson review No. 1, 2010, pp. 4-9. An example of an AF is the IP Multi-Media Subsystem (IMS) Proxy Call Session Control Function (P-CSCF).
The Sd reference point in
Both Gx and Rx reference points may be based on Diameter, see for example P. Calhoun et al., “RFC 3588: Diameter Based Protocol”, IETF, September 2003.
The PCEF enforces policy decisions received from the PCRF and also provides the PCRF with user- and access-specific information over the Gx reference point. The node including the PCEF or another Bearer Binding Function (BBF) encompasses SDF detection based on filter definitions included in the PCC Rules, as well as online and offline charging interactions (not described here) and policy enforcement. Since the PCEF is usually the one handling bearers, it is where the QoS is being enforced for the bearer according to the QoS information coming from the PCRF. This functional entity, i.e. the PCEF, is located at the Gateway, e.g. in the Gateway GPRS Support Node (GGSN), in the GPRS case. For all the cases where there is Proxy Mobile IP (PMIP) or Dual-Stack Mobile IP (DSMIP) in the core network, the bearer control is performed in the BBERF instead.
The Application Function (AF) 140 is an element offering applications in which service is delivered in a different layer, e.g. transport layer, from the one the service has been requested, e.g. signalling layer. One example of a network node including an AF 140 is the P-CSCF (Proxy-Call Session Control Function) of the IP multi-media (IM) core network (CN) sub-system. The AF 140 may communicate with the PCEF 110 to transfer dynamic session information, i.e. description of multi-media to be delivered in the transport layer. This communication is performed using the above-described Rx interface or Rx reference point, which is placed between the PCEF 110 and AF 140. Information in the Rx interface may be derived from the session information or service session information in the P-CSCF and it mainly includes what is called media components. Another example of a network node including an AF 140 is a streaming server.
Upon reception of the PCC/QoS rules from the PCRF, a Bearer Binding Function (BBF), either the PCEF 120 or the BBERF 130 depending on the deployment scenario, performs the bearer binding, i.e. associates the provided rule to an IP-CAN bearer within an IP-CAN (Internet Protocol Connectivity Access Network) session. The BBF will use the QoS parameters provided by the PCRF to create the bearer binding for the rule.
Next, PCC support to applications is described. When an application requires dynamic policy and/or charging control over the IP-CAN user plane to start a service session, the AF will communicate with the PCRF to transfer the dynamic session information required for the PCRF to take the appropriate actions on the IP-CAN network. The PCRF will authorize the session information, create the corresponding PCC/QoS rules and install them in the PCEF/BBERF. The PCEF/BBERF will encompass SDF detection, policy enforcement (gate and QoS enforcement) and flow based charging functionalities. As described, the applicable bearer will be initiated/modified and if required, resources will be reserved for that application.
The Traffic Detection Function (TDF) 160 is a functional entity that performs application detection and reporting of detected application or service and its service data flow description to the PCRF. The TDF can act in solicited mode, i.e. upon request from the PCRF, or unsolicited mode, i.e. without any request from the PCRF.
Next, PCC support for service awareness functionality is described. 3GPP release 11 has introduced a new entity in the PCC architecture, namely the above-mentioned TDF, that is a Deep Packet Inspection (DPI) box that monitors the payload and detects when an application is initiated/terminated. This functionality can also reside in the PCEF. In detail, DPI technology supports packet inspection and service classification, which consists of IP-packets classified according to a configured tree of rules so that they are assigned to a particular service session. DPI has been standardized in 3GPP release 11, the mentioned so-called traffic detection function (TDF), which can be either standalone or collocated with the PCEF which is discussed in detail in 3GPP TR 23.813. The reference point (Sd) has been defined between the stand-alone TDF and the PCRF.
Due to exponential growth in usage in mobile broadband networks, operators are very interested in offering subscriber packages which optimize the network resources without affecting the customer experience. Thereby, one approach could be to create rules that enforce certain policies decided by the PCRF to control network resources.
Multi-media related services (in the following called media services), and especially video and/or audio streaming, are already and are forecasted to be the most demanded services during the coming years. Those media services are very demanding from a QoS perspective and specifically require a lot of bandwidth from the operator's network.
With respect to media services, there are big differences in the requirements of the terminals in terms of bandwidth. For example, a smartphone of the first generation with a small screen size may require much less bandwidth than a laptop with mobile communication capabilities. There is currently no mechanism defined in the 3GPP PCC architecture in order to deliver custom-tailored video content required for a terminal.
It is thus desirable to provide methods, nodes, a system and a computer program to optimize resource allocation in a network.
A suitable method, node, a system and a computer program are defined in the independent claims. Advantageous embodiments are defined in the dependent claims.
In one embodiment, a method of controlling resources for a media service in a policy and charging system of a communication network comprises the steps of obtaining, at a network node, identification information for identifying at least one of a user and a user terminal; and determining at least one device parameter using said identification information. The device parameter is associated with a device selected to receive media data of said media service. Further, the method comprises selecting according to said at least one device parameter a policy which is to be applied for said media service. Accordingly, a policy can be selected depending on the device parameter, such as a device type or subscriber package, which takes into account the specific requirements and desires of a user operating a mobile terminal or other device that is capable of receiving mobile communication data directly or through a mobile terminal. As a result, since the network is aware of the device parameter, it is possible to deliver media content tailored, e.g. in terms of bandwidth, to the user.
In one embodiment, a node is provided for controlling resources for a media service in a policy and charging system of a communication network. The node comprises an ID obtainer configured to obtain identification information for identifying at least one of a user and a user terminal; a determiner configured to determine at least one device parameter using said identification information, which parameter is associated with a device selected to receive media data of said media service; and a policy selector configured to select according to said at ea one device parameter a policy which is to be applied for aid media service.
In another embodiment, a system is provided comprising the above-described elements of the node, namely the ID obtainer, the determiner, and the policy selector as well as a rule receiver and a policy enforcer.
In another embodiment, a computer program is provided which includes instructions configured, when executed on a data processor, to cause the data processor to carry out the above-described method.
Further, advantageous embodiments of the invention are disclosed in the dependent claims.
a illustrates a standalone TDF.
b illustrates a TDF collocated with a PCEF.
Further embodiments of the invention are described with reference to the figures. It is noted that the following description contains examples only and should not be construed as limiting the invention.
In the following, similar or same reference signs indicate similar or same elements or operations.
For example, the policy and charging system of the communication network comprises the above-mentioned node including the PCRF as well as a node including the above-mentioned Traffic Detection Function (TDF) collocated with a node including the above-mentioned Policy and Charging Enforcement Function (PCEF) or a standalone TDF.
As can be seen in
For example, at user session establishment, the TDF/PCEF node conveys to the PCRF node the subscriber identity, such as IMSI or MSISDN, as identification information for the user. Additionally or alternatively, user equipment information, such as the IMEI, may also be conveyed to the PCRF node providing identification information for identifying a user terminal. Surely, it is also possible to derive the subscriber identity from the user equipment information or vice versa, if a database is provided which maps user equipment information to a subscriber identity.
In step 220, a device parameter, such as a device type or subscriber package is determined using the identification information, e.g. IMEI, IMSI and/or MSISDN. The device type may indicate whether the device is a conventional mobile phone, smartphone, tablet computer or other device, such as a television. The subscriber package gives information about the user's subscription with the network provider, for example whether the user is allowed to receive multi-media content over IP and the associated bandwidth which can be allocated to him/her.
The device parameter is associated with the device which is selected to receive and reproduce media data of the media service requested by the user. The device may be the above-mentioned user terminal, in particular a mobile phone like known conventional mobile phones or smartphones, but is not limited thereto. For example, the device may also be any other media reproduction device that is connectable to the user terminal. In such a setup the user terminal would then act as a modem connecting to the mobile communication network and providing the media reproduction device with the desired media data. For example, the media reproduction device may be a high-definition (HD) television set with a large screen requiring a higher bandwidth for video reproduction and display than a conventional mobile phone.
Therefore, a subscription, i.e. subscription package, can relate to requirements for QoS, in particular bandwidth, which requirements may be different to the user terminal connected to the communication network and receiving the media data, since the terminal can also act as a modem for a flat screen device with HD resolution, for example. In the case, in which the user terminal acts as a modem, the bandwidth required by the user terminal would be higher than usually needed by the user terminal, since it has to provide the media data to the media reproduction device.
However, in most cases the user terminal receiving media data is also the same device reproducing the media data. The device parameter may be obtained by consulting a database in which identification information is associated with a device parameter, which will be explained in more detail further below.
Further, in step 230 a policy associated with a PCC or ADC rule(s) is selected according to the device parameter determined in step 220. The selected policy is then applied for the media service based on the subscriber package and/or device type so that a QoS can be selected to be applied for different devices. In detail, a PCC/ADC rule is generated associated with the policy and then provided to the PCEF node or TDF node.
Accordingly, network resources can be optimized and distributed according to different subscriber packages and/or devices used without affecting user experience. Additionally, the user may also be enabled to share a connection for multiple multi-media streams, in particular video streams, in parallel depending on the user's subscriber package at the network operator. For example, a base subscriber package would only allow one simultaneous video stream to protect network resources, and if a user desires to share the connection for multiple video streams, a different subscriber package may be obtained.
As mentioned above, the subscription may not be limited to the user terminal connected to the communication network but a subscription for high bandwidth can be obtained so that the user terminal may be used as a modem to be connected to a flat screen display with a much larger size.
The example discussed with respect to
As can be seen in
This identification information is then forwarded from PCEF 320 to PCRF 330, as shown in
For the case of video related subscriber packages, the retrieved video subscriber package can be at least one of the following: basic video package, tablet video package, laptop video package, HD video package, simultaneous video instances package. Based on the received identification information, in particular user equipment information, PCRF retrieves the device type from database 350 which may include a separate IMEI database. The retrieved device type is associated with a smartphone, tablet computer, laptop, etc., for example. Accordingly, one or more device parameters can be retrieved from a database such as an SPR, based on identification information so that the one or more determined device parameters can be used to select a policy or policies.
The subscriber package or device type, which are examples of the above described device parameters, are then forwarded from database 350 to PCRF 330, which selects according to at least one device parameter, e.g. the device type or subscriber package, a policy to be applied for the media service, such as video streaming. Accordingly, a device parameter may represent a device type for or associated with identification information identifying the user terminal and another device parameter may represent a subscriber package for or associated with identification information when this information can be used to identify a user.
In detail, depending on the subscriber package applicable for the user and/or the device type, the PCRF selects the appropriate policy and generates the appropriate PCC/ADC rule(s) to be applied for the media service, e.g. regarding which QoS is allowed and thus to be applied. For example, different QoS are to be applied for a smartphone having a screen size of 4″ requiring a video bandwidth of approximately 0.4 Mbps, a tablet computer having a screen size of 10″ requiring a video bandwidth of approximately 0.7 Mbps or a laptop computer having a screen size of 14″ requiring a video bandwidth of approximately 1.5 Mbps.
As can be seen in
The skilled person understands that more than one rule can be generated based on different selected policies for one user, wherein the policy is selected depending on the device type and/or the subscriber package, thus represented by a first and/or second device parameter. Further, instead of or in addition to providing a rule associated with a selected policy to the PCEF/TDF 320, the device parameter may be provided to this node directly. For example, the device parameter, in particular, the device type may be included in a charging report which can be sent to an online charging and billing system or the PCRF. Therefore, in some cases it may be useful to pass the device parameter to the PCEF/TDF node in a proprietary Device-Type AVP (Attribute Value Pair), based on PCRF configured policies which may also depend on other retrieved information, e.g. user location or user roaming status.
The PCEF/TDF node 320, upon reception of the device parameter from the PCRF node, can use it for charging and/or reporting, by including the proprietary Device-Type in the following:
During the user session, each time the user starts the media service, the TDF node including the DPI capabilities notifies to the PCRF node each individual video instance detected, for example in a new Instance-Id AVP. For example, when a user connects to a video server, e.g. HTTP based, and watches different videos either in parallel or in sequence in the same session (PDP context), the traffic for each video would be one service instance, here video service instance, whereas the service session comprises all traffic, i.e. different videos, between the UT and the video server during that connection. If the user closes the connection to the video server, e.g. closes a window, and connects again later, e.g. either keeping the general data connection or PDP context or by powering off the UT and powering it on again, another service session is created with other corresponding service instances. A service instance may simply be detected by URL hash by the TDF, i.e. each HTTP request/response transaction to a different URL is a different service instance, while all HTTP request/response transactions between the UT and video server for that connection correspond to the same service session.
In the following, examples of different policies are discussed. As mentioned above, the PCRF node selects the corresponding policy according to at least one device parameter. Preferably, the policy is selected according to two device parameters, namely the subscriber package and the device type.
For example, one policy may provide for the selection of a specific codec for a service instance so as to enable transcoding from one media format used by one node to another media format used by the media reproduction device, which is in most cases the same as the user terminal, as mentioned above. It is even possible that the PCRF provides a different codec to each service instance based on the subscription, e.g. high quality codec for the first video instance, and low quality codecs for subsequent video instances, in case the user uses them in parallel.
With a different subscription, there could be a case with no limitation on the codec quality and all instances use the high quality codec. As codecs several known codecs can be used, such as codecs supporting MPEG or HLS. This has the further advantage that a user terminal or media reproduction device does not have to support a large number of different codecs to be able to retrieve and view media data from different media video servers but if codec of a video server and codec of a user terminal should not correspond to each other, then the media format can be transcoded by the network, particularly by the TDF/PCEF node if it has transcoding capabilities. When the rule is provided to the PCEF/TDF node, it can be extended with codec information which constitutes a new enforcement action in PCC/ADC rules and details of new appropriately amended AVPs will be presented further below. Accordingly, the Gx interface can be enhanced with support of transcoding actions from the PCRF so that one format can be changed into another format.
A different policy provides for access control to allow a number of service instances to be established depending on the at least one device parameter. For example in a default case only a first service instance is allowed and in a case, in which the user subscribed to a subscriber package for simultaneous video instances, multiple service instances are allowed.
Another policy provides for adaptation of bandwidth for the first service instance or adaptation of bandwidth for additional service instances depending on the device parameter. In a simple example, the bandwidth may be adapted to the screen size of a device or not depending on both the device type and subscriber package. Accordingly, even if the device type indicates that a device with a large screen size and high resolution is used that usually requires a high bandwidth, the bandwidth could still be limited due to the user's subscriber package so as to prioritize other users with better, i.e. premium, subscriber packages when the overall bandwidth is limited.
In another example, in which the user has not subscribed to a subscriber package for simultaneous video instances, the bandwidth may be restricted for extra instances, while not restricting the bandwidth for the first instance.
A different policy may be related to a rating group selection to charge differently for each service instance.
Enforcing several other policies may be possible by implementing the above described functionality. In all cases, upon reception of a rule associated with the selected policy from the PORE node, the PCEF/TDF node enforces the policy accordingly. While in
The implementation of the above described functionality can be realized for an AF node with DPI capabilities, e.g. Ericsson's Service Aware Support Node (SASN), as part of a video enhancement feature. This may also impact on the PCRF, e.g. the SAPC which was discussed at the beginning of this document.
In the following different alternatives are proposed supporting the use cases described above. In detail, the idea of implementing an instance handling mechanism based on subscriber package and/or user terminal (device type) leads preferably to modification of the Gx, Sd and Rx interfaces to support passing codec information, device type, instance identifier, etc. to the PCEF/TDF/AF node, wherein the following three options will be discussed in detail below, namely a TDF collocated solution (Gx), standalone TDF solution (Sd) and AF based solution (Rx).
Before discussing implementation examples of these options in detail, it is referred to
In detail,
The ID obtainer 410 is configured to obtain identification information for identifying at least one of the user and a user terminal, whereas details about the identification information are provided above.
The determiner 420 is configured to determine at least one device parameter using the identification information, which parameter is associated with a device selected to receive media data of the media service. The device may be in the above described media reproduction device that can be the same device as the user terminal but is not limited thereto. Regarding the device parameter which is at least one of a subscriber package and device type, it is referred to the above explanation to avoid unnecessary repetition.
The policy selector 430 is configured to select, according to at least one device parameter, a policy which is to be applied for the media service. These described elements allow carrying out the functions previously described with respect to
Accordingly, the same advantages which are achieved with the above described method can also be achieved by the network node 400.
The system shown in
Similar to the network node 400, also the network node 550 may be a server comprising a processor to carry out at least some of the above described functions, in particular the functions described in
In the following the three options mentioned above, namely the TDF collocated solution, standalone TDF solution and AF based solution are described in detail with respect to
The IDE collocated solution applies to 3GPP Rel11 compliant TDF node collocated with the PCEF node, e.g. PDN gateway (PGW) with DPI capabilities. An example of such a collocation is shown in
The sequence depicted in
As seen in point 2 of
Once the PCRF node has received the appropriate identification information, it uses this information to retrieve the subscriber package, if available, and the device type from the external database 740.
Then, the PCRF node 730 selects a policy based on the subscriber package and the device type. Based on the above information and on PCRF configured policies, the PCRF node 730 conveys the proprietary Device-Type AVP, preferably including a codec, in the Gx CCA (Credit Control Answer) message to the node 720. Further, the appropriate ADC/PCC rules (both ADC rules and PCC rules are supported in collocated case) are generated and provided to the node 720, which is basically a PCEF/TDF node, in the Gx CCA initial message known from 3GPP release 11 so that the appropriate rule can be installed at node 720.
At a later stage, during the user session, each time the user starts the media service, the PCEHTDF node 720 notifies the PCRF node 730 in a proprietary Instance-Id AVP in the Gx CCR update message about each individual video instance detected by means of a 3GPP release 11 service event trigger, including not only the service identifier, e.g. video streaming, but also the video instance identifier, e.g. Instance-Id=1 (see point 9 in
The PCRF node 730 dynamically selects, according to the subscriber package and user equipment information, the corresponding policy and sends a rule generated based on the policy in a Gx CCA update message (see point 11 in
As mentioned several times before, upon reception of the rule associated with the selected policy from the PCRF node 730, the PCEF/TDF node 720 enforces the policy accordingly.
The remaining sequence steps in
In the following, the standalone TDF solution is described. This solution applies to 3GPP release 11 compliant standalone TDF node which supports the Sd reference point with the PCRF. A schematic drawing of the set-up and functional relationships of the nodes is shown in
Similar to the explanation of the flow diagram of
As explained before, the PCRF retrieves the subscriber package, if available, and the device type from one or more external databases. Based on the above information and on PCRF configured policies, the PCRF node selects the appropriate ADC (Application Detection and Control) rules to be installed in the standalone TDF for the media service, in this example video service, in the 3GPP release 11 Sd SER message and conveys the proprietary Device-Type AVP in the 3GPP release 11 Sd SER message.
Later on during the user session, each time the user starts the video service, the standalone TDF node notifies the PCRF node in a proprietary Instance-Id AVP in the Sd CCR update message of each individual video instance detected by means of a 3GPP release 11 service event trigger, including not only the service identifier, e.g. video streaming, but also the video instance identifier, e.g. Instance-Id=1. This implies the support of both video instance detection and notification through Sd reference point.
The PCRF node dynamically selects, according to the subscriber package and the user equipment information, the corresponding policy and sends the associated rule in a Sd CCA update message. In case the standalone TDF node has transcoding capabilities, Dynamic ADC rules can be extended with codec information to provide the new Codec-Information AVP in ADC-Rule-Definition, as follows:
Similar to the above-described examples, the standalone TDF node then enforces the policy accordingly after reception of the rule from the PCRF node.
In the following the AF based solution is described. This solution applies to an AF node with DPI capabilities, e.g. SASN, which supports the Rx interface with the PORE.
Similar to the above, at or after user session establishment, the PCRF node receives the subscriber identity (IMSI or MSISDN) and also the user equipment information (IMEI) from the PCEF node, e.g. PGW. Further, the PCRF node retrieves the video subscriber package, if available, and the device type from external databases, for example. Based on the above information and on PCRF configured policies, the PORE node conveys the proprietary Device-Type AVP to the PCEF/TDF node in the Gx CCA message.
Later on, during the user session, each time the user starts the video service, the AF node notifies the PCRF node in a proprietary Instance-Id AVP in the 3GPP Rx AAR message of each individual video instance detected, including not only the service identifier, e.g. AF-Application-Identifier set to video streaming, but also the video instance identifier, e.g. Instance-Id=1. This implies the support of both video instance detection and notification through the Rx interface.
The PCRF node dynamically selects, according to the subscriber package and user equipment information, the corresponding policy typically towards the PCEF node, e.g. by installing PCC rules on the PGW, but this may also be done towards the AF node, e.g. SASN has also enforcement capabilities as it supports the Ox protocol. In case the AF node has transcoding capabilities, it is possible to extend the Rx protocol with codec information and to provide a new Codec-Information AVP in Rx AAA message, as follows:
The PCEF node then enforces, upon reception of the policy from the PCRF node, the policy accordingly. In case of SASN, a Rx AAA response message indicating service not authorized results in dropping the package for that particular video instance.
According to the above, operators are enabled to support the provision of specific subscriber packages adapted to the device parameter, such as the device type, in order to optimize the network resources while not affecting user experience. Further, operators are enabled to support the provision of instance handling, allowing offering subscriber packages for simultaneous video instances or other multi-media instances for premium users.
Additionally, the above schemes enable to include the device type in the charging (online/offline) and reporting information, which provides more flexibility for the operator when offering certain services or subscriber packages as well as enable to pass codec information through Gx, Rx and Sd interfaces.
Processing unit 820 may include a processor, a microprocessor, or processing logic that may interpret and execute instructions. Main memory 830 may include a RAM or another type of dynamic storage device that may store information and instructions for execution by processing unit 820. For example, the determiner 420 and the policy selector 430 may be realized by the processing unit 820. ROM 840 may include a ROM device or another type of static storage device that may store static information and instructions for use by the processing unit. Storage device 850 may include a magnetic and/or optical recording medium and its corresponding drive.
The input device may include a mechanism that permits an operator to input information to network node 800, such as a keyboard, a mouse, a pen, voice recognition and/or biometric mechanisms, etc. Output device may include a mechanism that outputs information to the operator, including a display, a printer, a speaker, etc. Communication interface 860 may include any transceiver-like mechanism that enables network node 800 to communicate with other devices and/or systems. For example, communication interface 860 may include mechanisms for communicating with another device or system via a network, such as a communication network. In the above examples, the ID obtainer 410 may be realized by the communication interface 860.
Network node 800 may perform certain operations or processes described herein. Network node 800 may perform these operations in response to processing unit executing software instructions contained in a computer-readable medium, such as main memory 830, ROM 840, and/or storage device 850. A computer-readable medium may be defined as a physical or a logical memory device. For example, a logical memory device may include memory space within a single physical memory device or distributed across multiple physical memory devices. Each of the main memory, ROM and storage device may include computer-readable media with instructions as program code. The magnetic and/or optical recording media (e.g., readable CDs or DVDs) of the storage device may also include computer-readable media. The software instructions may be read into the main memory from another computer-readable medium, such as storage device 850, or from another device via communication interface 860.
The software instructions contained in main memory 830 may cause processing unit 820 including a data processor, when executed on the processing unit, to cause the data processor to perform operations or processes described herein. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes and/or operations described herein. Thus, implementations described herein are not limited to any specific combination of hardware and software.
The physical entities according to the different embodiments of the invention, including the elements, nodes and systems, may comprise or store computer programs including software instructions such that, when the computer programs are executed on the physical entities, steps and operations according to the embodiments of the invention are carried out, i.e. cause data processing means to carry out the operations. In particular, embodiments of the invention also relate to computer programs for carrying out the operations/steps according to the embodiments of the invention, and to any computer-readable medium storing the computer programs for carrying out the above-mentioned methods.
Where the terms obtainer, determiner, selector, forwarder, receiver, provider and enforcer are used, no restriction is made regarding how distributed these elements may be and regarding how gathered these elements may be. That is, the constituent elements of the nodes and systems may be distributed in different software and hardware components or other devices for bringing about the intended function. A plurality of distinct elements may also be gathered for providing the intended functionalities. For example, the elements/functions of the node may be realized by a microprocessor and a memory similar to
It will be apparent to those skilled in the art that various modifications and variations can be made in the entities and methods of this invention as well as in the construction of this invention without departing from the scope of spirit of the invention.
The invention has been described in relation to particular embodiments and examples which are intended in all aspects to be illustrative rather than restrictive. Those skilled in the art will appreciate that many different combinations of hardware, software and/or firmware will be suitable for practising the present invention.
Moreover, other implementations of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and the examples be considered as exemplary only, wherein abbreviations used in the above examples are listed below. To this end, it is to be understood that inventive aspects lie in less than all features of a single foregoing disclosed implementation or configuration. Thus, the true scope and spirit of the invention is indicated by the following claims.
TDF Traffic Detection Function
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2012/068425 | 9/19/2012 | WO | 00 |
