Method in a network node for classifying in-vehicle data traffic and network node - Patents.com

Abstract

A method for classifying in-vehicle data traffic is provided.

Description

[Technical field]

[0001] The present invention relates to a method and system for analyzing network traffic, and more particularly to a method and system for providing analysis of data traffic between a vehicle and a data service provider. [Background technology]

[0002] In-car Internet traffic usage is increasing every year. Offerings such as video and audio streaming services, navigation systems, and sharing of user-generated content are becoming ubiquitous. Many new cars are delivered with Internet connectivity. Other ways to enable this include the use of third-party Wi-Fi devices that can be retrofitted to the vehicle's On-Board Diagnostics (OBD) system. Regardless of the connection method, the connection is typically provided through a cellular network that appropriately routes data traffic between the vehicle and the appropriate data service provider associated with the requested traffic. Examples of these service providers include Netflix, Spotify, Google, etc.

[0003] US2017251339A1 discloses selecting a path for routing a data packet from a source node to a destination node in a vehicular ad-hoc network. CN106953788B discloses a virtual network card 3 consisting of a first virtual network card 31 and a second virtual network card 32. Nguyen Kein et al., "Empowering 5G Mobile Devices With Network Softwarization," IEEE Transactions on network and service management, vol.18, no.3 (2021), discloses network softwarization using namespaces.

[0004] FIG. 1 shows a simplified architecture of a conventional in-vehicle network data provision. A vehicle 105 is configured to communicate with a cellular service provider 115 through a cellular network 110. The cellular network includes conventional network components such as a packet data network gateway, PGW, that provides a connection from the vehicle 104 to an external packet data network (PDN) by providing an entry point for traffic. The cellular service provider 115 is associated with the vehicle 105. A vehicle authorized to access a network service through the cellular service provider 115 is typically identified using an International Mobile Subscriber Identifier (IMSI) or other unique mobile device identifier for that vehicle. Upon receiving a request to access a network service, the service provider 115 routes the traffic to an appropriate network service provider, shown in the schematic diagram of FIG. 1 as a cloud-based service provider 120. In the architecture of FIG. 1, the vehicle 105 operates as an end point data consuming device, much like a mobile device network. In practice, what happens at the service provider 115 is that traffic from an authorized vehicle is routed to an appropriate destination associated with the traffic request. For example, if the request is for a music streaming service, the request is routed to an Internet-based music streaming service. If the request is for video streaming, the request is routed to an Internet-based video streaming service. In either case, the service provider 115 simply routes the traffic between these services and the vehicle. In conventional arrangements, the service provider 115 simply classifies these requests generically as data services and does not have the ability to distinguish between different types of data services.

[0005] There are challenges in classifying vehicle data traffic at granular service levels, and in breaking down the amount of traffic used per service at any level. The lack of detailed analytics on in-vehicle traffic reduces the ability to identify network usage at any level of detail, and reduces the ability to identify anomalies, including security and operational issues.

[0006] There is also the issue that vehicle manufacturers can pre-associate their vehicle access with dedicated service providers 115, but need to be able to control what data services are consumed within the vehicle.

[0007] There is also a need to be able to identify particular network traffic as being associated with a particular network data service provider, and to facilitate routing that traffic over a dedicated channel.

[0008] For these reasons, there is a need for greater granularity regarding the actual data services utilized within a network. Summary of the Invention

[0009] Thus, a first embodiment of the present application provides a method as defined in claim 1. Advantageous embodiments are provided in the dependent claims. Also provided is a network node arranged to provide this method.

[0010] According to an aspect of the present invention, there is provided a method for classifying in-vehicle data traffic in a network node, the method comprising:

