WO2012016327A1 - Procédé et système de génération de mesures représentatives du trafic de données ip à partir d'enregistrements de données ip - Google Patents

Procédé et système de génération de mesures représentatives du trafic de données ip à partir d'enregistrements de données ip Download PDF

Info

Publication number
WO2012016327A1
WO2012016327A1 PCT/CA2011/000877 CA2011000877W WO2012016327A1 WO 2012016327 A1 WO2012016327 A1 WO 2012016327A1 CA 2011000877 W CA2011000877 W CA 2011000877W WO 2012016327 A1 WO2012016327 A1 WO 2012016327A1
Authority
WO
WIPO (PCT)
Prior art keywords
traffic
data
dimension
representative
data records
Prior art date
Application number
PCT/CA2011/000877
Other languages
English (en)
Inventor
Jean-Philippe Goyet
Alexandre Hayon
Eric MÉLIN
Original Assignee
Neuralitic Systems
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Neuralitic Systems filed Critical Neuralitic Systems
Publication of WO2012016327A1 publication Critical patent/WO2012016327A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/142—Network analysis or design using statistical or mathematical methods
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/4508—Management of client data or end-user data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/535—Tracking the activity of the user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/564—Enhancement of application control based on intercepted application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N17/00—Diagnosis, testing or measuring for television systems or their details
    • H04N17/004—Diagnosis, testing or measuring for television systems or their details for digital television systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet

