Patent Application
20230261958
The present disclosure generally relates to the field of processing information gathered in a communications network with the aim of reporting network traffic activities of mobile devices. The technique presented herein may be implemented in the form of a method, a computer program product, a network apparatus, and a network system.
In current mobile communications networks, network traffic patterns of mobile devices are primarily analysed for enforcing traffic handling policies and other network-related policies, including quality of service guarantees, charging agreements, and admission control. In some implementations, the associated traffic analysis is done in a core network domain by a Policy Control and Charging Rules Function (PCRF). In addition to exposing information about network traffic activities for PCRF-based policy enforcement, there is some further information exposure by service exposure functions, including a Service Capability Exposure Function (SCEF) in 4th Generation (4G)/Long Term Evolution (LTE) communications networks and a Network Exposure Function (NEF) in 5th Generation (5G) communications networks. In this case, the exposed information mainly relates to connectivity aspects (e.g., roaming status, communication failures, availability after downlink data failure, number of mobile devices in a certain geographical area, detection of radio access network congestion, loss of connectivity, and reachability).
Moreover, the Network Data Analytics Function (NWDAF) newly introduced for 5G communications networks also provides analytics services. These services are provided using a similar subscribe/notify model as SCEF and NEF. The purpose of NWDAF is to provide traffic monitoring insights. Examples of such insights include the load status of active network slices, application performance or predicting/analysing behaviour of mobile devices.
The network functions discussed above target at exposing network traffic information for purposes of service quality monitoring, monitoring of mobile infrastructure status or monitoring of mobile device status, and the monitored information is mainly intended for the owners of the respective assets, for example the network operators and/or the device owners. Therefore, the information exposed typically includes either an identity of a mobile device or an identity of a group of mobile devices. In some cases it would, however, be desired to anonymously report insights about network traffic activities of mobile devices.
One solution in this regard would be information aggregation, for example by reporting the number of mobile devices fulfilling certain filtering criteria without disclosing the associated device identifiers. However, there exist various challenges in case the report is to be generated from highly granular information (e.g., on Protocol Data Unit, PDU, level), in particular when the monitoring period may cover an extended period of time.
There is a need for a technique for efficiently reporting information gathered for network traffic activities of mobile devices.
According to a first aspect, a method of reporting information included in data records generated for network traffic activities of a plurality of mobile devices is provided. Each data record includes a traffic type of a traffic activity of a mobile device, a timestamp of the traffic activity, and an identifier of the mobile device.
The method comprises receiving a monitoring request specifying a monitoring type, and calculating from the data records a number of mobile devices having, within a given monitoring period, traffic activities that fulfil the following conditions:
The method of the first aspect further comprises returning, in response to the monitoring request, a monitoring report that is based on the calculated number of mobile devices.
The monitoring report may include a parameter that is based on the calculated number of mobile devices and indicative of an extent across mobile devices of the traffic activity associated with the monitoring type and the monitoring period. In some variants, the parameter may be the calculated number of mobile devices as such (e.g., for a particular point in time corresponding to the monitoring period). In other variants, the parameter may be an averaged number of mobile devices derived by averaging two or more individually calculated number of devices (e.g., for different points in time within the monitoring period). As such, the monitoring period may be defined to be a point in time or may have a longer temporal extension (e.g., of seconds, minutes, hours, or days).
The monitoring report may only include anonymized information. For example, the report may not include any information allowing to identify a particular mobile device or a particular device group included in calculated number of mobile devices. In particular, the report may not include any mobile device identifiers.
In some variants, traffic activities associated with the same identifier and the same traffic activity are considered only once per monitoring period to avoid counting multiple data records associated with the same traffic activity and the same traffic type multiple times per mobile device and, thus, falsifying the calculation of the actual number of mobile devices. In one implementation, to fulfil condition iii), multiple data records per mobile device that concurrently fulfil conditions i) and ii) are only considered once. For example, out of a set of data records that fulfil conditions i) and ii) for a given mobile device, only one data record (e.g., the first within the monitoring period) is actually considered to increment the current count of the number of devices, and the other data records do not lead to a (further) incrementation.
Each traffic activity may comprises transmission of a series of Protocol Data Units (PDUs). The PDUs may be associated with a particular communication protocol on any particular layer of the Open System Interconnection (OSI) model. Depending on the layer, such PDUs are for example called segments or datagrams (layer 4), data packets (layer 3), and frames (layer 2).
The series of PDUs may be transmitted in the context of a session established for a particular mobile device, or otherwise. In some cases, one data record has been generated from one PDU.
Each PDU may have a PDU header and a PDU payload. The traffic type included in a particular data record may be determined (e.g., upon data record generation) by at least one of PDU header inspection and PDU payload inspection. For example, the PDUs may be selected from Internet Protocol (IP) PDUs and Hypertext Transfer Protocol (HTTP) PDUs, and the corresponding header or payload may then be inspected.
Generating an individual one of the data records may comprise receiving a measurement report indicating, for a current traffic activity of a particular mobile device, a traffic type of the traffic activity and an identifier of the mobile device. The measurement report may pertain to a dedicated PDU or a dedicated series of PDUs. The measurement report may be generated by one or both of PDU header inspection and PDU payload inspection. The measurement report may be generated in a radio access network domain or in a core network domain of a mobile communications system.
According to a first variant, generating an individual one of the data records may further comprise generating a data record associating the traffic type and the identifier of the particular mobile device, and providing the data record with a time stamp. According to a second variant, generating an individual one of the data records may further comprise requesting, based on the identifier of the mobile device, a geographical location of the traffic activity, receiving the geographical location of the traffic activity, generating a data record associating the geographical location with the traffic type and the identifier of the particular mobile device, and providing the data record with a time stamp.
In these variants, the data record may be generated substantially in real time with the current traffic activity. In this manner, it can be ensured that the timestamp is actually indicative of the time the current traffic activity takes place.
As said, the monitoring report may include an average number of mobile devices. This average number may be derived by performing the calculation N times during the monitoring period so as to obtain N numbers of mobile devices, and averaging the N numbers of mobile devices thus obtained (e.g., by dividing the summed numbers by N). The individual calculations may be equidistant in time over the monitoring period. Each of the individual calculations may be performed for a dedicated sub-period (including a dedicated point in time) of the monitoring period. A frequency of the calculations may be variable, for example depending on one or more network parameters, such as network load.
The monitoring report may include a value derived from the data records that fulfil the conditions. For example, the monitoring report may include the value in a <type, value> data structure. The type in this data structure may correspond to the monitoring type specified in the monitoring request. The value may be indicative of one or more of: a traffic type, a generic traffic type encompassing multiple traffic types on a lower hierarchy level, a prediction made by a machine learning algorithm based on the data records that fulfil the conditions, and a temporal validity of the prediction, and an average traffic duration. The monitoring type may in some variants be on the same or a higher hierarchy level than a generic traffic type. The monitoring request may include a list of <type, value> data structures, wherein for each value an associated (possibly averaged) number of mobile devices can be reported. In some variants, the monitoring report does not include the number of mobile devices but at least one or more values, optionally in at least one <type, value> data structure.
The monitoring period may in some variants be specified in the monitoring request. In other variants, the monitoring period may be defined by a network operator or otherwise. The monitoring period may be a function of one or more variable network parameters. As an example, the monitoring period may decrease as the network load increases.
The traffic type may be indicative of, or derived from, at least one of an application identifier of an application involved in the network traffic resulting in the traffic activity and a destination domain name of a destination of the network traffic. The application may be running on an application server outside the mobile communications network. The destination domain name may take the form of a Universal Resource Identifier (URI).
For anonymization, two or more traffic types of a lower hierarchy level may be mapped in the calculation to a single generic traffic type on a higher hierarchy level. The number of mobile devices is then calculated across all the traffic types of the lower hierarchy level mapped to the generic traffic indication. The monitoring type specified in the monitoring request may be located on the same or a higher hierarchy level than each generic traffic type.
For example, YouTube traffic activities and Netflix traffic activities may both be mapped to the generic traffic type “video streaming traffic”. So when a monitoring request specifies “streaming traffic” (or “video streaming traffic”) as monitoring type, mobile devices are counted that have either one of YouTube traffic activities and Netflix traffic activities, which adds to the anonymization of the reported information. Of course, this does not exclude that the monitoring type specified in the monitoring request could also indicate a traffic type as such (e.g., “Netflix traffic”).
For example, one or both of different application identifiers and different destination domain names may be mapped, as exemplary lower level traffic types, to a single generic traffic type on the higher hierarchy level. The generic traffic type may then be included as a value in the monitoring report, in addition to the (possibly averaged) number of mobile devices fulfilling the filtering conditions across the generic traffic type.
Each data record may further include a geographical location of the mobile device during the traffic activity. In such a case, the monitoring request may further specify a geographical area to be monitored, and when calculating the number of mobile devices, the following further condition may be considered:
iv) the geographical location of the traffic activity falls within the geographical area.
The geographical location is in one variant defined by a cell identifier. As such, the method may further include consulting a mapping between cell identifiers and geographical areas to determine if the geographical location of the traffic activity falls within the geographical area.
Also provided is computer program product comprising program code portions configured to perform the steps of the method presented herein when the computer program product is executed on a processor. The computer program product may be stored on a computer-readable recording medium.
According to a further aspect, a network apparatus configured to report information included in data records generated for network traffic activities of a plurality of mobile devices is presented, wherein each data record includes a traffic type of a traffic activity of a mobile device, a timestamp of the traffic activity, and an identifier of the mobile device. The network apparatus is configured to receive a monitoring request specifying a monitoring type, and to calculate from the data records a number of mobile devices having, within a given monitoring period, traffic activities that fulfil the following conditions:
The network apparatus is further configured to return, in response to the monitoring request, a monitoring report that is based on the calculated number of mobile devices.
The network apparatus may be configured as or located on a network node, for example in a radio access network domain or a core network domain. As such, it may be configured as or located on a packet gateway node of a 4th generation mobile communications network. Alternatively, the network apparatus may be configured as or co-located with a network data analytics function of a 5th generation mobile communications network.
Also provided is a network system comprising the network apparatus presented herein, a first gateway node configured to route network traffic for a first set of mobile devices for which information about network traffic activities is to be reported, and a second gateway node configured to route network traffic for a second set of mobile devices for which information about network traffic activities is not to be reported
Still further, a network system is provided comprising the network apparatus presented herein, a first gateway node configured to route network traffic for mobile devices for which information about network traffic activities is to be reported, wherein the first gateway node performs routing until a re-routing condition is fulfilled, and further comprising a second gateway node configured to route network traffic for the set of mobile devices after the re-routing condition is fulfilled. In some implementations, the re-routing condition is lapse of a predefined period of time individually started per mobile device.
Further aspects, details and advantages of the present disclosure will become apparent from the detailed description of exemplary embodiments below and from the drawings, wherein:
In the following description, for purposes of explanation and not limitation, specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent to one skilled in the art that the present disclosure may be practiced in other embodiments that depart from these specific details.
While, for example, some embodiments of the following description focus on an exemplary core network configuration in accordance with specific 4G and 5G specifications, the present disclosure is not limited in this regard. The present disclosure could also be implemented in other cellular or non-cellular wireless communication networks.
Those skilled in the art will further appreciate that the steps, services and functions explained herein may be implemented using individual hardware circuits, using software functioning in conjunction with a programmed microprocessor or general purpose computer, using one or more application specific integrated circuits (ASICs) and/or using one or more digital signal processors (DSP). It will also be appreciated that when the present disclosure is described in terms of a method, it may also be embodied in one or more processors and one or more memories coupled to the one or more processors, wherein the one or more memories store one or more computer programs that perform the steps, services and functions disclosed herein when executed by one or more processors.
In the following description of exemplary embodiments, the same reference numerals denote the same or similar components.
The application server 102B in some embodiments belongs to a content provider system operated by a content provider (sometimes also called service provider). The content provider system may provide an application service (such as an instant messaging, IM, service or a video or audio streaming service), possibly over the Internet 102A. In some variants, the application server 102B is configured to provide an Over-The-Top (OTT) application service. Such an OTT application service generates OTT network traffic to transport video content or audio content (typically in a session context).
As shown in
Each of the two domains 104, 106 comprises a user plane for transporting application traffic and a control plane for transporting control signalling. The access network domain 106 may have a cellular or a non-cellular configuration. In some variants, the access network domain 106 comprises multiple base stations or wireless access points. The services provided by the core network domain 102 include core network processing functions 110 for network traffic exchanged between the external domain 102 and the mobile devices 108, via the access network domain 106. Exemplary core network processing functions 110 include Quality of Service enforcement, charging, mobility-related services, and so on.
Also provided by the core network domain 104 is a reporting function 112. The reporting function 112 can be a logical entity or a hardware entity. It can be part of an NWDAF Network Function (NF) in 5G communications networks or of a Packet Gateway (PGW) node in LTE/4G communications networks.
The reporting function 112 is configured to report information included in data records generated for network traffic activities of the mobile devices 108. Such network traffic activities may comprise a particular mobile device 108 streaming video content from a particular application server 102A, visiting over the Internet 102 an online shopping or news website on another application server 102A, and so on.
The data records accessed by the reporting function 112 for filtering and analyzing the information to be reported are in one variant received from the core network processing functions 110. In another variant, these data records are generated locally by the reporting function 112 based on information received from the core network processing functions 110. In the embodiment illustrated in
The reporting function 112 is configured to generate its reports responsive to dedicated monitoring requests. As illustrated in
In the following, an apparatus embodiment of the reporting function 112 of
In the apparatus embodiment illustrated in
The reporting function 112 further comprises an input interface 206 and an output interface 208. The two interfaces 206, 208 are configured for communication with the core network processing functions 110 on the one hand and the function or apparatus 114 on the other hand.
The processor 202 of the reporting function 112 is configured to report information included in the data records, and the data records are generated for network traffic activities of the plurality of mobile devices 108. Each data record pertains to a particular network traffic activity of a particular mobile device 108. For the particular traffic activity (e.g., a particular content streaming session) multiple data records may be generated (and may be stored in the database 112A). For example, each data record may correspond to a particular PDU generated, in the context of the particular traffic activity, for transmission from the external domain 102 via the core network domain 104 and the access network domain 106 to the particular mobile device 108 (or vice versa).
Each traffic activity is associated with at least one traffic type. The traffic type(s) may be defined by the content provided by a particular application server 102B involved in a particular traffic activity. If, for example, the application server 102B is operated by Netflix, the traffic type may be one (or more) of content streaming, video streaming, and Netflix traffic (in decreasing order of logical hierarchy).
Each data record analysed by the processor 202 in a reporting context includes a traffic type of a particular traffic activity of a particular mobile device 108 (or multiple such types), a timestamp of the traffic activity, and an identifier of the mobile device 108. The identifier may, for example, take the form of an International Mobile Subscriber Identity (IMSI). The data record may include further information, such as a geographical location of the mobile device 108 during the traffic activity. This geographical location may be indicated in the data record via the cell identifier of the particular cell of the access network domain 106 serving the mobile device 108 during the traffic activity.
Now referring to the flow diagram 300 of
In some variants, the monitoring request includes one or more further filtering criteria for the monitoring reports to be generated by the reporting function 112, such as a predefined period of time (monitoring period). The period of time may be indicated in a relative format (e.g., day, week, month) or in an absolute format (e.g., 12 May 2020 - 16:00 to 17:00, or today, or now, or yesterday). The predefined period of time, in particular when indicated in a relative format, may define a reporting frequency. The predefined period of time may be a time instant. When not defined in the monitoring request, the monitoring period may be a default setting of the reporting function 112, or may dynamically be defined (e.g., based on network load, with a higher network load leading to a more frequent reporting and, thus, a shorter monitoring period).
In such or alternative variants, the monitoring request may optionally specify a geographical area to be monitored (i.e., for which the report(s) is (are) to be generated). The specification of the geographical area may include at least one of the following parameters: one or more ZIP codes, one or more cell identifiers, and a name of the geographical area (e.g., a town name).
The method further comprises calculating, by the processor 202, from the data records a number of mobile devices 108 having, within a given monitoring period, traffic activities that fulfil the certain conditions (step 304 in
Condition iii) helps to avoid counting, for a particular mobile device 108 and a particular monitoring period, multiple data records associated with the same traffic activity (and the same traffic type) multiple times and, thus, falsifying the calculation of the actual number of mobile devices 108. Such a falsification may in particular occur in case the data records are of a highly granular nature (e.g., generated on a per-PDU basis), whereas the monitoring period is not an instant in time but has an actual duration. Therefore, multiple data records that concurrently fulfil conditions i) and ii) are only considered once per monitoring period and per mobile device 108. For example, out of a set of data records that fulfil conditions i) and ii), only one data record (e.g., the first within the monitoring period) is actually considered to increment the current count of the number of mobile devices 108, and the other data records are disregarded and, thus, do not lead to a (further) incrementation of that number.
In case the monitoring request further specifies a geographical area to be monitored, the following further condition is considered when calculating the number of mobile devices 108 in step 304:
iv) the geographical location of the traffic activity falls within the geographical area.
In case the geographical location is indicated via a cell identifier in the data records, the processor 202 may consult a mapping between cell identifiers and geographical areas to test condition iv).
The method further comprises returning, in response to the monitoring request, a monitoring report that is based on the calculated number of mobile devices 108 (see step 306 in
In one example, the reporting function 112 reports current (“instantaneous”) demand as classified by the monitoring type indicated in the monitoring request. In another example, the reporting function 112 uses historical data records to predict future demand (e.g., by use of time-series analysis). Demand can in some implementations be defined as “interest” for specific digital content conforming to the indicated monitoring type. As explained above, the “interest” is quantified by the (e.g., averaged) number of mobile devices 108 for a specific period of time, optionally in a specific geographical area.
In some variants, only active mobile devices 108 are counted. An active mobile device 108 is a mobile device 108 which has established a Radio Resource Control (RRC) connection and actively transmits and receives data. In case of a 5G communications network 100, the mobile device 108 is characterized by RRC_ACTIVE state. In case of an LTE/4G communications network 100, mobile device 108 is in RRC_CONNECTED state and undergoing a User Data Transaction. The information about the state a mobile device 108 is in is known from information obtained from the access network domain 106. As will be appreciated, only active mobile devices 108 have established sessions and can produce data traffic. Such a type of counting limited to active mobile devices 108 is performed at least for some use cases in which one would like to avoid counting idle mobile devices 108, which were forgotten by their users and are in no position to transmit data.
Therefore, for a given monitoring period of duration td (as indicated, e.g., in a monitoring request), an interest I for a particular monitoring type and at a particular geographical area can be represented (and reported) as I = {location, UEnum}, where location (optional) is the geographical area and UEnum the (possibly averaged) number of mobile devices 108 in that geographical area (as mobile devices 108 may join and leave the location within td).
The geographical area can be the actual location of a cell of the access network domain 106 where the mobile devices 108 are attached to, or a bounding box that includes the location of the cell and an approximate coverage area. Also, depending on the implementation, the geographical area can include multiple cells, in which case a central point is chosen or a larger bounding box. The so-called geolocation of a cell serving a mobile device 108 as identified by an operator-unique “cell identifier” or “cell-ID” is known to a network operator system, as that system holds both information about the location of the cell and the mobile devices 108 attached to it. The responsible node in LTE as an exemplary 4G communications network 100 is the Mobility Management Entity (MME), and it is the Access and Mobility Functions (AMF) in a 5G communications network 100.
In order to be valid for a report, a mobile device group must include at least one mobile device 108, for at least a portion of td, that fulfils the filtering condition(s) defined in the monitoring request. To report an average number of mobile devices 108, mobile devices 108 can be sampled periodically within td (e.g., for a 100 data points sample, a periodical sampling every td/100 can be implemented).
In the monitoring report, the interest I can be augmented with one or more so-called insights: I = {location, UEnum, insights}, where insights = list<type, value>. The insights may at least implicitly be defined by the monitoring type specified in the monitoring request (e.g., the parameter “type” in the data structure <type, value> may correspond to the monitoring type specified in the monitoring request. In some variants, UEnum is reported per data structure <type, value>.
Exemplary, non-limiting types of insights and, thus, monitoring types are discussed below.
A first insight/monitoring type is called “Popular Destination”. To this end, the reporting function 112 analyzes PDU headers to identify (as traffic type) a destination domain name in the PDU. The reporting function may additionally group the destination domain names under a higher-level generic traffic type, as schematically illustrated for a general <type, value> data structure in
This first insight is about popular PDU destinations (e.g., what generic or specific type(s) of application servers 102B are actually contacted by the mobile devices 108). This analysis can be based on application-layer PDU analysis, and specifically on the domain name of the destination (for example by analysis of HTTP PDU headers). The analysis can use a thesaurus of domain name categories (see, for example, https://tools.zvelo.com - categories could be social media, news sites, vehicle manufacturers, corporate websites, etc.), in order to establish user interest.
Consider the following examples:
Since user A, B, C share the same interest as per the definition above, then the associated group has an insight of type “popular destination” and value “technology websites”. Note that the corresponding monitoring report may include multiple values for the reporting type “popular destination”, wherein for each reporting type a dedicated (e.g., averaged) number of mobile devices 108 is reported. Note further that the identifiers of the mobiles devices 108 (e.g., IMSIs) and explicit website names, which could be used to identify users A, B and C, are not included in the monitoring report.
A second insight/monitoring type is called “Popular Application Categories”. Here, PDU headers are analyzed to identify the applications generating the associated traffic activities, and to grouping of applications under one or more generic traffic activities as values. This insight uses application identifiers as traffic types in order to classify the applications in regard to a generic traffic activity, similar to the previous example of “popular destinations” idea. Again, the actual application and the actual mobile device 108 using the application need not be disclosed in the monitoring report. Over time, this insight can give an estimation of what type of applications are popular in a specific area and/or time. Extracting application identifier from possibly encrypted PDUs may be done a specified in https://www.caida.org/research/traffic-analysis/classification-overview/.
Consider the following examples:
Since users A, B, C share the same interest as per the definition above, then group has an insight of type “popular application” and value “email”. Again, mobile device identifiers (e.g., IMSIs) and explicit application names, which could be used to identify mobile device users, are not exposed.
A third insight/monitoring type is called “Short term group propensity”. Here, the traffic generated from/to mobile devices 108 is analyzed. For example, if a user of a mobile device 108 is streaming video from YouTube it is more likely that (s)he is going to continue to request more video traffic for some period of time in the future. If a user is streaming Netflix content, then it is also likely that the user is going to request video traffic but for a longer period of time since video streams on Netflix tend to be longer. Furthermore, even if a mobile device 108 has stopped streaming any video (s)he is more likely start streaming something again compared to a mobile device 108 which was completely idle, or a mobile device 108 that was used for web browsing. Besides temporal correlation, the same mobile device 108 in the same geographical arear might have typical pattern of data consumption. For example, when a user is commuting (s)he might be typically watching a certain television program.
Consider the following examples:
Since users A, B, C share the same interest as per the definition above, group has an insight of type “group propensity” and three values “video consumption, 88%, 10 min”, where the percentage denotes a confidence level of a machine learning algorithm for a prediction, and the time denotes how long the prediction is valid for a given group of mobile devices. Again, mobile device identifiers (e.g., IMSIs) and explicit application names, which could be used to identify mobile device users, are not exposed in the resulting monitoring report.
A fourth insight/monitoring type is called “Engagement Aware Group Profile”. Here, it is an advanced analytic service which can report aggregated preferences of the group of mobile devices 108 connected to a given cell. The profiles with preferences and interests of all connected mobile devices 108 are combined to create a group profile. When combining profiles, one can weight profiles of different mobile devices 108 based on the level of interaction of the user with his/her mobile device 108. Users who are in a call, watch videos or do active browsing would be much less engaged and even aware about what is going on around them compared to users who keep their mobile devices 108 idle. Interactive users of their mobile devices 108 would contribute less to the group profile in the area. This type of engagement aware group profile information could be of interest for providers of onscreen targeted advertisement. This type of advertisement becomes common in public transport areas like buses, trains, stations, stops, etc. People there are densely concentrated and stay static with respect to advertisement media. Also it is becomes common that ultra-small cells like pico-cells are installed in the public transport areas making UE localization very precise.
Consider the following examples:
Since users A, B, C share the same interest as per the definition above, the resulting mobile device group has an insight of type “Engagement Aware Group Profile” and of values “12%, 10 min”, where the percentage denotes a confidence of a machine learning algorithm regarding how engaged the users in the group will be, and the time indicates how long the prediction is valid for the given mobile device group. Again, mobile device identifiers (e.g., IMSIs) and explicit application names, which could be used to identify mobile device users, are not exposed in the resulting monitoring report.
As has become apparent from the last two examples, the monitoring report may include one value indicative of a prediction made by a machine learning algorithm based on the selected data records that fulfil certain conditions. The monitoring report may include a further value indicative of a temporal validity of the prediction.
The table 500 of
The diagram of
As illustrated in
The table of
For each application, there exist a Packet Flow Description (PFD) which contains information on where to route IP traffic under this application ID (e.g., a serverside IP address and port number, or URI/URL, or domain name, etc.). PFDF 104D is a node that allows storing and enforcing PFDs. It has a northbound interface to SCEF 104C and southbound interface to PGW (PCEF) 104E.
On the other hand, SCEF 104C allows an Application Server (AS) 114A - which is a function that may or may not be within mobile network operator’s administrative domain (e.g., it could be located on an enterprise server in the external domain 102), to securely subscribe to monitoring events around UE connectivity aspects (such as the ones mentioned in the introduction). The process includes a “Monitoring Request” message submitted to SCEF 104C by AS 114A, and subsequently SCEF 104C internally polls nodes such as MME 104A and PCRF (not shown) in order to retrieve the information requested. When new information is available for an event, SCEF 104C reports it to AS 114A using a “Monitoring Report” message. The “Monitoring Request” message and the “Monitoring Report” message as such are defined in the applicable standard (see, e.g., 3GPP TS 23.682 – 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements to facilitate communications with packet data networks and applications (Release 13)). The same process is also available in 5G communications networks and NEF.
The technical means in the LTE/4G communications network 100 of
To overcome these limitations, a new function called User Data Insight Generator Function (UDIGF) is proposed to be added to the core network domain 104. UDIGF may implement some or all of the operations of the reporting function 112 discussed above and, thus, will in the following be denoted by the same reference numeral in signalling diagrams 8, 9A and 9B. UDGIF 112 is responsible for generating insights from user data flows, anonymizing these insights and exposing them, for example via SCEF 104C, to interested third parties. UDIGF 112 may be placed between PGW (PCEF) 104E and SCEF 104C, for example collocated with PFDF 104D.
UDIGF 112 comprises five elements, or sub-functions, 112A to 112E as illustrated in
A resolution sub-function 112B retrieves policy rule enforcement actions from PCEF on PGW 104E. Whenever a PDU (e.g., an IP packet) from a mobile device 108 or the Internet 102A (i.e., towards a mobile device 108) arrives, PCEF triggers a policy action. This can be for example a policy triggered from an SDF as shown in the table of
A storage sub-function 112A (realized, e.g., in the form of a database 112A as illustrated in
An analysis sub-function 112C analyzes the generated policy rules, as stored in by the storage sub-function 112A, and produces insights. The produced insights are then provided to an exposure sub-function 112D for dispatchment to SCEF 104C and subsequently to AS 114A. The exposure sub-function 112D implements a monitoring request/monitoring report interface (e.g., similar to functionality in T6a as described in 3GPP TS 23.682). Specifically, the exposure sub-function 112D retrieves analysis insights and reports them to a requesting AS 114A.
A geographical database sub-function 112E provides a mapping between cell identifiers and geographical locations (as defined, e.g., by ZIP codes, geographical names, or otherwise).
As illustrated in the signalling diagram of
Subsequently, resolution sub-function 112B will ask MME 104A (AMF in 5G) about the cell identifier (Cell ID) associated with the identifier of the mobile device 108 indicated in the Policy Rule Enforcement message. This information is known to the MME 104A as whenever a mobile device 108 attaches to the RAN domain 106 and/or handovers from another cell, this information is part of the authentication process (LTE Attach) and will be stored by MME 104A. For an open-source database of cell identifiers, see https:/opencellid.org – the idea is that the cell identifier is also a designator of the geographical location of the mobile device 108 (with some granularity). Once the cell identifier is retrieved, then the information provided by PCEF and the cell identifier are timestamped with current date and time and stored as a data record in the in storage sub-function 112A. In use cases where the geographical location of the mobile device 108 is not of importance, the Policy Rule Enforcement message (or information included therein) may directly be associated with a time stamp and stored as a data record in the in storage sub-function 112A.
In parallel to the data acquisition process as illustrated in
The exposure sub-function 112D of UDIGF 112 fully implements the monitoring request/monitoring response and monitoring report publish/subscribe interface as defined in 3GPP TS 23.682. MME 104A also implements the same type of interface.
As shown in
The exposure sub-function 112D forwards the monitoring type (together with the optional parameters monitoring period and geographical area) with a Generate Insights message to the analysis sub-function 112C. The analysis sub-function 112C acknowledges that message back to SCEF 104C, which forwards the acknowledgement to the requesting AS 114A.
As explained above, the monitoring type indicated as a code in the monitoring request corresponds to the insight generated. The exemplary insights supported in this embodiment are (description – monitoring type code in quotation):
From this point and onwards, the analysis sub-function 112C performs analysis on one or both of incoming (current) and historical data to generate insights. This process can be asynchronous to the monitoring request, meaning that an analysis can take place whenever a new data record is available to the storage sub-function 112A, or periodically (e.g., every 2 minutes, depending on the monitoring period specified on the monitoring request or otherwise). As said, the monitoring request may also specify the duration of the monitoring (e.g., in hours or days).
As part of the analysis, the analysis sub-function 112C retrieves the data records to be analyzed from the storage sub-function 112A. The data records to be retrieved may be defined, inter alia, by the monitoring period. As indicated in the last signalling step of
Now reference is made to the signalling diagram of
In case a geographical area was specified in the monitoring request, the analysis sub-function 112C, for each data record (list entry), consults the geographical database sub-function 112E to determine, for the cell identifier in the data record, the associated geographical location. The analysis sub-function 112C then compares the geographical location thus determined with the geographical area as specified in the monitoring request and generates the insights (as discussed above) only on the basis of data records having cell identifiers that map on geographical locations included in the geographical area. The insight generation will be performed in accordance with the specified monitoring type as explained above (see also step 304 in
The above idea discussed introducing UDIGF 112 and extending PGW reporting capabilities to report information on every PDU filtered by PCEF. Evidently, this kind of filtering and reporting puts computational overhead on PGW 104E and can affect its performance, thus potentially impacting network traffic flows on the data plane. One idea in order to address this issue is to use two PGWs 104E, one for “regular” network data traffic and another for traffic analysis and insight generation as discussed herein (see
Another idea would be to add a grace period during initial attach of a mobile device 108 to a particular mobile operator network 100. This grace period could apply to all mobile devices 108 and can be any predefined period of time between, for example, a few minutes to a few hours. During this grace period, the traffic of a particular mobile device 108 is routed through the PGW 104E that reports the filtered network data traffic as shown in
The data records are provided asynchronously when available. When NWDAF 124 receives all data records for a period of time equal to td (as outlined above), it processes those data records according to the use case (insight/monitoring type) as discussed above and reports to SCEF (not shown), which then notifies the User 114A. The notification payload includes information about the insight and an associated value. Note that it is possible for to subscribe to more than one insight.
It will be appreciated that the present disclosure has been described with reference to exemplary embodiments that may be varied in many aspects. As such, the present invention is only limited by the claims that follow.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2020/066597 | 6/16/2020 | WO |