[0011] defining, at the network node, a first network namespace and a second network namespace; the first network namespace includes an ingress network interface configured to receive incoming request data packets and deliver response data packets; the second network namespace includes an egress network interface configured to receive incoming response data packets and deliver request data packets; a channel is provided between the first network namespace and a second network namespace such that traffic between the ingress network interface and the egress network interface is routed through the channel; receiving at the network node a plurality of incoming request data packets from a vehicle, the data packets originating from an application executing in the vehicle; For each data packet of the plurality of incoming request data packets, extracting a source IP address of the data packet from a header of the data packet, the source IP address being associated with the vehicle; extracting a destination IP address of the data packet from a header of the data packet, the destination IP address being associated with a service requested by the application; determining an amount of data for an incoming data packet by inspecting a header of the data packet; Checking the destination IP address against a routing table; if it is determined that the destination IP address is defined in the routing table, then routing the incoming data packet through a channel defined for the destination IP address; or if it is determined that the destination IP address is not defined in the routing table, routing the incoming data packet through a default channel reserved for all undefined destination IP addresses; updating an indicator of channel volume based on the determined amount of data for the incoming request data packet; The plurality of incoming request data packets are transmitted from the network node to the destination IP address associated with each of the request data packets. The incoming request data packet is preferably received, at least in part, over a cellular data network. The routing table preferably uses the same channel for traffic with the same destination IP address.

[0012] Preferably, the method includes the following: receiving a plurality of incoming response data packets at the network node in response to transmitting the plurality of incoming request data packets from the network node to the destination IP address; For each data packet of the plurality of incoming response data packets, extracting a destination IP address of the data packet from a header of the data packet, the IP address being associated with the vehicle; extracting a source IP address of the data packet from a header of the data packet, the source IP address being associated with a service requested by the application; determining an amount of data for the incoming data packet by inspecting the header of the data packet; Checking the source IP address against the routing table; and if it is determined that the source IP address is defined in the routing table, then routing the incoming data packet through a channel defined for the source IP address; or if it is determined that the source IP address is not defined in the routing table, then routing the incoming data packet through a default channel provided for all undefined source IP addresses; updating an indicator of channel volume based on the determined amount of data for the incoming request data packet; It will be appreciated that each of the plurality of incoming response data packets is transmitted from the network node to each vehicle associated with the destination IP address for each of the response data packets, and that the destination IP address is associated as a mobile device ID or acts as a proxy for each of the response data packets.

[0013] Preferably, said transmission occurs at least in part using a cellular data network.

[0014] The routing table preferably uses the same channel for traffic with the same source IP address.

[0015] Preferably, each of a plurality of said channels is associated with a separate application executed on said vehicle.

[0016] The method preferably includes defining the channel in the routing table and includes associating known IP address values ​​with particular channels such that traffic destined for an IP address associated with a particular channel is routed through the channel.

[0017] The method includes dynamically updating the routing table, the method including for an incoming DNS request data packet, first performing packet inspection by matching the domain in the DNS query against a set of defined expressions, each defined expression being associated with a particular service, and preferably, if a match is found, updating the routing table with the IP address or addresses of the domain such that upon receiving a response data packet to the request data packet, subsequent traffic to and from these IP addresses passes through a channel associated with the particular service that was first matched against the DNS request data packet.

[0018] Preferably the method includes dynamically updating said routing table. monitoring upstream TLS packets to identify a TLS handshake; If it determines that a TLS handshake is in the process of inspecting the packet to determine whether it contains an SNI header, It finds the SNI header, extracts the header's value, and compares it with the SNI matching rules defined for each service; if an SNI rule matches, it uses the destination IP address header of the TLS packet to update the routing table for the service that owns that rule.

[0019] According to a further aspect of the present invention there is provided a network node including a processor, a first network interface and a second network interface, Preferably, the network node is configured to carry out the method. [Brief description of the drawings]