Definitions

  • a method and system are disclosed to generate metrics representative of IP data traffic from IP data records.
  • the method and system receives, at an analytic system, IP data records representative of the IP data traffic.
  • the method and system processes, at the analytic system, the IP data records from the perspective of at least one traffic dimension.
  • the processing comprises, for each at least one traffic dimension: extracting information representative of the traffic dimension from the IP data records, and using the extracted information to compute at least one measure representative of the traffic dimension.
  • the processing further comprises computing a metric, consisting of an aggregated value of the at least one measure representative of the traffic dimension against at least one traffic characteristic
  • the traffic dimensions comprise at least one of: protocols, data services, web domains, applications, and IP television (IPTV) channels.
  • IPTV IP television
  • a method and system are disclosed, wherein the measures comprise at least one of: a volume of data, a number of users, a number of sessions, a session duration, and a number of transactions.
  • Figure 1 illustrates an analytic framework for generating metrics representative of IP data traffic from IP data records, according to a non-restrictive illustrative embodiment
  • Figure 2 illustrates a system for generating metrics representative of IP data traffic from IP data records, according to a non- restrictive illustrative embodiment
  • Figure 3 illustrates a method for generating metrics representative of IP data traffic from IP data records, according to a non- restrictive illustrative embodiment.
  • IP data network to monitor and analyze the usage of the IP data services available to its subscribers via its IP based network infrastructure.
  • This is due to a combination of factors, including the variety of devices available to connect to the IP data network, the variety of applications and IP data services available via the IP based network infrastructure, the differences in terms of capacity and performance of the IP based network infrastructures, and the variety of usage patterns of the subscribers consuming IP data services.
  • This issue is applicable to any type of network Operator with an IP based network infrastructure, including for example: a mobile network Operator, a fixed broadband network Operator, a corporation operating its own network infrastructure.
  • it is becoming increasingly critical for a network Operator to have the capability to monitor and analyze the usage of the IP data services offered via its IP based network infrastructure.
  • IP data traffic generated on its IP based network infrastructure enables the network Operator to adjust its offerings, in terms of devices, data plans, IP data services, and network capacity. Having the proper offering is key in the competition between network Operators for subscribers' retention and Average Revenue Per User (ARPU) protection / development. Also, the cost of upgrading the IP based network infrastructure to sustain the growth in IP data services consumption shall be kept under control. Having comprehensive information on the IP data traffic enables the network Operator to upgrade its IP based network infrastructure in the most efficient way.
  • ARPU Average Revenue Per User
  • the scope of the information related to the IP data traffic on an IP based network infrastructure, available to a network Operator, is generally limited to a specific perspective.
  • the scope focuses on information related to the operating conditions of the IP data network (bandwidth usage, quality of service enforcement, network failures, user experience, etc).
  • the scope focuses on information related to the usage of a specific service (or class of service) delivered via the IP data network.
  • the variety of IP data traffic types, devices used, user types, and behaviors, are not taken into account via a comprehensive and coherent analytic framework.
  • the present method is adapted for generating metrics representative of IP data traffic from IP data records. For doing so, the method receives, at an analytic system, IP data records representative of IP data traffic on an IP network. The method processes, at the analytic system, the IP data records from the perspective of at least one traffic dimension.
  • the processing comprises for each at least one traffic dimension: extracting information representative of the traffic dimension from the IP data records, and using the extracted information to compute at least one measure representative of the traffic dimension.
  • the processing further comprises computing a metric, consisting of an aggregated value of the at least one measure representative of the traffic dimension against at least one traffic characteristic.
  • the present system is adapted for generating metrics representative of IP data traffic from IP data records.
  • the system comprises an analytic system for receiving IP data records representative of IP data traffic on an IP network, and for processing the IP data records from the perspective of at least one traffic dimension.
  • the processing comprises for each at least one traffic dimension: extracting information representative of the traffic dimension from the IP data records, and using the extracted information to compute at least one measure representative of the traffic dimension.
  • the processing further comprises: computing a metric consisting of an aggregated value of the at least one measure representative of the traffic dimension against at least one traffic characteristic.
  • the at least one traffic dimension comprises at least one of: protocols, data services, web domains, applications, and IP television (IPTV) channels.
  • IPTV IP television
  • the at least one measure comprises at least one of: a volume of data, a number of users, a number of sessions, a session duration, and a number of transactions.
  • the at least one measure may further comprise: an average volume of data per user, an average volume of data per session, an average volume of data per transaction, an average number of sessions per user, an average number of transactions per user, and an average session duration per user.
  • the at least one traffic characteristic comprises at least one of: time, devices, users (optionally further divided into subscribers and roamers), and networks.
  • a non-restrictive illustrative embodiment of the present method and system consists in: selecting the at least one traffic dimension from a set of pre-defined traffic dimensions, selecting the at least one measure from a set of pre-defined measures, and selecting the at least one traffic characteristic from a set of pre-defined traffic characteristics.
  • the analytic framework 10 described in Figure 1 is a representation of an IP data traffic occurring on an IP based network infrastructure.
  • the objective of this analytic framework 10 is to enable the processing of raw data, received in the form of IP data records, according to a pre-defined data model.
  • This data model takes into account the complexity resulting from several factors, including: the variety of applications and IP data services used on the IP based network infrastructure, the multitude of devices available (with a range of specific characteristics for each model of device), and the different usage patterns of the users when consuming IP data services.
  • the information extracted from the IP data records is processed and aggregated, allowing the computation of various metrics representative of the IP data traffic on the IP based network infrastructure.
  • the analytic framework 10 relies on the definition of traffic dimensions 20.
  • a traffic dimension 20 is a perspective from which the IP data traffic occurring on an IP based network infrastructure is analyzed.
  • Each traffic dimension 20 is related to a specific aspect of the IP data traffic.
  • the analysis of each aspect presents an added value for a network Operator, in terms of (among others): network performance tracking and optimization; subscriber behavior monitoring and profiling; IP data services monitoring, marketing, and monetizing; etc.
  • the analysis of the IP data traffic is performed from the perspective of at least one of the traffic dimensions 20.
  • the traffic dimensions 20 defined in a specific analytic framework 10 evolve over time, taking into consideration the evolution of the IP data services available on the IP based network infrastructures, and the specific needs of the network Operators in terms of monitoring and analysis.
  • traffic dimensions 20 are represented in Figure 1 : protocols 21 , data services 22, web domains 23, applications 24, and IPTV channels 25. It will be apparent to one of ordinary skill in the art, that other examples of traffic dimensions 20 may be considered, without changing the scope of the present method and system.
  • the protocols traffic dimension 21 allows the analysis of the
  • IP data traffic from the perspective of the various networking protocols used to support the applications and IP data services consumed via the IP based network infrastructure.
  • Examples of such protocols include the Hypertext Transfer Protocol (HTTP), BitTorrent, Skype, the Real-time Transfer Protocol (RTP) and the Real Time Streaming Protocol (RTSP), the Session Initiation Protocol (SIP).
  • HTTP Hypertext Transfer Protocol
  • RTP Real-time Transfer Protocol
  • RTSP Real Time Streaming Protocol
  • SIP Session Initiation Protocol
  • the data services traffic dimension 22 allows the analysis of the IP data traffic from the perspective of various categories of IP data services. Examples of such IP data services include: web browsing, emailing, instant messaging, audio and video streaming, Voice over IP (VoIP), peer-to-peer, business services, IP based television (IPTV). Each IP data service is usually represented by a collection of applications providing this specific type of data service 22. Each application is implemented via a single, or a set of, networking protocol(s). Identifying a specific IP data service implies identifying the networking protocols implementing the related applications.
  • Additional characteristics are taken into consideration, to identify a specific application related to a specific IP data service, since the same protocol may be used to provide different types of IP data services (for example, HTTP is used for both the web browsing and audio / video streaming data services - RTP is used for both the audio / video streaming and VoIP data services).
  • the web domains traffic dimension 23 allows the analysis of the IP data traffic from the perspective of the web domains accessed via the web browsing service.
  • Each web domain is identified by a unique Uniform Resource Identifier (URI) transmitted via the HTTP protocol (the networking protocol supporting the web browsing service).
  • URI Uniform Resource Identifier
  • the applications traffic dimension 24 allows the analysis of the IP data traffic from the perspective of the third party applications used on the devices. This traffic dimension is particularly relevant for a mobile IP network, where such third party applications are usually downloaded from an application portal / store associated to a specific mobile operating system provider, to a specific mobile device manufacturer, or to a specific service provider (for instance the mobile network Operator).
  • the download and installation of a third party application on a mobile device is performed at the initiative of the owner of the mobile device.
  • the mobile IP traffic generated by each specific third party application is taken into consideration.
  • HTTP based third party applications constitute a significant proportion of these third party applications.
  • the detection of the most popular HTTP based third party applications may have a critical importance for a mobile network Operator.
  • the method of identification of each specific HTTP based third party application is out of the scope of the present method and system, but is considered as technically feasible.
  • the IPTV channels traffic dimension 25 allows the analysis of the IP data traffic from the perspective of the IPTV channels viewed by the owners of devices using an IP based TV service, provisioned over an IP based network infrastructure.
  • the IPTV channels are delivered via dedicated networking protocols (for example RTP, RTSP, SIP, HTTP), with specific patterns in the related IP packets, allowing the identification of the IPTV traffic in general, and the identification of each delivered IPTV channel in particular.
  • RTP Real-Time Transport Protocol
  • RTSP Real-Time Transport Protocol
  • SIP Session Initid Access Protocol
  • HTTP HyperText Transfer Protocol
  • the notion of IPTV is taken in a broad sense, to encompass any IP based TV service delivered on an IP based network infrastructure, including a mobile IP network or any kind of IP based fixed broadband network infrastructure.
  • the analytic framework 10 also relies on the notion of measures 40. Information extracted from the IP data records is used to compute each measure 40.
  • the analytic framework 10 represents various measures 40, which are relevant for the analysis of the IP data traffic. For each traffic dimension 20, several measures 40 are relevant to represent this specific traffic dimension. For instance, as illustrated in Figure 1 , the protocols traffic dimension 21 is represented by the following measures 40: 41 (volume), 42 (number of users), and 46 (average volume per user). And the IPTV channels traffic dimension 25 is represented by the following measures 40: 41 (volume), 42 (number of users), 43 (number of sessions), 44 (session duration), and 47 (average volume per session).
  • the definition of a measure 40 is different for each specific traffic dimension 20, so that the computation of each measure is tailored to the traffic dimension for which it is considered.
  • the definition (and the computation) of the volume 41 is different in the context of the following traffic dimensions: protocols 21 , and IPTV channels 25.
  • the measures 40 defined in a specific analytic framework 10 may evolve over time, to enhance the capabilities of analysis of a particular traffic dimension, or to support a new traffic dimension.
  • Figure 1 volume 41 , number of users 42, number of sessions 43, session duration 44, number of transactions 45, average volume per user 46, average volume per session 47, average volume per transaction 48, average number of session per user 49, average number of transaction per user 50, and average session duration per user 51. It will be apparent to one of ordinary skill in the art that other examples of measures 40 may be considered, without changing the scope of the present method and system.
  • the volume 41 measures a volume of IP traffic. Specific IP packets are taken into consideration, to compute the volume 41 from the perspective of a particular traffic dimension. Additionally, the layers of the Open System Interconnection (OSI) model taken into consideration for the computation may vary, based on the considered traffic dimension. In one case, layers 3 (network) to 7 (application) may be considered. In another case, layers 4 (transport) to 7 (application) may be considered. And in still another case, layers 5 to 7 (session / presentation / application) may be considered.
  • OSI Open System Interconnection
  • the volume 41 is the total volume of IP traffic transported by an IP flow associated to a specific networking protocol (for example an HTTP, or a BitTorrent, or a RTP, IP flow).
  • a specific networking protocol for example an HTTP, or a BitTorrent, or a RTP, IP flow.
  • IP flow is defined by a source IP address and source port, a destination IP address and destination port, and a transport protocol (in most cases, Transmission Control Protocol (TCP) or User Datagram Protocol (UDP)).
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • the volume 41 is the total volume of IP traffic transported by all the IP flows (potentially involving several networking protocols) associated to an instance of a specific IP data service (for example an instance of a VoIP session).
  • An IP data service is usually composed of several applications (for example several VoIP applications), each application implemented via one or several networking protocols.
  • an instance of the IP data service is a specific applicative session (represented by one or several related IP flows) generated by a device connected to an IP data network.
  • the volume 41 is the total volume of HTTP traffic transported by all the IP flows supporting an HTTP session (access to a specific web domain (identified by its URI) by a device). [0034] From the perspective of the applications traffic dimension 24, the volume 41 is the total volume of IP traffic transported by all the IP flows associated to a specific third party applicative session (execution of the specific third party application on a device).
  • the volume 41 is the total volume of IP traffic transported by the IP flow(s) (for example, the RTP flows) associated to a specific IPTV session (delivery of a specific IPTV channel to a device).
  • the computation of a volume 41 is based on the information (related to this volume) extracted from the IP data records.
  • the information extracted from the IP data records is memorized (e.g. in a data warehouse), and the effective computation of the volume is performed over a reference time period, as will be detailed later.
  • generic information e.g. timestamps of occurrence, identification of the related device, etc
  • This generic information is used to perform the calculation / aggregation of the volume, as will be detailed later.
  • the number of users 42 measures the number of unique users accessing / making use of a specific resource. Specific IP flows are taken into consideration, to compute the number of users 42 accessing / making use of this specific resource, from the perspective of a particular traffic dimension.
  • the notion of number of unique users is defined as follows: the same user accessing / making use of the specific resource several times under predefined circumstances (for instance, a reference time period) is counted only once.
  • the number of users 42 is the number of unique users making use of a specific networking protocol (for example HTTP, or BitTorrent, or RTP).
  • the number of users 42 is the number of unique users making use of a specific IP data service (for example emailing, or VoIP).
  • the number of users 42 is the number of unique users accessing a specific web domain (identified by its URI).
  • the number of users 42 is the number of unique users making use of a specific third party application (the third party application is identified by the associated IP flows).
  • the number of users 42 is the number of unique users accessing a specific IPTV channel.
  • the access to the IPTV channel is identified by the associated IP flows (for example, the RTP flows) delivering this specific IPTV channel.
  • the computation of a number of users 42 is based on the information (related to this number of users) extracted from the IP data records.
  • having a unique identifier of the device accessing a specific resource is mandatory (in the IP data records), to support the notion of unique user (a unique user is defined by the unique identification of its device).
  • the information extracted from the IP data records is memorized (e.g. in a data warehouse), to keep a record of each access to a specific resource.
  • the effective computation of the number of users is performed over a reference time period, as will be detailed later.
  • generic information e.g. timestamps of occurrence, identification of the related device, etc
  • This generic information is used to perform the calculation / aggregation of the number of users, as will be detailed later.
  • the number of sessions 43 measures the number of occurrences of the access to / the use of a specific resource. Specific IP flows are taken into consideration, to compute the number of occurrences of the access to / the use of the specific resource, from the perspective of a particular traffic dimension. Each time a device accesses / makes use of the specific resource, it is counted as an additional occurrence.
  • the number of sessions 43 is the number of occurrences of an IP flow associated to a specific networking protocol (for example HTTP, or BitTorrent, or RTP).
  • a specific networking protocol for example HTTP, or BitTorrent, or RTP.
  • the number of sessions 43 is the number of occurrences of the use of a specific IP data service (for example emailing, or VoIP).
  • the number of sessions 43 is the number of occurrences of the access to a specific web domain (identified by its URI). [0048] From the perspective of the applications traffic dimension 24, the number of sessions 43 is the number of occurrences of the use of a specific third party application (the third party application is identified by the associated IP flows).
  • the number of sessions 43 is the number of occurrences of the access to a specific IPTV channel.
  • the access to the IPTV channel is identified by the associated IP flows (for example, the RTP flows) delivering this specific IPTV channel.
  • the computation of a number of sessions 43 is based on the information (related to this number of sessions) extracted from the IP data records.
  • the information extracted from the IP data records is memorized (e.g. in a data warehouse), and the effective computation of the number of sessions is performed over a reference time period, as will be detailed later.
  • generic information e.g. timestamps of occurrence, identification of the related device, etc
  • This generic information is used to perform the calculation / aggregation of the number of sessions, as will be detailed later.
  • the session duration 44 measures the duration of the access to / the use of a specific resource. Specific IP flows are taken into consideration, to compute the duration of the access to / the use of the specific resource, from the perspective of a particular traffic dimension.
  • the session duration 44 is the duration of an IP flow associated to a specific networking protocol (for example HTTP, or BitTorrent, or RTP).
  • a specific networking protocol for example HTTP, or BitTorrent, or RTP.
  • the session duration 44 is the duration of an applicative session representative of a specific IP data service (duration of the execution of an applicative session by a device).
  • the session duration 44 is the duration of an HTTP session related to a specific web domain (duration of the access to a specific web domain by a device).
  • the session duration 44 is the duration of an applicative session of a specific third party application (duration of the execution of an applicative session by a device).
  • the session duration 44 is the duration of an IPTV session related to a specific IPTV channel (duration of the access to a specific IPTV channel by a device).
  • the computation of a session duration 44 is based on the information (related to this session duration) extracted from the IP data records.
  • the extracted information is memorized (e.g. in a data warehouse), and the effective computation of the session duration is performed over a reference time period, as will be detailed later.
  • generic information e.g. timestamps of occurrence, identification of the related device, etc
  • This generic information is used to perform the calculation / aggregation of the session duration, as will be detailed later.
  • the number of transactions 45 measures the number of occurrences of a specific transaction for the access to / the use of a specific resource.
  • This measure may not be applicable to every traffic dimension.
  • specific IP flows are taken into consideration, to compute the number of occurrences of a specific transaction for the access to / the use of the specific resource, from the perspective of a specific traffic dimension. Each time a device performs the specific transaction, it is counted as an additional occurrence.
  • the number of transactions 45 is, for example, the number of HTTP GET or HTTP POST requests related to a specific web domain (identified by its URI).
  • the computation of a number of transactions 45 is based on the information (related to this number of transactions) extracted from the IP data records.
  • the information extracted from the IP data records is memorized (e.g. in a data warehouse), to keep a record of each occurrence of a specific transaction.
  • the effective computation of the number of transactions is performed over a reference time period, as will be detailed later.
  • generic information e.g. timestamps of occurrence, identification of the related device, etc
  • This generic information is used to perform the calculation / aggregation of the number of transactions, as will be detailed later.
  • Additional measures may be defined, for instance by combining two among the previously defined measures. For example, the following additional measures may be considered: the average volume per user 46, the average volume per session 47, the average volume per transaction 48, the average number of sessions per user 49, the average number of transactions per user 50, and the average session duration per user 51. Each of these additional measures may not be applicable to every traffic dimension. Following are a few examples of how these additional measures are applied to a specific traffic dimension.
  • the average volume per user 46 is the volume 41 (total volume of IP traffic transported by all the IP flows associated to a specific networking protocol), divided by the number of users 42 (number of unique users making use of this specific networking protocol).
  • the average volume per session 47 is the volume 41 (total volume of IP traffic transported by all the IP flows associated to the delivery of a specific IPTV channel), divided by the number of sessions 43 (number of occurrences of an access to this specific IPTV channel).
  • the measures 40 are computed over a reference time period and stored in a data warehouse.
  • the reference time period is dependent on the granularity in terms of time interval of the data received in the IP data records.
  • Each network event reported in the IP data records usually has a timestamp with a lowest possible granularity in hours, preferably minutes, and even preferably seconds.
  • the computation of the measures 40 is also dependant on the frequency of reception of the IP data records.
  • a reasonable reference time period for the computation of the measures 40 is the hour. However, some measures may require a lower reference time period, for instance minutes or even seconds. This is the case for the session duration 44, in the context of the IPTV channels 25. Higher reference time periods, like days, are not sufficiently accurate, since Operators are more and more interested in comparing various aspects of the IP data traffic at different periods of the day (the hour, and optionally the minute, is a good granularity in this case).
  • the analytic framework 10 also relies on the notion of traffic characteristics 60.
  • the measures 40 computed as described previously, are further aggregated against at least one traffic characteristic 60.
  • the result of the aggregation is a metric, which is used by the network Operator to monitor a specific aspect of the IP data traffic on its IP based network infrastructure.
  • the traffic characteristics 60 defined in a specific analytic framework 10 may evolve over time, to enhance the capabilities of analysis of the IP data traffic.
  • traffic characteristics 60 are represented in Figure 1 : time 61 , devices 62, users 63, and networks 64. It will be apparent to one of ordinary skill in the art that other examples of traffic characteristics 60 may be considered, without changing the scope of the present method and system.
  • the time 61 is a traffic characteristic 60, which is generally always available to perform the aggregation of the measures 40. This is due to the fact that the notion of time is already present in the computation of the measures 40, since these measures are computed over a reference time period. Thus, the measures 40 may be further aggregated against a multiple of the reference time period. For instance, if the reference time period is the hour, each measure 40 may be further aggregated, to compute an aggregated value of the measure against days, weeks, or months. The computation of the measures over the reference time period (for instance the hour) may be considered in itself as an aggregation of the measures against the reference time period.
  • the devices 62 are a traffic characteristic 60, which may be used to perform the aggregation of the measures 40. For instance, if every network event in the IP data records is associated to a unique identifier of the device which initiated this network event, then the measures 40 can be computed for each individual unique identifier. The information extracted from the IP data records is sorted per unique identifier of the related device, and the measures 40 are computed for each unique identifier over the reference time period. For example, in the case of a mobile IP network of the 3GPP family (Third Generation Partnership Project), a unique identifier of the mobile devices is the IMEI (International Mobile Equipment Identity).
  • IMEI International Mobile Equipment Identity
  • the manufacturer and the model of the mobile device can be inferred.
  • additional characteristics can be further determined (using an additional data source 140 as represented in Figure 2): type of mobile device (feature phone, smart phone, tablet, computer with a dongle used as a modem), operating system used by the mobile device, etc.
  • the measures 40 may be further aggregated against one of the characteristics of the devices 62: aggregated values of the measures may be computed for each device manufacturer, for each model of device, for each type of device, for each operating system, etc.
  • the users 63 are a traffic characteristic 60, which may be used to perform the aggregation of the measures 40. For instance, if every network event in the IP data records is associated to a unique identifier of the user who owns the device which initiated this network event, then the measures 40 can be computed for each individual unique identifier. The information extracted from the IP data records is sorted per unique identifier of the related users, and the measures 40 are computed for each unique identifier over the reference time period.
  • a unique identifier of the user who owns a mobile device is the IMSI (International Mobile Subscriber Identity) or the MSISDN (Mobile Subscriber Integrated Services Digital Network Number). Having the unique identifier, it is possible to obtain demographic characteristics (sex, age, revenue, localization, etc) of the user associated to this unique identifier from an additional data source (140 as represented in Figure 2). In the case of a mobile IP network, having the unique identifier of the user, it is also possible to detect if this user is a subscriber of the mobile network Operator or a roamer.
  • IMSI International Mobile Subscriber Identity
  • MSISDN Mobile Subscriber Integrated Services Digital Network Number
  • the detection may be direct (for example, the IMSI contains information that allows the segregation between subscribers and roamers), or indirect via a cross reference of the unique identifier with an additional source of information (for example, the MSISDN may be cross referenced with the database containing the mobile network Operator's subscribers).
  • the measures 40 may be further aggregated against one of the characteristics of the users 63: aggregated values of the measures may be computed for various demographic characteristics of the users, aggregated values of the measures may also be computed for the subscribers or the roamers in the case of a mobile network Operator.
  • having unique identifiers of the devices associated to the network events in the IP data records allows the segmentation of the measures 40 against the devices 62, but also against the users 63.
  • an additional data source is used to map the unique identifier of a device to a unique identifier of the user who owns this device.
  • having unique identifiers of the users who own the devices associated to the network events in the IP data records allows the segmentation of the measures 40 against the users 63, but also against the devices 62.
  • an additional data source is used to map the unique identifier of a user who owns a device to a unique identifier of the device itself.
  • unique identifiers of both the devices and the users are associated to the network events in the IP data records, allowing the direct segmentation against both the devices 62 and the users 63.
  • the networks 64 are a traffic characteristic 60, which may be used to perform the aggregation of the measures 40.
  • This characteristic applies specifically to mobile IP networks.
  • various types of radio access networks within the 3GPP family may be deployed in the global mobile network infrastructure, including General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), etc.
  • GPRS General Packet Radio Service
  • UMTS Universal Mobile Telecommunications System
  • LTE Long Term Evolution
  • the measures 40 may be further aggregated against one of the radio access network type defined in the traffic characteristic networks 64.
  • the volume of data 41 is computed per IPTV channel over a reference time period (one hour) for each unique identifier of a mobile device. It may be further aggregated against a combination of: a specific model of mobile device 62, a specific duration 61 (e.g. on a daily basis), and the subscribers 63 (e.g. excluding the roamers).
  • An IP data network 100 is represented in Figure 2. It allows various types of devices (110, 111 , and 112) to access IP based applications and services 120, via the IP data network 100. For this purpose, IP data traffic is generated between the devices (110, 111 , and 112), and the infrastructure supporting the IP based applications and services 120. The role of a collecting entity 130 is to collect data related to this IP data traffic.
  • the present method and system is applicable to any type of mobile IP network (100) operated by a mobile network Operator, including without limitations: GPRS networks, UMTS networks, LTE networks, Code Division Multiple Access (CDMA) networks, or Worldwide Interoperability for Microwave Access (WIMAX) networks.
  • GPRS networks UMTS networks
  • UMTS networks Long Term Evolution networks
  • LTE networks Long Term Evolution networks
  • CDMA Code Division Multiple Access
  • WIMAX Worldwide Interoperability for Microwave Access
  • the present method and system is also applicable to any type of IP based fixed broadband network (100) operated by an Internet Service Provider (ISP), including without limitations: Digital Subscriber Line (DSL) networks, cable networks, or optical fiber networks.
  • ISP Internet Service Provider
  • DSL Digital Subscriber Line
  • the present method and system is also applicable to an IP data network (100) operated by a corporation, for instance a private company or a governmental / public organization.
  • the type of devices using the IP data network 100 includes without limitations: mobile phones 110, tablets (not represented), laptops and computers 111 , television sets 112; and more generally any type of IP enabled mobile device, home networking equipment / IP enabled multimedia equipment.
  • the collecting entities 130 collect data representative of the
  • IP data traffic on the IP data network 100 and generate IP data records based on the collected data.
  • the collecting entities 130 may operate in two ways.
  • the collecting entities 130 collect data by capturing in real time IP packets from the IP data traffic occurring on a specific segment of the IP data network 100.
  • the captured IP packets contain data related to IP data sessions occurring on the IP data network.
  • An IP data session is defined as an IP based data session initiated by a device (110, 111 , or 112) on the IP data network 100, during which the device (110, 111 , or 112) consumes various types of applications and services 120 (for example messaging, web browsing, social networking, multimedia streaming, etc).
  • the IP packets related to a specific IP data session are analyzed according to the protocol layers of the Open System Interconnection (OSI) model, to extract parameters representative of the IP data traffic on the IP data network 100.
  • OSI Open System Interconnection
  • DPI Deep Packet Inspection
  • the type of parameters which can be extracted from IP packets by DPI based collecting entities 130 is also well known in the art.
  • the collecting entities 130 may be positioned between a Serving GPRS Support Node (SGSN) and a Gateway GPRS Support Node (GGSN), in order to collect the IP data traffic between these two equipments, well known in the art as the GPRS Tunneling Protocol (GTP) control and user planes.
  • SGSN Serving GPRS Support Node
  • GGSN Gateway GPRS Support Node
  • GTP GPRS Tunneling Protocol
  • the collecting entities 130 do not operate on the real time traffic, but collect data that have been gathered by one or several networking equipments of the IP based network infrastructure.
  • the gathered data usually consist in logs of the IP data sessions.
  • the same type of parameters is extracted from these gathered data, as in the case of the previously described first embodiment.
  • the granularity of the parameters may be lower in this second embodiment, since the collecting entities 130 can only extract the subset of parameters present in the gathered data, and some useful parameters may be missing.
  • the extracted parameters are generally sufficient to be representative of the IP data traffic on the IP data network 100, since they usually include for each IP data session: timestamps of occurrence of network events, an identifier of the device (1 10, 1 1 1 , and 112) performing the IP data session, and several parameters representative of the specific protocols, applications and services used during the IP data session.
  • timestamps of occurrence of network events an identifier of the device (1 10, 1 1 1 , and 112) performing the IP data session
  • several parameters representative of the specific protocols, applications and services used during the IP data session are usually referred to as Call Detail Records (CDRs).
  • CDRs Call Detail Records
  • the collecting entities 130 retrieve the CDRs from network equipments such as the GGSN and the SGSN, and extract the relevant parameters from these CDRs.
  • IPDRs IP Detail Records
  • the collecting entities 130 transmit IP data records to an analytic system 160.
  • the IP data records contain all the parameters collected by the collecting entities 130 over a pre-defined time period.
  • the analytic system 160 is composed of a pre-processing unit 162, a post-processing unit 164, a data warehouse 166, an analytic engine 168, and a reports unit 170.
  • a single centralized analytic system 160 receives the IP data records from all the collecting entities 130 operating on the IP data network 100.
  • several centralized analytic systems 160 may be deployed, each of these receiving the IP data records from a set of collecting entities 130 grouped by geographical proximity (or any other relevant criteria).
  • the IP data records received from the collecting entities 130 are processed by the pre-processing unit 162, according to an analytic framework 10 as represented in Figure 1.
  • This processing consists in extracting information from the IP data records, transforming the extracted information according to a data model defined in relation to the analytic framework 10, and storing the resulting information in the data warehouse 166. If necessary, additional data provided by an additional data source 140 may be used, to enrich the information extracted from the IP data records, as has been explained previously in the description of Figure 1.
  • the IP data records contain generic information relevant in the context of any of the traffic dimensions 20. For instance, the identifiers of the devices (1 10, 111 , and 1 12), the identifiers of the users who own the devices (1 10, 1 1 1 , and 1 12), the type of network technology used for a given IP data session, represent information extracted from the IP data records, which are relevant to any traffic dimension 20. [0088] The IP data records also contain information only relevant in the context of a specific traffic dimension 20.
  • IP data records For instance, detailed information related to the usage of a specific network protocol (identification of the protocol, timestamps of beginning and end of the usage of the protocol within an IP data session, volume of data transferred with this protocol, and various parameters specific to this protocol like the URI in the case of HTTP), represent information extracted from the IP data records, which may be relevant to only one of the specific traffic dimensions 20.
  • IP data records are relevant to more than one traffic dimension 20.
  • basic information related to the usage of a specific network protocol is relevant to the traffic dimension protocols 21 ; and is also relevant to the traffic dimensions data services 22 (various network protocols), web domains 23 (HTTP protocol), applications 24 (HTTP protocol), and IPTV channels 25 (HTTP, SIP, RTP, RTSP protocols).
  • the pre-processing unit 162 when processing the IP data records from the perspective of a specific traffic dimension 20, the pre-processing unit 162 extracts information representative of this specific traffic dimension (including information exclusively relevant to this traffic dimension, and information also relevant to other traffic dimensions). This information is optionally adapted (to comply with a specific data model representative of the analytic framework 10), and then stored in the data warehouse 166.
  • the post-processing unit 164 processes the information
  • the pre-processing unit 162 in order to compute measures 40 defined according to the analytic framework 10 over a reference time period.
  • Each resulting measure 40 is stored in the data warehouse 166.
  • the computation of a measure 40 is performed in relation to a specific traffic dimension 20, as has been explained previously in the description of Figure 1.
  • the post-processing unit 164 also processes the measures
  • the computation of an aggregated value of a measure 40, representative of a specific traffic dimension 20, is performed against at least one traffic characteristic 60, as has been explained previously in the description of Figure 1.
  • the resulting aggregated values of the measures are stored in the data warehouse 166, and constitute metrics representative of the IP data traffic on the IP data network 100.
  • the post-processing unit 164 performs the computation of the measures 40 representative of this specific traffic dimension 20 over reference time periods (based on the previously extracted information stored in the data warehouse by the pre- processing unit 162), and stores these resulting measures 40 in the data warehouse 166.
  • the reference time period for the computation of a measure 40 may be a minute or an hour, based on the granularity required for this measure 40.
  • the post-processing unit 164 computes aggregated values of the measures 40 (representative of the traffic dimensions 20) stored in the data warehouse 166, to generate the metrics representative of the IP data traffic on the IP data network 100. The aggregation of the measures 40 is performed against one (or several) traffic characteristic(s) 60 defined in the analytic framework 10.
  • the pre-processing unit 162 and the post-processing unit 164 have been represented as two separate functional entities in Figure 2. However, from an implementation perspective, these two functional entities may be integrated into a single processing unit.
  • the analytic engine 168 queries the data warehouse 166, to extract metrics (the aggregated values of the measures 40) representative of the IP data traffic on the IP data network, according to the analytic framework 10.
  • the extracted metrics are further processed if necessary (some additional computations may be necessary to generate the finalized values of the metrics), and then combined, to generate reports.
  • These reports are transferred to the reports unit 170, to be presented to the staff of the network Operator (e.g. operational, marketing, and product development teams) via a Graphical User Interface (GUI).
  • GUI Graphical User Interface
  • the reports presented via the GUI consist in visual representations of the metrics, relying on various types of charts and diagrams, to illustrate the metrics in an intuitive, easy to understand way.
  • the generation of a report according to the analytic framework 10 follows the following steps. First, a traffic dimension 20 is selected. Then, one or several measures 40 representative of this traffic dimension 20 is (are) selected. Then, for each measure 40, one or several traffic characteristics 60 are selected. For each traffic characteristic 60, a range of values representative of this traffic characteristic is selected. The data warehouse 166 is queried by the analytic engine 168, to extract the aggregated values of each selected measure 40 against the range of values of the selected traffic characteristic(s) 60. The extracted aggregated values of the measures 40 constitute the metrics, which are further processed if necessary, and then combined, to generate the report.
  • a report is generated to analyze the IPTV channels 25.
  • the volume of traffic 41 for three different IPTV channels is compared.
  • the volume of traffic 41 is aggregated on a daily basis, and compared over a one month period (aggregation against time 61).
  • the comparison is performed for two different models of mobile devices (aggregation against devices 62).
  • the analytic engine 168 has Business Intelligence
  • Bl and / or data mining capabilities, to further process the metrics extracted from the data warehouse 166.
  • Trends and behaviors in the usage of the IP data network 10 are identified via the Bl capabilities.
  • clusters of users with specific consumption patterns are identified via the data mining capabilities.
  • the pre-processing unit 162, the post-processing unit 164, the analytic engine 168, and the reports unit 170 are respectively composed of dedicated software programs executed on a dedicated computer. Alternatively, dedicated software programs corresponding to several units may be executed on the same computer (for instance for the pre-processing unit 162 and postprocessing unit 164).
  • the implementation of the data warehouse 166 is considered as well known in the art.
  • the analytic framework 10 consists of a set of pre-defined traffic dimensions 20, a set of pre-defined measures 40, and a set of pre-defined traffic characteristics 60.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Algebra (AREA)
  • Mathematical Physics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • General Engineering & Computer Science (AREA)
  • Probability & Statistics with Applications (AREA)
  • Pure & Applied Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente invention concerne un procédé et un système servant à générer des mesures représentatives du trafic de données IP à partir d'enregistrements de données IP. Le procédé et le système reçoivent, sur un système d'analyse, des enregistrements de données IP représentatifs du trafic de données IP dans un réseau IP. Le procédé et le système traitent, sur le système d'analyse, les enregistrements de données IP du point de vue d'au moins une dimension du trafic. Pour chaque dimension parmi ladite ou lesdites dimensions, le traitement consiste à extraire des informations représentatives de la dimension du trafic à partir des enregistrements de données IP, et à utiliser les informations extraites pour calculer au moins une mesure représentative de la dimension du trafic. Le traitement consiste en outre à calculer une mesure et à constituer une valeur agrégée de la ou des mesures représentatives de la dimension du trafic par rapport à au moins une caractéristique du trafic.
