Abstract:
A two-stage anonymization process is applied to monitored network traffic in which unique user identifiers, such as the MSISDN (Mobile Station International Subscriber Directory Number), are extracted from the traffic and anonymized to generate an ASI (anonymized subscriber identifier). A strictly random RSI (random subscriber identifier) is generated and used to replace the ASI. The RSI is generated upon a first occurrence of an ASI and stored in a lookup table for utilization upon subsequent ASI occurrences. Use of the strictly random RSI enables various studies and analyses of user behavior to be performed at a heightened level of privacy protection as compared with conventional anonymization schemes that do not utilize strictly random identifiers.

Description:
BACKGROUND 
       [0001]    Communication networks provide services and features to users that are increasingly important and relied upon to meet the demand for connectivity to the world at large. Communication networks, whether voice or data, are designed in view of a multitude of variables that must be carefully weighed and balanced in order to provide reliable and cost effective offerings that are often essential to maintain customer satisfaction. The ability to analyze network activities and manage information gained from the accurate measurement of network traffic characteristics is generally important to ensure successful network operations. However, for reasons of security and privacy, monitored network traffic typically needs to be irreversibly anonymized so that Personally Identifiable Information (PII) about users is not directly or indirectly revealed. While current anonymization methodologies often perform satisfactorily, there are some instances where stronger privacy protection is needed. 
         [0002]    This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above. 
       SUMMARY 
       [0003]    A two-stage anonymization process is applied to monitored network traffic in which unique user identifiers, such as the MSISDN (Mobile Station International Subscriber Directory Number), are extracted from the traffic and anonymized to generate an ASI (anonymized subscriber identifier). A strictly random RSI (random subscriber identifier) is generated and used to replace the ASI. The RSI is generated upon a first occurrence of an ASI and stored in a lookup table for utilization upon subsequent ASI occurrences. Use of the strictly random RSI enables various studies and analyses of user behavior to be performed at a heightened level of privacy protection as compared with conventional anonymization schemes that do not utilize strictly random identifiers. 
         [0004]    In various illustrative examples, the ASI is generated by a network probe associated with a network intelligence solution (NIS) arranged for monitoring a mobile communications network such as a GPRS (General Packet Radio Service) network. The ASI is generated by applying a cryptographic hash function such as HMAC-SHA1 (Hash-based Message Authentication Code—Secure Hash Algorithm 1) to the MSISDN twice in succession using two separate keys. The ASI is inserted into GTP (GPRS Tunneling Protocol) traffic and received at the NIS which generates an RSI using a collision-free random code generator. The associated ASI and RSI are stored in an ASI/RSI lookup table so that the RSI can be persisted for subsequent occurrences of the ASI that are received at the NIS. Advantageously, such persistence enables behavioral metrics such as unique user visits to be collected while preserving heightened privacy protections. 
         [0005]    The ASI/RSI lookup table can be cleaned-up by an automated process that loops through the table on a periodic basis to remove inactive ASIs. The RSI may be periodically reset to limit individual RSI persistence by subjecting the RSI to a time-to-live (TTL) value where the association between a given ASI and RSI is deleted when the TTL value is exceeded using an automated process that loops through the lookup table. In this case, a new RSI is generated even when the ASI has been previously seen at the NIS. A management interface can be locally instantiated at the NIS or implemented remotely to provide an administrator with tools to manage various aspects of the two-stage anonymization process. For example, parameters used by the table clean-up and RSI reset procedures can be specified at the management interface, the ASI/RSI table may be periodically saved to persistent storage, and process logging and monitoring functions may be controlled. 
         [0006]    This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. 
     
    
     
       DESCRIPTION OF THE DRAWINGS 
         [0007]      FIG. 1  shows an illustrative mobile communications network environment that facilitates access to resources by users of mobile equipment and with which the present system and method may be implemented; 
           [0008]      FIG. 2  shows an illustrative web browsing session which utilizes a request-response communication protocol; 
           [0009]      FIG. 3  shows an illustrative NIS that may be located in a mobile communications network or node thereof and which taps information from traffic flowing in the network; 
           [0010]      FIG. 4  shows illustrative generation of an anonymized subscriber identifier (ASI) that is inserted into GTP (GPRS Tunneling Protocol where GPRS is an acronym for General Packet Radio Service) session data prior to the data being received at the NIS; 
           [0011]      FIG. 5  shows various illustrative types of IDs (identifiers) that expose Personally Identifiable Information (PII) that may be extracted from GTP traffic and utilized as inputs to the ASI generation; 
           [0012]      FIG. 6  shows illustrative generation of a random subscriber identifier (RSI) at the NIS; 
           [0013]      FIG. 7  shows an illustrative management interface to an RSI generator; and 
           [0014]      FIG. 8  is a flowchart of an illustrative method for two-stage anonymization of mobile network subscriber personal information; 
       
    
    
       [0015]    Like reference numerals indicate like elements in the drawings. Unless otherwise indicated, elements are not drawn to scale. 
       DETAILED DESCRIPTION 
       [0016]      FIG. 1  shows an illustrative mobile communications network environment  100  that facilitates access to resources by users  105   1, 2 . . . N  of mobile equipment  110   1, 2 . . . N  and with which the present arrangement may be implemented. In this example, the resources are web-based resources that are provided from various websites  115   1, 2 . . . N . Access is implemented, in this illustrative example, via a mobile communications network  120  that is operatively connected to the websites  115  and/or other resources via the Internet  125 . Accordingly, the users  105  are typically subscribers to a service that operates in whole or part over the mobile communications network  120 . It is emphasized that the present arrangement is not necessarily limited in applicability to mobile communications network implementations and that other network types that facilitate access to the World Wide Web including local area and wide area networks, PSTNs (Public Switched Telephone Networks), and the like that may incorporate both wired and wireless infrastructure may be utilized in some implementations. 
         [0017]    In this illustrative example, the mobile communications network  120  may be arranged using one of a variety of alternative networking standards such as GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System), GSM/EDGE (Global System for Mobile Communications/Enhanced Data rates for GSM Evolution), CDMA (Code Division Multiple Access), CDMA2000, or other 2.5G, 3G, 3G+, or 4G (2.5 th  generation, 3 rd  generation, 3 rd  generation plus, and 4 th  generation, respectively) wireless standards, and the like. 
         [0018]    The mobile equipment  110  may include any of a variety of conventional electronic devices or information appliances that are typically portable and battery-operated and which may facilitate communications using voice and data. For example, the mobile equipment  110  can include mobile phones (e.g., non-smart phones having a minimum of 2.5G capability), e-mail appliances, smart phones, PDAs (personal digital assistants), ultra-mobile PCs (personal computers), tablet devices, tablet PCs, handheld game devices, digital media players, digital cameras including still and video cameras, GPS (global positioning system) navigation devices, pagers, electronic devices that are tethered or otherwise coupled to a network access device (e.g., wireless data card, dongle, modem, or other device having similar functionality to provide wireless Internet access to the electronic device) or devices which combine one or more of the features of such devices. Typically, the mobile equipment  110  will include various capabilities such as the provisioning of a user interface that enables a user  105  to access the Internet  125  and browse and selectively interact with web pages that are served by the Web servers  115 , as representatively indicated by reference numeral  130 . 
         [0019]    The network environment  100  may also support communications among machine-to-machine (M2M) equipment and facilitate the utilization of various M2M applications. In this case, various instances of peer M2M equipment (representatively indicated by reference numerals  145  and  150 ) or other infrastructure supporting one or more M2M applications will send and receive traffic over the mobile communications network  120  and/or the Internet  125 . In addition to accessing traffic on the mobile communications network  120  in order to classify web pages and domains in an automated manner, the present arrangement may also be adapted to access M2M traffic traversing the mobile communications network. Accordingly, while the methodology that follows is applicable to an illustrative example in which Internet usage of mobile equipment users is measured, those skilled in the art will appreciate that a similar methodology may be used when M2M equipment is utilized. 
         [0020]    A network intelligence solution (NIS)  135  is also provided in the environment  100  and operatively coupled to the mobile communications network  120 , or to a network node thereof (not shown) in order to access traffic that flows through the network or node. In alternative implementations, the NIS  135  can be remotely located from the mobile communications network  120  and be operatively coupled to the network, or network node, using a communications link  140  over which a remote access protocol is implemented. In some instances of remote operation, a buffer (not shown) may be disposed in the mobile communications network  120  for locally buffering data that is accessed from the remotely located NIS. 
         [0021]    It is noted that performing network traffic analysis from a network-centric viewpoint can be particularly advantageous in many scenarios. For example, attempting to collect information at the mobile equipment  110  can be problematic because such devices are often configured to utilize thin client applications and typically feature streamlined capabilities such as reduced processing power, memory, and storage compared to other devices that are commonly used for web browsing such as PCs. In addition, collecting data at the network advantageously enables data to be aggregated across a number of instances of mobile equipment  110 , and further reduces intrusiveness and the potential for violation of personal privacy that could result from the installation of monitoring software at the client. The NIS  135  is described in more detail in the text accompanying  FIGS. 3 and 6  below. 
         [0022]      FIG. 2  shows an illustrative web browsing session which utilizes a protocol such as HTTP (HyperText Transfer Protocol) or SIP (Session Initiation Protocol). In this particular illustrative example, the web browsing session utilizes HTTP which is commonly referred to as a request-response protocol that is commonly utilized to access websites. Access typically consists of file requests  205   1, 2 . . . N  for pages or objects from a browser application executing on the mobile equipment  110  to a website  115  and corresponding responses  210   1, 2 . . . N  from the website server. Thus, at a high level, the user  105  interacts with a browser to request, for example, a URL (Uniform Resource Locator) to identify a site of interest, then the browser requests the page from the website  115 . When receiving the page, the browser parses it to find all of the component objects such as images, sounds, scripts, etc., and then makes requests to download these objects from the website  115 . 
         [0023]      FIG. 3  shows details of the NIS  135  which is arranged, in this illustrative example, to monitor network traffic in the mobile communications network  120  in order to perform a variety of analyses  305 . Such analyses  305 , as respectively indicated by reference numerals  310 ,  315 ,  320 , and  325  in  FIG. 3 , illustratively include monitoring Internet usage by the users  105 , monitoring user behaviors, generating various reports, and performing other analytical or monitoring functions as may be required. In some implementations, the NIS  135  will perform deep packet inspection of the monitored traffic in order to facilitate such analyses. It is emphasized that the exemplary analyses shown in  FIG. 3  are intended to be illustrative and that the number and particular analyses that are utilized in any given application can differ from what are shown. 
         [0024]    The NIS  135  is typically configured as one or more software applications or code sets that are operative on a computing platform such as a server  335  or distributed computing system. In alternative implementations, the NIS  135  can be arranged using hardware and/or firmware, or various combinations of hardware, firmware, or software as may be needed to meet the requirements of a particular usage scenario. As shown, network traffic typically in the form of IP (Internet Protocol) packets  330  flowing through the mobile communications network  120 , or a node of the network, is captured via a tap  340 . 
         [0025]      FIG. 4  shows details of operations that may be performed at the tap  340 . At a mirror port  405  conforming to the Gn (i.e., Ethernet) interface in the GPRS protocol, identification and behavioral data  410  are extracted from GTP (GPRS Tunneling Protocol) traffic at a Gateway GPRS Support Node (GGSN)  415  along some portion  420  of the mobile communications network. As shown in  FIG. 5 , the data  410  typically includes some form of indirect Personally Identifiable Information (PII)  505  such as the MSISDN (Mobile Station International Subscriber Directory Number)  510  associated with mobile equipment  110  employed by a network user  105  ( FIG. 1 ), or alternatively, the IMEI (International Mobile Equipment Identity)  515 , or IMSI (International Mobile Subscriber Identity)  520 . 
         [0026]    Returning to  FIG. 4 , an irreversible anonymization process  425  is implemented at an NIS probe  430  in the first anonymization stage of the present arrangement. The process  425  applies a cryptographic hash function  435 , such as the known HMAC-SHA1 hash (Hash-based Message Authentication Code—Secure Hash Algorithm 1) successively to the MSISDN, in this example, using two separate keys  440  and  445 , to generate anonymized code referred to here as the anonymized subscriber identifier (ASI)  450 . The ASI  450  is inserted into the GTP session data  455  at the NIS probe  430  before the data is received at the NIS  135 , as shown in  FIG. 5 . 
         [0027]      FIG. 6  shows the second stage of the present arrangement in which a random subscriber identifier (RSI) is generated at the NIS  135 . Using an RSI generator  605  in the NIS  135  which may be embodied, for example, as a collision free random code generator executing in volatile memory  610 , an RSI  615  is implemented as random code which replaces the ASI  450  received at the NIS  135 . In this particular example, the ASI  450  is represented in exemplary hexadecimal form, as shown in  FIG. 6  by reference numeral  620 . When the ASI  450  received at the RSI generator  605  has not been previously seen (i.e., is unknown), then a new RSI is generated and the associated ASI/RSI pair is written to a lookup table  625 . The associated RSI is represented in exemplary hexadecimal form by reference numeral  630 . 
         [0028]    The lookup table  625  will typically be implemented in volatile memory  635  and will store different ASI/RSI pairs  640   1, 2 . . . N  where the size of the table can vary by implementation. In addition to containing the values of ASI/RSI pairs, in some implementations, the lookup table  625  can store additional fields of information such as record creation time and last record read time on a per-ASI/RSI pair basis. 
         [0029]    When an ASI is received at the RSI generator  605  that has been seen before and is thus known (i.e., is already present in the ASI/RSI lookup table  625 ), then the RSI associated with that particular ASI is reused. Among other applications, such reuse enables RSI persistence so that reports including metrics such as unique visits, for example, can be generated. The RSI  615 , whether newly generated by the generator  605  or persisted from the lookup table  625 , can be archived in non-volatile memory  645  such as a hard-disk drive or other stable storage in the form of comma-separated value (CSV) files  650 , for example. 
         [0030]    In some applications, excessive individual RSI persistence may be avoided by limiting the time for which an ASI-RSI association remains valid. Here, an RSI may be assigned a time-to-live (TTL) value that when exceeded will cause the RSI to be deleted from the lookup table  625 . In this case, when an ASI is received at the RSI generator  605 , even if previously seen and known, a new RSI will be generated. An automated RSI-reset process can typically be used to periodically loop through the lookup table  625  and delete the ASI-RSI associations for which the RSI has exceeded its TTL value. For example, old records are selected for deletion using an age calculation in which the “record creation time” field from the ASI/RSI lookup table is compared to the current time. When the calculated age exceeds the defined TTL the relevant records are removed from the table. 
         [0031]    The TTL value may be configured to be specifiable in some cases by an administrator or other qualified personnel having access to the NIS  135 . In a similar manner, an automated table clean-up process may be run periodically to remove inactive ASI entries from the lookup table  625 . For example, inactive records are selected for deletion using an age calculation in which the “last record time” field from the ASI/RSI lookup table is compared to the current time. When the calculated age exceeds some arbitrary (or administrator-specified) threshold, the records are removed from the table. 
         [0032]    An ASI/RSI lookup table “save” functionality may be optionally enabled in order to prevent the loss of ASI-RSI association when the NIS  135 , or particular processes/applications running on it, are started or restarted. In this case, the ASI/RSI lookup table  625  is periodically written to an encrypted file  655  in encrypted non-volatile memory  660  (such as a hard-disk drive or other stable storage) and then loaded into volatile memory upon startup/restart, as indicated by the arrow  665  in  FIG. 6 . A conventional encryption algorithm such as AES-128 (Advanced Encryption Standard using a 128 bit cryptographic key) may be used to perform the encrypted write. 
         [0033]      FIG. 7  shows an illustrative management interface  705  exposed by the NIS  135  to an administrator  710 , or other qualified personnel, to the RSI generator  605 . The management interface  705  provides a set of tools to enable the administrator  710  to perform a variety of management functions pertaining to the present two-stage anonymization process. An RSI reset function  715  can be configured to enable the administrator  710  to specify the value of the TTL in some convenient time unit (e.g., seconds). The RSI reset function  715  may also allow the administrator to specify the periodicity of the looping of the RSI reset process through the ASI/RSI lookup table  625  ( FIG. 6 ). A table clean-up function  720  can be configured to enable the administrator  710  to specify the threshold age at which inactive ASI entries are removed from the table. The table clean-up function  720  may also allow the administrator to specify the periodicity of the looping of the table clean-up process through the ASI/RSI lookup table. 
         [0034]    A save to encrypted storage function  725  may enable the administrator  710  to set an option to allow the ASI/RSI lookup table  625  to be saved as an encrypted file  655  to non-volatile memory  660  ( FIG. 6 ). The administrator may also specify the periodicity of the save to non-volatile memory using the save function  725  in some cases. Process logging and monitoring functions, respectively indicated by reference numerals  730  and  735 , can also be provided by the management interface  705  to enable the administrator  710  to specify parameters pertaining to logging and monitoring of the present two-stage anonymization process. A configuration file  740  may be utilized to store various parameters associated with the two-stage anonymization process and/or the tools included in the management interface  705 . 
         [0035]      FIG. 8  shows a flowchart of an illustrative method  800  for two-stage anonymization of mobile network subscriber personal information. The method  800  may be implemented, for example, using the elements shown in  FIGS. 4 ,  6 , and  7  and described in the accompanying text. The method begins at block  805 . At block  810 , GTP traffic flowing across a network or network node is tapped to collect IP packets. At block  815 , a unique user ID, such as the MSISDN is extracted from the GTP traffic at the NIS probe  430 . An ASI is generated by application of two successive cryptographic hash functions, such as HMAC-SHA1, to the extracted ID at block  820 . The ASI is inserted at the NIS probe  430  into the GTP session data prior to being sent to the NIS  135  for subsequent processing at block  825 . 
         [0036]    At decision block  830 , if the ASI received at the RSI generator  605  in the NIS  135  has not been seen previously (i.e., is unknown), then a new RSI is generated at block  835  and the ASI-RSI association is stored in the ASI/RSI lookup table  625  at block  840 . If the received ASI is known, then control passes to decision block  845  where it is determined if the RSI associated with the received ASI has exceeded its TTL. If it has, then a new RSI is generated at block  835 . If the TTL has not been exceeded, then at block  850 , the RSI that is associated with the received ASI is persisted from the ASI/RSI lookup table  625 . 
         [0037]    At block  855 , the RSI is written to non-volatile memory  645 , for example in one or more CSV files  650 , for use in subsequent analyses. Such analyses may include those shown in  FIG. 3  and described in the accompanying text. At block  860 , the ASI/RSI lookup table can be periodically saved as an encrypted file  655  in non-volatile memory  660 . At block  865 , the automated RSI reset and/or table clean-up processes are performed periodically. At block  870 , one or more tools can be exposed through the management interface  705  to enable an administrator, or other qualified personnel to control various parameters used in the present two-stage anonymization process. At block  875 , the ASI/RSI lookup table can be loaded from non-volatile memory upon startup or restart of a computing platform upon which the two-stage anonymization process executes. 
         [0038]    It is noted that the method steps shown at blocks  855  to  875  can be performed in a different order from what is shown in  FIG. 8 . The method ends at block  880 . 
         [0039]    Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.