[0020] The present application will now be described with reference to the accompanying drawings. [Figure 1]FIG. 1 is a schematic diagram showing the network architecture of a prior art system. [Diagram 2] FIG. 2 is a schematic diagram showing the network architecture of the system according to the invention. [Diagram 3] FIG. 3 is a schematic diagram illustrating the architecture in a particular instance for analyzing traffic to and from a particular vehicle. [Figure 4] FIG. 4 is a process flow diagram illustrating how vehicle-originated data may be routed. [Diagram 5] FIG. 5 is a process flow diagram illustrating a method for routing data destined for a vehicle. [Figure 6] FIG. 6 is an example histogram outlining data services per channel that can be generated using the system of the present teachings. [Figure 7] FIG. 7 is an example of a portion of a DNS lookup process flow that can be used in accordance with the present teachings. [Figure 8] FIG. 8 is an example of another portion of a DNS lookup process flow that can be used in accordance with the present teachings. [Figure 9] FIG. 9 is an example of a TLS packet inspection process flow that can be used in accordance with the present teachings. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0021] 2 is a network architecture integrating a processing or classification system 200 in accordance with the present invention. The processing or classification system 200 is configured to classify network traffic passing therethrough into destination services and to report traffic volume per service. The system 200 is configured to identify the ultimate destination of any traffic received from a vehicle 105 and use the identified destination as a classifier of data services being consumed by that vehicle 105.

[0022] Incoming traffic from the vehicle 105, received in the form of data packets, is analyzed to identify a destination IP address of the traffic. Upon determining the destination IP address, the system 200 is configured to determine whether the IP address is pre-associated with a known data service provider. Upon determining that there is a known data service provider, the system channels the incoming traffic through a channel in the system dedicated to that data service provider's traffic. Traffic destined for data service provider A is routed via channel A, and traffic destined for data service provider B is routed via channel B. Channelizing the traffic through a dedicated channel based on the destination IP address allows the traffic to be analyzed and classified based on header information without requiring any inspection of the actual payload of the packets. This facilitates real-time minimal delay classification of the traffic.

[0023] Thus, the classification system according to the present invention ensures that the amount of data passing through any one channel reflects the actual usage of a particular data service and can be monitored, reported, or otherwise controlled.

[0024] While the system functionality can be visualized in five core blocks 205-225, this is for ease of understanding, and it will be understood that functionality described below with respect to one block can equally be provided by another block. Functionally, without being constrained to a particular implementation, the system can be understood to include:

[0025] Configuration Manager 205 The configuration manager 205 validates the configuration options and publishes configuration updates to other components of the system 200 .

[0026] DNS Monitor 210 The DNS monitor 210 scans DNS traffic passing through the system, compares queries and responses against service rules defined in the configuration manager data structures, and publishes updates to the routing controller 220 if a match is found.

[0027] SNI Monitor 215 The SNI monitor 215 scans the TLS handshake and applies service matching rules to the SNI header. If a match is found, an update is published to the routing controller 220.

[0028] Routing Controller 220 The routing controller configures the routing table to enable implicit classification of traffic passing through the system 200. The initial routing table configuration is based on the IP addresses and network ranges included in each service's configuration, however, the routing controller can also dynamically modify the routing table at run time in response to updates received from the DNS and SNI monitors.

[0029] EDR Generator 225 The EDR generator 225 monitors the headers of packets flowing on each channel in the system and publishes periodic updates summarizing the traffic per service per vehicle.

[0030] The component functional blocks 205-225 of the classification system 200 can be configured and monitored using a management system 230. While FIG. 2 shows this management system on a separate device, the management network 235, it will be understood that this is for schematic purposes to visually separate the management and post-processing functions from the functional components that actively interface with the traffic passing through the classification system 200. The management network 235 can also host a database 240 that can store EDR data exposed by the EDR generator 225, and a data analysis engine 250. In an optional embodiment, the database 240 and / or the analysis engine 250 may be provided on one or more additional devices separate from the management system 230. Some of the details of the system of FIG. 2 are further described below with reference to FIG. 3.

[0031] While it is not intended that the teachings of the present invention be limited to any one particular network operating system or the like, for present purposes, it will be assumed that the classification system 200 is hosted on a LINUX® machine (which may be a physical machine or a virtual machine) with three network cards.