PCT/CA2011/000877 2010-08-06 2011-07-21 Procédé et système de génération de mesures représentatives du trafic de données ip à partir d'enregistrements de données ip WO2012016327A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US37147710P 2010-08-06 2010-08-06
US61/371,477 2010-08-06

Publications (1)

Publication Number Publication Date
WO2012016327A1 true WO2012016327A1 (fr) 2012-02-09

Family

ID=45558880

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2011/000877 WO2012016327A1 (fr) 2010-08-06 2011-07-21 Procédé et système de génération de mesures représentatives du trafic de données ip à partir d'enregistrements de données ip

Country Status (1)

Country Link
WO (1) WO2012016327A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9471612B2 (en) 2012-06-29 2016-10-18 International Business Machines Corporation Data processing method, data query method in a database, and corresponding device
US20230261958A1 (en) * 2020-06-16 2023-08-17 Telefonaktiebolaget Lm Ericsson (Publ) Technique for reporting network traffic activities

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5787253A (en) * 1996-05-28 1998-07-28 The Ag Group Apparatus and method of analyzing internet activity
US5850388A (en) * 1996-08-02 1998-12-15 Wandel & Goltermann Technologies, Inc. Protocol analyzer for monitoring digital transmission networks
US20050128946A1 (en) * 2003-12-11 2005-06-16 Yasuo Murakami Network statistics information service system and internet access server
US20060015576A1 (en) * 2002-11-13 2006-01-19 Seo Kyoung-Ii Apparatus for analyzing the packet data on mobile communication network and method thereof
US7065482B2 (en) * 2001-05-17 2006-06-20 International Business Machines Corporation Internet traffic analysis tool
US20060198311A1 (en) * 2005-03-04 2006-09-07 Stsn General Holdings Inc. Detection of multiple users of a network access node
US20070234425A1 (en) * 2006-03-29 2007-10-04 Woonyon Kim Multistep integrated security management system and method using intrusion detection log collection engine and traffic statistic generation engine
US7492720B2 (en) * 1998-11-24 2009-02-17 Niksun, Inc. Apparatus and method for collecting and analyzing communications data
US7660248B1 (en) * 2004-01-23 2010-02-09 Duffield Nicholas G Statistical, signature-based approach to IP traffic classification

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5787253A (en) * 1996-05-28 1998-07-28 The Ag Group Apparatus and method of analyzing internet activity
US5850388A (en) * 1996-08-02 1998-12-15 Wandel & Goltermann Technologies, Inc. Protocol analyzer for monitoring digital transmission networks
US7492720B2 (en) * 1998-11-24 2009-02-17 Niksun, Inc. Apparatus and method for collecting and analyzing communications data
US7065482B2 (en) * 2001-05-17 2006-06-20 International Business Machines Corporation Internet traffic analysis tool
US20060015576A1 (en) * 2002-11-13 2006-01-19 Seo Kyoung-Ii Apparatus for analyzing the packet data on mobile communication network and method thereof
US20050128946A1 (en) * 2003-12-11 2005-06-16 Yasuo Murakami Network statistics information service system and internet access server
US7660248B1 (en) * 2004-01-23 2010-02-09 Duffield Nicholas G Statistical, signature-based approach to IP traffic classification
US20060198311A1 (en) * 2005-03-04 2006-09-07 Stsn General Holdings Inc. Detection of multiple users of a network access node
US20070234425A1 (en) * 2006-03-29 2007-10-04 Woonyon Kim Multistep integrated security management system and method using intrusion detection log collection engine and traffic statistic generation engine

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
CALLADO, A. ET AL.: "A Survey on Internet Traffic Identification", IEEE COMMUNICATIONS SURVEYS & TUTORIALS, vol. 11, no. 3, 21 August 2009 (2009-08-21), pages 37 - 52, XP011272506, DOI: doi:10.1109/SURV.2009.090304 *
DATABASE IP.COM 18 July 2006 (2006-07-18), IBM: "Method and System for Netflow Analyzer and Entry Into Database", XP013115120, Database accession no. IPCOM000138427D *
ROSSI, D. ET AL.: "Sherlock: A framework for P2P traffic analysis", IEEE NINTH INTERNATIONAL CONFERENCE ON PEER-TO-PEER COMPUTING, P2P'09, SEPTEMBER 9-11, 2009, 9 September 2009 (2009-09-09), SEATTLE, WA, USA, pages 321 - 330, XP031544857 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9471612B2 (en) 2012-06-29 2016-10-18 International Business Machines Corporation Data processing method, data query method in a database, and corresponding device
US20230261958A1 (en) * 2020-06-16 2023-08-17 Telefonaktiebolaget Lm Ericsson (Publ) Technique for reporting network traffic activities
JP7511030B2 (ja) 2020-06-16 2024-07-04 テレフオンアクチーボラゲット エルエム エリクソン（パブル） ネットワークトラフィックアクティビティを報告するための技法