[0032] The control NIC 315 provides communications between the system 200 and the management network 235. The control NIC 315 may be used to send and receive communications from the management system 230 used to manage the system 200. The control NIC 315 may also be used to provide data transmission from the EDR generator 225 to the database 240 and the analysis engine 250.

[0033] Ingress NIC 305 is connected to an ingress network for communicating with vehicles, and egress NIC 310 is connected to an egress network for communicating with external network elements, such as services requested by the vehicles.

[0034] As shown in FIG. 3, which illustrates in schematic form at least a portion of the processing occurring within classification system 200, the classification system is configured to implement two network namespaces: ingress namespace 301 and egress namespace 302. Ingress NIC 305 is located in ingress namespace 301 and egress NIC 310 is located in egress namespace 302. The ingress network is used to receive request packets and deliver response packets. The egress network is used to deliver request packets and receive response packets. The routing of these packets is controlled by routing controller 220.

[0035] Those skilled in the art will appreciate that a network namespace is an independent implementation of an IP stack. Hosting the ingress and egress NICs in separate namespaces effectively isolates traffic on each network. To forward packets between networks, packets must be forwarded between namespaces. To achieve this forwarding between respective namespaces, the system of the present teachings employs the known Linux construct of Virtual Ethernet (VETH), which allows for the creation of local Ethernet tunnels between respective namespaces. A veth pair is a virtual Ethernet connection with two endpoints. Packets written to one endpoint can be read from the other endpoint and vice versa. Within the host system of FIG. 3, the present teachings use veth pairs 1-5 to bridge network namespaces by placing one end of each pair in the ingress namespace 301 and the other end in the egress namespace 302.

[0036] As part of the initial configuration of the system to provide for traffic classification, the present teachings first create a veth pair between the ingress and egress namespaces of each service to be classified, and one additional veth pair for unclassified traffic. These veth pairs effectively act as channels through which classified traffic passes. In this example, the services to be classified are those identified by channels A through D, and the last channel, channel E, is the channel through which all unclassified traffic is routed. The number of channels shown is for illustrative purposes only, and again, for ease of understanding only, it is understood that channel A can be considered to be used for a first music streaming service, channel B for a video streaming service, channel C for a second music streaming service, channel D for a navigation service such as that provided by Google Maps, and channel E for all other Internet traffic, browsing, other data service providers, etc. It will be understood that this number of channels or association with specific services can be changed depending on the specific requirements of the system.

[0037] It will be appreciated that any packet traversing a packet-based network includes a header and a payload. The header contains control information that provides data (such as source and destination network addresses) for delivering the payload, and the payload contains the user data. The system classifies traffic by inspecting the destination address of vehicle-originated packets and the source address of vehicle-terminated packets. By defining an entry in the routing table that associates a particular address with a particular channel, upon identifying a particular address in the header information, the entry in the routing table can be used to forward the packet to the appropriate veth pair. Thus, the act of routing traffic through a particular channel implicitly classifies the traffic as being associated with a particular type of data service.

[0038] FIG. 4 illustrates the process flow associated with routing traffic from a vehicle. A packet arrives at the ingress NIC from the vehicle (step 405). It will be appreciated that, traditionally, the actual vehicle identifier VIN or the mobile identifier IMSI of the vehicle is not displayed at the ingress NIC 305. For each traditional traffic session, traffic originating from the vehicle is first routed to a packet gateway (PGW), which will be appreciated as a traditional component of the cellular network 110. The PGW assigns an IP address to the vehicle for the duration of the session. The PGW also publishes a data feed that associates the MSISDN identifier with the IP address assigned to the session. In accordance with the present teachings, this feed is then used to adjust the traffic routed through the ingress and egress NICs, since the MSISDN can be resolved to an out-of-band VIN / IMSI during the analysis phase, allowing the service traffic to be attributed to a particular vehicle. For example, a portion of the traffic routed through the system 200 can be attributed to an individual vehicle 105a, while another portion of the traffic can be attributed to vehicles 105b and 105c. Typically, this adjustment is done through offline processing of channel volume data from the PGW feed and EDR generator 225 by the analysis engine 250. Thus, the analysis engine 250 can analyze the traffic on a per channel and per vehicle basis. It will be appreciated that there is an association between the destination IP address of the response packet and the MSISDN of the respective vehicle, but this is typically only known at the packet gateway (PGW). This IP address can be associated with a particular vehicle, but this is typically not done by the PGW itself. Nevertheless, once a packet is received from a vehicle at the ingress NIC 301, the header is checked for the destination IP address (step 410). That IP address is extracted and then checked against the routing table (step 415).If there is a match (step 420), it is routed according to the destination IP address to the appropriate channel provided by the defined Veth pair (step 425).

[0039] If there is no match (step 420) because there is no explicit route defined in the routing table for the destination IP address, the packet is routed to the default channel (step 430) associated with its own particular veth pair. In the example of Figure 3, this default channel is channel 5, which is associated with all Internet traffic not otherwise classified.

[0040] In either scenario (matched or unmatched), the packet leaves the veth pair in the egress namespace and is routed through the upstream gateway associated with the service, or through the default gateway if no explicit gateway is configured. The packet is then written to the egress NIC from which it originated (step 435).

[0041] Figure 5 shows the equivalent process when a vehicle terminates traffic. A packet arrives at the egress NIC (step 505) and is policy routed to the appropriate veth pair according to the source IP address, i.e., the origin of the packet. This is accomplished by checking the source IP address header (step 510) and checking the routing table for that identified source address (step 515). If no explicit policy route exists (no match in match determination step 520), the packet is routed via the default Veth pair (step 530). If an explicit policy route exists (match in match determination step 520), the packet is routed to the channel associated with the match (step 525). In either scenario, the packet leaves the veth pair in the ingress namespace and is routed via the downstream gateway associated with the destination address. These are sent via the ingress NIC.

[0042] By classifying traffic according to IP address, data can be aggregated over time regarding the amount of traffic passing through any channel.

[0043] FIG. 6 shows an example of a histogram of traffic over time that can be calculated. It will be appreciated that this is merely illustrative, but shows that meaningful data can be extracted regarding the nature of data traffic utilized by a vehicle or group of vehicles over time. The data is aggregated by calculating traffic per service by inspecting packet headers as the packets pass through each veth pair. The data in FIG. 6 may be per channel data associated with one particular IP address corresponding to a particular vehicle 105, or it may be aggregated per channel data associated with all traffic passing through the system 200 (i.e., traffic of multiple vehicles 105a-c).

[0044] For vehicle originated packets, the system can be configured to record the number of bytes in the packet and associate it with the source IP address found in the packet header. For vehicle terminated packets, the system can be configured to record the number of bytes in the header and associate it with the destination IP address found in the packet header. As outlined above, the source / destination IP addresses can be associated with a specific vehicle through comparison to data feeds published by the PGW. In this way, the system can maintain a count of bytes uploaded and downloaded per service for each vehicle. These statistics are collected periodically and sent for data processing and analysis, at which point the counts are reset or archived for later use.

[0045] The classified data collected by the system 200 is output as an aggregated data set and sent to a database 240 and / or an analytics engine 250 for storage and / or further processing.

[0046] In one example, an aggregated dataset including traffic data per channel is sent from system 200 to database 240 for storage. Analytics engine 250 retrieves and processes the aggregated dataset from database 240. Analytics engine 250 enriches the aggregated dataset with platform data to associate traffic on a particular channel with a particular IMSI, vehicle, and / or group of vehicles. For example, usage of a particular service provider (e.g., Netflix, Spotify, etc.) by all vehicles of a particular brand (e.g., VW, Porsche, etc.) can be inferred from the enriched aggregated dataset, which can be used to provide billing and reporting data.