Similar Documents

Publication Publication Date Title
US8935381B2 (en) Method and apparatus for real-time collection of information about application level activity and other user information on a mobile data network
US9032427B2 (en) System for monitoring a video network and methods for use therewith
US20120060198A1 (en) Method and system for generating metrics representative of policy and charging control rules
US20150222939A1 (en) System for monitoring a video network and methods for use therewith
CN107040863B (zh) 实时业务推荐方法及系统
US20120317151A1 (en) Model-Based Method for Managing Information Derived From Network Traffic
US9424509B2 (en) System for application personalization for a mobile device
US20100054128A1 (en) Near Real-Time Alerting of IP Traffic Flow to Subscribers
US10284928B2 (en) System and method of analyzing CMTS data streams
US20150312127A1 (en) Data Usage Analysis and Reporting
US20130019009A1 (en) Method and system for subscriber journey analytics
US20110238826A1 (en) Method and system for analysing a mobile operator data network
US20130066875A1 (en) Method for Segmenting Users of Mobile Internet
Mangla et al. VideoNOC: Assessing video QoE for network operators using passive measurements
US20120042067A1 (en) Method and system for identifying applications accessing http based content in ip data networks
WO2012016327A1 (fr) Procédé et système de génération de mesures représentatives du trafic de données ip à partir d'enregistrements de données ip
US20120215793A1 (en) Method and system for matching segment profiles to a device identified by a privacy-compliant identifier
US20130064108A1 (en) System and Method for Relating Internet Usage with Mobile Equipment
CN102064972A (zh) 一种监视广告效果的方法及系统
AT&T
CA2885035A1 (fr) Analyse d'utilisation de donnees et production de rapport
Dabrowski et al. The MOME Workstation as a Platform for Automatic Analysis of Measurement Data

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11813983

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11813983

Country of ref document: EP

Kind code of ref document: A1