[0047] The analytics engine 250 takes the per-channel / per-IP-address traffic data output from the system 200 and stored in the database 240 and reconciles them to generate equivalent per-service / per-vehicle traffic summaries. Consumed data (uploads and downloads) is collected at a sampled frequency and stored against the service consuming the data (the service the user has subscribed to).

[0048] In order to create the routing tables necessary to meaningfully classify packets passing through the system, the system requires knowledge of the IP addresses used by a particular data service provider. It will be appreciated that popular data service providers such as Spotify, Netflix, etc. are known to employ lists of known, permanent IP addresses or subnets for their respective services. These are used to create the initial routing configuration that classifies the traffic for that service.

[0049] However, to augment this static configuration, the system is also configured to dynamically discover new IP addresses for services by inspecting DNS and TLS packets.

[0050] In this context, it will be appreciated that in traditional Internet traffic routing, a DNS lookup is triggered when an application on a client device wants to connect to an Internet host but only has the name of that host (e.g., services.cubictelecom.com). To open a connection, an application running on the device (or network node) needs an address. The role of the DNS is to look up a name and return one or more IP addresses that can be used to contact the associated host. In accordance with the present teachings, a routing table that is used to direct specific traffic through specific channels to facilitate subsequent analysis of whether a specific Internet service is being used by a specific vehicle is populated with a specific IP address for each specific known service. In this way, the routing table uses known IP addresses for known services and routes traffic for those services through the channels associated with those IP addresses.

[0051] Certain services have fixed IP addresses associated with them, and for those services for which the system of the present invention anticipates needing traffic analysis, the routing tables for the channels associated with those services can be pre-populated with those IP addresses. It will be appreciated that multiple IP addresses may be associated with a service provider, and the routing tables of the present invention can accommodate the use of multiple IP addresses to route traffic for one dedicated service.

[0052] For other services, or when a particular service geo-fences traffic to a particular IP address, the actual IP address used to service an application request may vary over time. The system of the present teachings can address this type of dynamic IP address by analyzing incoming traffic to identify changes in the IP address associated with the service and updating the routing table when a new IP address for that target service is found. In such an arrangement to dynamically update the routing table used to classify subsequent packets, the system can be configured to perform DNS packet (UDP port 53) inspection by first matching the domain of the DNS query against a collection of regular expressions. As part of the system's configuration, each service for which an analysis channel is required can define a set of regular expressions to match. If a match is found, the system can cache the request ID and wait for the corresponding DNS response. When a response arrives, the IP address associated with the domain is forwarded to the routing controller, which updates the routing table entry for the service. When a response arrives, the IP address associated with the domain is forwarded to the routing controller, which updates the routing table entry for the service. Subsequent traffic to or from these IP addresses is classified as belonging to that service.

[0053] In some cases, the domain being queried may be too general to be associated with a service. In this case, the DNS rules can contain additional rules to match CNAMEs in the DNS response. The IP address returned in the response will be forwarded to the routing controller only if the response contains a CNAME and that CNAME matches one of the provided rules.

[0054] 7 and 8 are schematic diagrams illustrating an example process flow relating to how a system in accordance with the present teachings can resolve traffic routed through the system to ensure that the appropriate channel is used.

[0055] The process begins in step 705 when a client device, a vehicle, attempts to open a connection to a host. In step 710, the client device sends a DNS request to a name server to resolve a host name to one or more IP addresses. The DNS request is identified when it arrives on the ingress NIC. Upon arrival, in step 715, the request is inspected and the host is compared to the rules defined for each service. If there is no match, the request ID is not saved (step 730), but the request is still routed to the DNS name server in step 735.

[0056] If there is a match, then in step 720, for the host, the DNS request ID is cached and the DNS request is routed through the egress NIC to the DNS name server, which resolves the request and responds with a DNS response.

[0057] When a DNS response is received from a name server, the response ID of the DNS response is checked against the request ID cache in step 740 to see if there is a match in step 741 .

[0058] If a match is found, then in step 745 the system is configured to forward the A record to the routing controller, where one skilled in the art will appreciate that the A record is the portion of the DNS response that contains the IP address associated with the domain, and the routing controller then updates the routing table for the associated service.

[0059] In step 750, whether or not a match was found, the DNS response is sent to the requesting client.

[0060] In step 755, the client opens a connection to one of the IP addresses included in the DNS response.

[0061] In step 760, the traffic resulting from the request is routed through the correct channel defined by the routing controller.

[0062] Following the process flow of Figure 9, the system can also be configured to monitor all upstream TLS packets (TCP port 443) on the ingress NIC. Upon identifying a TLS handshake in process step 805, the client handshake packet is inspected in step 810 to determine whether it contains a Server Name Indication (SNI) extension header. If an SNI header is found, the header's value is extracted in step 820 and compared to the SNI matching rules defined for each service. If a service rule is matched, in step 825 the destination IP address of the packet is assumed to be the identifying IP address of that service, and in step 835 the destination IP address is forwarded to the routing controller. As in the case of a DNS match, the routing controller updates the routing table entry for the service 840.

[0063] From the above, it can be seen that the system according to the present teachings allows for classification of data usage at the network level based on the service generating that traffic. By identifying the IP addresses of different data service providers, the present teachings allow for routing of network traffic at the network level through channels specific to these different data service providers. Routing is performed by analyzing the headers of packets traversing the network and routing packets to specific channels based on the source or destination IP address. In this way, the nature of the traffic is inferred from the IP address of the generating data service provider as opposed to having to perform detailed packet analysis of each individual packet traversing the network.

[0064] The system of the present teachings is configured to route traffic originating from a particular vehicle through channels specific to different data service providers. In this way, a detailed overview of the type of data services used by a particular vehicle is achieved at the network level. The system does not need to query the actual vehicle for e.g. browsing activity or cookies. The analysis is performed based on packets passing through the network device. Using the vehicle's device identifier (usually IMSI), traffic originating from the vehicle or routed to it from different data service providers can be tracked. This not only facilitates monitoring of data usage, but also enables additional features such as service blocking, routing configuration changes based on the device or data service in use, billing data, etc.

[0065] It will be appreciated that the system of the present teachings provides tracking at a device-specific level, rather than at a browser or specific application level. Although data analysis is performed on a device-by-device basis, it is possible to track all devices using the network and obtain a global view of activity for all specified devices on the network, as opposed to performing statistical sampling to estimate traffic.

[0066] As detailed above, because the system of the present teachings tracks requests from a network level, rather than from an application such as a web browser, it is able to see and track all requests for data services from Internet-type data service providers, including web-based services, but also non-human / user directed services such as machine-to-machine services such as telematics, maps, and other machine-to-machine data, website requests, or consumer-based services such as streaming data services like Netflix / Spotify.

[0067] Data requests are tracked at the raw request level as they travel over the network, which differs from other traffic analysis tools in that it only records requests made from a web browser, and not from a terminal window, updates from the operating system, or other requests.

[0068] It will be appreciated that an exemplary configuration of the data analysis system is located within a network node, for example between a vehicle and a data service provider. The system is configured to analyze packets of data originating from or destined for a particular vehicle and route the packets through a particular channel within the network node so that data analysis can be performed on the nature of the particular data service being used by the vehicle based on the header information within those packets. Changes may be made in what has been described herein without departing from the scope of this application, which is intended to be limited only insofar as necessary in light of the following claims.

[0069] As used in this specification, the word comprises / comprising is intended to specify the presence of stated features, integers, steps or components, but does not exclude the presence or addition of one or more other features, integers, steps, components or groups thereof.

Claims

1. A method in a network node for classifying in-vehicle data traffic, comprising: In the network node, defining a first network namespace and a second network namespace, The first network namespace includes an ingress network interface configured to receive incoming request data packets and deliver response data packets, and the second network namespace includes an egress network interface configured to receive incoming response data packets and deliver request data packets. A plurality of channels are provided between the first network namespace and the second network namespace such that traffic between the ingress network interface and the egress network interface is routed through the channels, Receiving, at the network node, a plurality of incoming request data packets from a vehicle (105), the data packets being sent from an application running on the vehicle (105), For each data packet of the plurality of incoming request data packets Extracting the source IP address of the data packet from the header of the data packet, the source IP address being associated with the vehicle (105), Extracting the destination IP address of the data packet from the header of the data packet, the destination IP address being associated with the service requested by the application, Determining the data volume of the incoming data packet by inspecting the header of the data packet, Comparing the destination IP address with a routing table, If the destination IP address is determined to be defined in the routing table, routing the incoming data packet through the channel defined for the destination IP address, the channel being one of a plurality of channels provided between the first network namespace and the second network namespace, or If it is determined that the destination IP address is not defined in the routing table, route the incoming data packet through a default channel provided for all undefined destination IP addresses, the default channel being one of a plurality of channels provided between the first network namespace and the second network namespace, updating an indicator of channel volume based on the determined data volume of the incoming request data packet, and transmitting, from the network node, the plurality of incoming request data packets to the destination IP address associated with each respective request data packet. **Claim 2** The method according to claim 1, wherein the incoming request data packet is received at least in part via a cellular data network. **Claim 3** The method according to claim 1 or claim 2, wherein the routing table uses the same channel for traffic to the same destination IP address. **Claim 4** in response to transmitting the plurality of incoming request data packets from the network node to the destination IP address, receiving, at the network node, a plurality of incoming response data packets, and for each data packet of the plurality of incoming response data packets extracting, from the header of the data packet, the destination IP address of the data packet, the IP address being associated with the vehicle (105), extracting, from the header of the data packet, the source IP address of the data packet, the source IP address being associated with the service requested by the application, determining the data volume of the incoming data packet by inspecting the header of the data packet, and matching the source IP address with the routing table, and if it is determined that the source IP address is defined in the routing table, routing the incoming data packet through the channel defined for that source IP address, the channel being one of a plurality of channels provided between the first network namespace and the second network namespace, or When it is determined that the source IP address is not defined in the routing table, route the incoming data packet through the default channel defined for all undefined source IP addresses, where the default channel is one of a plurality of channels provided between a first network namespace and a second network namespace. Updating an indicator of channel volume based on the determined data amount of the incoming request data packet. The method according to claim 1, wherein each of the plurality of incoming response data packets is transmitted from the network node to each vehicle (105) associated with an IP address for each of the response data packets.

5. The method according to claim 4, wherein the transmission is performed at least partially using a cellular data network.

6. The method according to claim 4, wherein the routing table uses the same channel for traffic with the same source IP address.

7. The method according to claim 1, wherein each of the plurality of channels is associated with an individual application executed on the vehicle (105).

8. The method according to claim 1, including defining the channel in the routing table, the method including associating a known IP address value with a specific channel such that traffic destined for the IP address associated with the specific channel is routed through the channel.

9. The method according to claim 1, further including dynamically updating the routing table, the method including performing packet inspection on an incoming DNS request data packet by first collating the domain in the DNS query against a set of defined expressions, each defined expression being associated with a specific service, and if a match is found, the method including updating the routing table with the IP address or addresses of the domain such that subsequent traffic to and from these IP addresses passes through the channel associated with the specific service that first matched the DNS request data packet when receiving a response data packet for the request data packet.

10. further comprising dynamically updating the routing table, the method comprising monitoring upstream TLS packets to identify a TLS handshake, if it is determined that the TLS handshake is in a process of checking the packet to determine whether an SNI header is included, finding the SNI header, extracting the value of the header, and comparing the value with an SNI matching rule defined for each service, if the SNI rule matches, updating the routing table of the service owning the rule with the destination IP address header of the TLS packet, the method according to claim 1.

11. A network node comprising a processor, a first network interface, and a second network interface, the network node being configured to execute the method according to claim 1.

Images