Field

This specification relates to application identification, in particular to identifying an application corresponding to a data flow.

Background

An identifier of the application corresponding to a data flow may be provided to a network side entity of a communication system. There remains a need for alternative arrangements for identifying an application establishing such a data flow and for providing such information to a network entity.

Summary

In a first aspect, this specification describes an apparatus comprising: means for detecting, at a user device, establishment of a data flow from a user-side application to a first network-side entity (such as a web server); means for a determining, at the user device, an identifier of the application corresponding to said data flow, wherein the identifier of the application comprises a name of a process owning a user-side socket terminating the data flow; and means for transferring the identifier of the application to a second network-side entity, wherein the means for transferring the identifier of the application to the second network side entity comprises: means for establishing a connection to the second network-side entity and providing packets of data including the identifier of the application as part of an off-band data transfer to the second network side entity; and/or means for modifying one or more existing packets being transferred from the user device to the second network-side entity to include the identifier of the application.

The means for establishing a connection to the second network-side entity may include a radio resource control (RRC) or other control plane connection (such as 3 GPP).

The means for transferring the identifier of the application may comprises means for providing a mapping between the application identity and the socket identity of the data flow. The mapping may be a tuple (e.g. a globally unique identifier, one example of which is a 5-tuple. Tuples may include IP addresses, UDP ports etc.) The identifier of the application may be received at a relevant radio access network of the first or second network-side entity.

The means for transferring the identifier of the application may include means for extracting the identifier of the application from modified existing data packets at the second network-side entity.

The means for detecting establishment of the data flow and/or the means for determining the identifier of the application may comprise a socket monitor of the user device.

The means for detecting establishment of the data flow (e.g. a socket monitor) may detect the establishment of new data flows by inspecting data packets at the user-side (e.g. by detecting SYN segments (for TCP) or by detecting a packet with a new IP address/port pair (for UDP)).

The means for a determining the identifier of the application (e.g. the socket monitor) may query a process interface to determine a name of the process that has established said data flow. For example, the process interface that opens a connection to establish said data flow may be identified.

The second network-side entity may comprise one or more of: a quality-of-service monitoring application or an application aware traffic management system; means for arbitrating resource allocation; and a differential application-based service to the user.

In some embodiments, the second network-side entity comprises a base station and/or a core network.

In a second aspect, this specification describes an apparatus comprising means for receiving, at a second network-side entity, an identifier of an application corresponding to a data flow (such as an Internet Protocol (IP) data flow, examples of which in TCP/IP, UDP/IP etc.), wherein: the identifier of the application comprises a name of a process owning a user-side socket terminating the data flow and the identifier of the application is received at said second network-side entity from the user device as part of an off-band data transfer to the second network-side entity and/or as one or more modified existing packets being transferred from the user device to the second network- side entity.

The second network-side entity may comprise means for controlling whether said identifier is provided by said user device to said second network-side entity. Thus, for example, the network-side entity may be able to turn the reporting on or off as desired.

The second network-side entity may comprise one or more of: a quality-of-service monitoring application or an application aware traffic management system; means for arbitrating resource allocation; and a differential application-based service to the user.

In some embodiments, the second network-side entity comprises a base station and/or a core network. In the first or second aspects, the said means may comprise: at least one processor; and at least one memoiy including computer program code, the at least one memory and the computer program code configured, with the at least one processor, to cause the performance of the apparatus. In a third aspect, this specification describes a method comprising: detecting, at a user device, establishment of a data flow from a user-side application to a first network-side entity; determining, at the user device, an identifier of the application corresponding to said data flow, wherein the identifier of the application comprises a name of a process owning a user-side socket terminating the data flow; and transferring the identifier of the application to a second network-side entity, wherein transferring the identifier of the application to the second network side entity comprises: establishing a connection to the second network-side entity and providing packets of data including the identifier of the application as part of an off-band data transfer to the second network side entity; and/or modifying one or more existing packets being transferred from the user device to the network-side entity to include the identifier of the application.

In a fourth aspect, this specification describes a method comprising receiving, at a second network-side entity, an identifier of an application corresponding to a data flow (such as an Internet Protocol (IP) data flow, examples of which in TCP/IP, UDP/IP etc.), wherein: the identifier of the application comprises a name of a process owning a user-side socket terminating the data flow and the identifier of the application is received at said second network-side entity from the user device as part of an off-band data transfer to the second network-side entity and/or as one or more modified existing packets being transferred from the user device to the second network-side entity. The second network-side entity may control whether said identifier is provided by said user device to said second network-side entity. Thus, for example, the network-side entity may be able to turn the reporting on or off as desired.

Some embodiment may comprise providing a mapping between the application identity and the socket identity of the data flow. The mapping may be a tuple (e.g. a globally unique identifier, one example of which is a 5-tuple. Tuples may include IP addresses, UDP ports etc.)

The identifier of the application may be received at a relevant radio access network of the first or second network-side entity.

Transferring the identifier of the application may include means for extracting the identifier of the application from modified existing data packets at the second network- side entity. Detecting establishment of the data flow and/ or determining the identifier of the application may comprise a socket monitor of the user device.

The second network-side entity may comprise one or more of: a quality-of-service monitoring application or an application aware traffic management system; means for arbitrating resource allocation; and a differential application-based service to the user.

In a fifth aspect, this specification describes any apparatus configured to perform any method as described with reference to the third or fourth aspects. In a sixth aspect, this specification describes computer-readable instructions which, when executed by computing apparatus, cause the computing apparatus to perform any method as described with reference to the third or fourth aspects.

In a seventh aspect, this specification describes a computer program comprising instructions for causing an apparatus to perform at least the following: detecting, at a user device, establishment of a data flow from a user-side application to a first network- side entity; determining, at the user device, an identifier of the application

corresponding to said data flow, wherein the identifier of the application comprises a name of a process owning a user-side socket terminating the data flow; and transferring the identifier of the application to a second network-side entity, wherein transferring the identifier of the application to the second network side entity comprises:

establishing a connection to the second network-side entity and providing packets of data including the identifier of the application as part of an off-band data transfer to the second network side entity; and/or modifying one or more existing packets being transferred from the user device to the network-side entity to include the identifier of the application.

In an eighth aspect, this specification describes a computer program comprising instructions for causing an apparatus to perform at least the following: receiving, at a second network-side entity, an identifier of an application corresponding to a data flow (such as an Internet Protocol (IP) data flow, examples of which in TCP/IP, UDP/IP etc.), wherein: the identifier of the application comprises a name of a process owning a user-side socket terminating the data flow and the identifier of the application is received at said second network-side entity from the user device as part of an off-band data transfer to the second network-side entity and/or as one or more modified existing packets being transferred from the user device to the second network-side entity.

In a ninth aspect, this specification describes a computer-readable medium (such as a non-transitoiy computer readable medium) comprising program instructions stored thereon for performing at least the following: detecting, at a user device, establishment of a data flow from a user-side application to a first network-side entity; determining, at the user device, an identifier of the application corresponding to said data flow, wherein the identifier of the application comprises a name of a process owning a user-side socket terminating the data flow; and transferring the identifier of the application to a second network-side entity, wherein transferring the identifier of the application to the second network side entity comprises: establishing a connection to the second network- side entity and providing packets of data including the identifier of the application as part of an off-band data transfer to the second network side entity; and/or modifying one or more existing packets being transferred from the user device to the network-side entity to include the identifier of the application. In a tenth aspect, this specification describes a computer-readable medium (such as a non-transitoiy computer readable medium) comprising program instructions stored thereon for performing at least the following: receiving, at a second network-side entity, an identifier of an application corresponding to a data flow (such as an Internet Protocol (IP) data flow, examples of which in TCP/IP, UDP/IP etc.), wherein: the identifier of the application comprises a name of a process owning a user-side socket terminating the data flow and the identifier of the application is received at said second network-side entity from the user device as part of an off-band data transfer to the second network-side entity and/or as one or more modified existing packets being transferred from the user device to the second network-side entity.

In an eleventh aspect, this specification describes an apparatus comprising: at least one processor; and at least one memory including computer program code which, when executed by the at least one processor, causes the apparatus to: detect, at a user device, establishment of a data flow from a user-side application to a first network-side entity; determine, at the user device, an identifier of the application corresponding to said data flow, wherein the identifier of the application comprises a name of a process owning a user-side socket terminating the data flow; and transfer the identifier of the application to a second network-side entity, wherein transferring the identifier of the application to the second network side entity comprises: establishing a connection to the second network-side entity and providing packets of data including the identifier of the application as part of an off-band data transfer to the second network side entity;

and/or modifying one or more existing packets being transferred from the user device to the network-side entity to include the identifier of the application.

In a twelfth aspect, this specification describes an apparatus comprising: at least one processor; and at least one memory including computer program code which, when executed by the at least one processor, causes the apparatus to: receive, at a second network-side entity, an identifier of an application corresponding to a data flow (such as an Internet Protocol (IP) data flow, examples of which in TCP/IP, UDP/IP etc.), wherein: the identifier of the application comprises a name of a process owning a user- side socket terminating the data flow and the identifier of the application is received at said second network-side entity from the user device as part of an off-band data transfer to the second network-side entity and/or as one or more modified existing packets being transferred from the user device to the second network-side entity. In a thirteenth aspect, this specification describes an apparatus comprising: a first module (such as a socket monitor) for detecting, at a user device, establishment of a data flow from a user-side application to a first network-side entity (such as a web server); a second module (such as the socket monitor) for determining, at the user device, an identifier of the application corresponding to said data flow, wherein the identifier of the application comprises a name of a process owning a user-side socket terminating the data flow; and a third module (such as the socket monitor) for transferring the identifier of the application to a second network-side entity, wherein the third module comprises: an off-band transfer module for establishing a connection to the second network-side entity and providing packets of data including the identifier of the application as part of an off-band data transfer to the second network side entity; and/or an in-band transfer module for modifying one or more existing packets being transferred from the user device to the second network-side entity to include the identifier of the application.

In a fourteenth aspect, this specification describes an apparatus comprising: a receiver (e.g. a radio access network or a core network), at a second network-side entity, for receiving an identifier of an application corresponding to a data flow (such as an Internet Protocol (IP) data flow, examples of which in TCP/IP, UDP/IP etc.), wherein: the identifier of the application comprises a name of a process owning a user-side socket terminating the data flow and the identifier of the application is received at said second network-side entity from the user device as part of an off-band data transfer to the second network-side entity and/or as one or more modified existing packets being transferred from the user device to the second network-side entity.

Brief description of the drawings

Example embodiments will now be described, by way of non-limiting examples, with reference to the following schematic drawings: FIG. 1 is a block diagram of a system in accordance with an example embodiment;

FIG. 2 is a block diagram of a system in accordance with an example embodiment;

FIG. 3 is a flow chart showing an algorithm in accordance with an example

embodiment;

FIG. 4 is a block diagram of a system in accordance with an example embodiment;

FIG. 5 is a block diagram showing further details of a user device of the system of FIG. 4; FIGS. 6 to li are flow charts showing algorithms in accordance with example embodiments;

FIG. 12 is a block diagram of a system in accordance with an example embodiment; and FIGS. 13A and 13B show tangible media, respectively a removable memory unit and a compact disc (CD) storing computer-readable code which when run by a computer perform operations according to example embodiments.

Detailed description

In the description, like reference numerals relate to like elements throughout.

FIG. 1 is a block diagram of a system, indicated generally by the reference numeral 10, in accordance with an example embodiment.

The system 10 comprises a number of user devices in communication with a network 16. The particular example shown in FIG. 1 includes a first user device 12, a second user device 13 and a third user device 14, each in two-way communication with the network 16. Of course, in any particular embodiment, any number of user devices may be in communication with the network 16. On receipt of data from one of the user devices, the network 16 may wish to be able to identify an application providing the data (for example for quality-of-service (QoS) flow parameter setting, quality-of-service or quality-of-experience (QoE) management, monitoring, reporting etc.). This can be difficult, particularly if the data is encrypted. IP address/port-based identification is typically unreliable and domain name (DNS)- based identification may not be detailed enough, especially if multiple applications are hosted under the same domain or a given domain hosts common services for multiple applications. Indirect mechanisms for identifying an application providing data based, for example, on traffic pattern monitoring typically take time in order to process the incoming data and to reach conclusions. Accordingly, such methods may not be able to classify a source application starting with the first transferred data packet. In some systems, applications may be identified by pre-assigned identifiers (IDs) that map an application to a number. If such mappings are not standardized, then the provider of the application ID (such as a traffic monitoring probe) may have to publish a mapping table. Different traffic monitoring probes may use different mappings, making application IDs decodable only in the context of their provider and their specific implementation. Relying on numerical application IDs is typically insufficiently reliable for use by the network entity for identification purposes.

FIG. 2 is a block diagram of a system, indicated generally by the reference numeral 20, in accordance with an example embodiment. The system 20 comprises the first user device 12 referred to above (and could include any number of further user devices). The system 20 also comprises a radio-access network 22, a core network 24 and the Internet 26. The radio access network 22, core network 24 and Internet 26 are collectively referred to herein as the“network side” of the system 20 (with the user device 12 being referred to as the“user side”). The radio access network 22 may be a base station. The core network may be a 3GPP mobile core network. Of course, other implementations are possible. For example, the radio access network 22 could be a wi- fi access point. The core network 24 may, for example, belong to an Internet Service Provider or a Communication Server Provider (or some other deployment of home Internet access). FIG. 3 is a flow chart showing an algorithm, indicated generally by the reference numeral 30, in accordance with an example embodiment.

The algorithm 30 starts at operation 32, where the establishment of a data flow from a user side application, such as the user device 12, to a first network side entity, such as the radio access network 22, core network 24 or the Internet 26 (e.g. a web server or some other Internet location) is determined. This determination may be carried out at the user side application (as discussed further below).

At operation 34, an identifier of the application corresponding to said data flow detected in operation 32 is determined. As described further below, the identifier of the application comprises a name of a process owning a user side socket terminating the data flow. The determination of the identifier of the application may be carried out at the user side application (as discussed further below). At operation 36, the identifier determined in operation 34 is transferred to a network side entity (e.g. the radio access network 22 or the core network 24). The algorithm 30 can therefore be used to provide a user side mechanism to identify a user side application corresponding to a data flow (such as an IP flow, TCP/IP,

UDP/IP, etc.) and transfer the relevant identifier to a network side entity in a way that does not require cooperation from the application.

Each IP flow may be identified by the name of a process that owns the user device side socket terminating the IP flow. One advantage of using the process name (instead of a pre-agreed numerical ID) is that if a new application is developed, the name of that new application can be obtained and transferred to a network side entity, without having to modify the user side mechanism that obtains the name. This enables the

implementation and deployment of the algorithm 30 once at the user device 12, without disrupting the user experience by subsequent updates. Another advantage of using the process name is that such process names can be globally available and observable by any third party (e.g. by running an application in question and checking its process name in the user device). The names therefore do not have to be standardized or maintained in any centralized list.

FIG. 4 is a block diagram of a system, indicated generally by the reference numeral 40, in accordance with an example embodiment. The system comprises a user device side 42 (which may include a user device similar to the user device 12) and a network side 44 (which may include at least some of the network features of the system 20 described above). The user device side 42 comprising a media player 46, an operation system/kernel 47 and a socket monitor 48. (It should be noted that the media player 46 is provided as an example application running on a user device. The principles described herein are independent of the nature of the user application.) For each data flow established by the user device 42, a socket is present at the operating system/kernel 47. The socket monitor 48 observes the establishment of new data flows (thereby implementing operation 32 of the algorithm 30 described above). The owner of the socket is the process that has opened the socket and therefore transfers data via the data flow. The name of the owner may be obtained by the socket monitor 48 using existing standard application program interfaces (APIs) at the user device (thereby implementing operation 34 of the algorithm 30). The details of the owner can therefore be transferred from the socket monitor 48 to the network 44 (thereby implementing operation 36 of the algorithm 30).

FIG. 5 is a block diagram showing further details of the user device 42 of the system 40. The user device 42 includes the operating system/kernel 47 and the socket monitor 48 described above. The user device 42 also includes one or more applications 52 and one or more modems 54 (a plurality of modems are shown in FIG. 5 by way of example only). The socket monitor 48 may be implemented as a software monitor module that is part of a factory software installation of the user device 42, or is installed as an additional application on the user device after it has been produced and shipped to a user. The socket monitor may integrate with the operating system/kernel 47 of the user device on two interfaces: a packet monitoring and header enrichment (HE) interface 55; and a process interface 56. The packet monitoring and HE interface 55 may communicate with one or more sockets 57a, 57b...57h via a netdevice module 58. As noted above, when an application 52 establishes a data flow, a socket 57a, 57b...57h is present at the operating system/kernel 47 and the socket monitor 48 is able to observe the

establishment of the data flow.

FIG. 6 is a flow chart showing an algorithm, indicated generally by the reference numeral 60, in accordance with an example embodiment. The algorithm 60 shows the logical flow of an example use of the system 40. The algorithm 60 starts at operation 62, where the socket monitor 48 monitors data packets (e.g. IP packets) in the system. On the basis of the monitored data packets, the socket monitor (at operation 64) detects when a new data flow (e.g. IP flow) is established (for sending data from an application 52 to the network 44). The socket monitor 48 detects the establishment of new data flows by monitoring or inspecting data packets at the user side. More specifically, the packet monitoring and HE interface 55 has access to the original packets that are sent and received by the user device 42 (e.g., by attaching to the network interface corresponding to the cellular connection). Through this interface, the socket monitor inspects packets and detects the establishment of new data flows. For example, for Transmission Control Protocol (TCP) communications, data flows may be detected by detecting SYN segments. For User Datagram Protocol (UDP) communications, data flows may be detected by detecting a packet with a new IP address/port pair. The packet monitoring and HE interface 55 may be implemented via a kernel module (such as a netfilter target inserted into the user device’s outgoing packet flow) that may not require modification to the existing kernel.

Once the socket monitor 48 has detected a new data flow in operation 64, the algorithm 60 moves to operation 66 where the socket monitor queries the process interface to find out the name of the process that has opened the connection (i.e. the name of a process that has established the data flow referred to above is determined). On

Linux/Android systems, the process interface may be accessed by the socket monitor 48 through opening the /proc/net/* virtual files via common I/O routines (i.e., open, read). The files provide an ASCII interface to a socket list that provides the 5-tuple (source/destination IP addresses, source/destination ports and protocol) of each existing socket (being established or open) and the name of the process that owns the socket. The socket monitor 48 finds the record for the socket that has the same 5-tuple as the first observed packet of the data flow (e.g. IP flow) and reads the name of the owner application from the record. The use of 5-tuple identification is provided by way of example; other arrangements (e.g. other unique identifiers) will be apparent to those skilled in the art. For example, the QUIC (Quick UDP Internet Connection) protocol uses an additional layer of connection identity (CID) on top of the UDP ports and IP addresses. When identifying QUIC traffic, extending the 5-tuple with the CID when identifying the flow to the network side entity may be beneficial.

With the process name identified, the algorithm 60 moves to operation 68, where the process name is transferred to the relevant network side entity (e.g. the network 44). The transfer of the identifier to the network side entity described in operations 36 and 68 described above may be implemented in a number of different ways. Options include a number of in-band methods (e.g. packet marking, tagging, additional headers etc.) and off-band methods (e.g. radio resource control (RRC)). FIG. 7 is a flow chart showing an algorithm, indicated generally by the reference numeral 70, in accordance with an example embodiment. The algorithm 70 shows an example off-band method comprising establishing a connection to the relevant network side entity (operation 71) and providing packets of data including the identifier of the application as part of an off-band data transfer to the second network side entity (operation 72).

FIG. 8 is a flow chart showing an algorithm, indicated generally by the reference numeral 80, in accordance with an example embodiment. The algorithm 80 shows an example in-band method comprising modifying existing packets (that are already being transferred from the user device to the relevant network-side entity) to include the identifier of the application (operation 81) and sending the modified packet to the relevant network entity. Such in-band methods are sometimes referred to as “piggybacking” on existing data traffic. In-band methods can be considered to be self- referencing, in the sense that the identifier is included in a data packet of a flow to which it is related (i.e. the identifier relates to the flow that the data packet forms a part of).

In the case of in-band U-plane transfer, the packet monitoring and HE interface 55 may be used to modify outgoing packets (from the user device 42 to the network 44) to piggyback the process name on subsequent packets sent in the same data flow. The in- band arrangement may include inserting a TCP/IP Option header. In order to facilitate the undisrupted transfer of an application name in the packet headers, a new value in the IP Option Kind or TCP Option Kind space may be allocated and standardized (IANA/IETF). In case of off-band U-plane transfer, the socket monitor 48 may establish a connection to the network side entity (e.g. using IP, for example using a U-plane TCP/IP stack, alternatives include UDP/IP, SCTP/IP etc.). The communication maybe provided through a standard U-plane PDCP/RLC/... path but terminated by a network element or network function in the EPC/5GC instead of an Internet server. This may require that the socket monitor 48 receives the network side IP address and port it has to connect to (e.g., using existing configuration methods or connecting to a captive portal).

In case of off-band C-plane transfer, a radio resource control (RRC) message may be defined that carries the process name as well as the 5-tuple of the IP flow to the eNB/gNB. NAS may be used to transfer the information to the EPC/5GC. It should be noted that the network entity to which the process name is provided (e.g. in operations 36, 68, 72 and 82) may be different from the network entity to which the relevant data flow is being provided (from the relevant application). The data flow may be sent to a server (such as a web server), for example as part of the Internet 26 of the network 20, or some other network. The network entity to which the process name is provided may be part of the communications network, such as a base station or core network function (e.g. the radio access network 22 or core network 24 of the system 20).

In the case of the identifier being provided to a radio access network (e.g. a gNB), the radio access network may use the knowledge of which data flow belongs to which application as part of intelligent QoS/QoE driven actions. The point of QoS interaction at the gNB may be the service data application protocol (SDAP) layer, whose scope is to map QoS flows to data radio bearers (DRBs).

In the case of the identifier being provided to a core network, the core network may use the knowledge of which data flow belongs to which application as part of a QoS application. Here, the UPF may be the entiy point where packets are assigned to QoS flows. For such requirements, knowing the application-flow mapping may be valuable as sometimes QoS/QoE differentiation only make sense if applications can be separated from each other. This would also be an enabler for slicing (application specific overlay networks). Also application specific charging and metering may be possible (under the control of the core network).

It may also be possible and useful to provide the identifier information to both the radio access network 22 and the core network 24.

FIG. 9 is a flow chart showing an algorithm, indicated generally by the reference numeral 90, in accordance with an example embodiment. The algorithm 90 starts at operation 91, where a network entity requests an identifier. Thus, the relevant network entity may comprise means for controlling whether said identifier is provided by the user device to the network-side entity. The network entity may therefore be able to turn the identifier reporting on and off, as desired. At operation 92, the network entity may provide configuration information relating to the identifier request. For example, the configuration information may identify the application for which identifiers are required. More specifically, the network entity may, for example, require that identifiers for all data flows are provided, that a sample (e.g. a random or pseudorandom sample) of identifiers should be reported, or that a specific identifier for a specification application should be provided. One example use of the algorithm 90 is to enable a network entity to target relatively large data flows that generate substantial data and may therefore need to be regulated in some way to maintain QoS/QoE of other users.

At operation 93, the identifier of the relevant application is received at the network entity.

FIG. 10 is a flow chart showing an algorithm, indicated generally by the reference numeral 100, in accordance with an example embodiment. The algorithm 100 shows an example use of the principles described herein.

The algorithm 100 starts at operation 101, where an application corresponding to a data flow from a user-side application 42 to a network-side entity 44 is identified. At operation 102, the identity of the application is used to control quality-of-service (QoS) or quality-of-experience (QoE) variables in some way.

For example, prioritisation of data packet transfers may be determined based on the identity of the application. Thus, for example, time critical data (such as video streaming data) may be prioritised over non-time-critical data (such as the provision of software updates). Thus, the operation 102 may implement a resource allocation arbitrating algorithm. Such prioritization may be restricted to be within the data flows of the same user, e.g. to prioritize one data flow of the user above another data flow of the same user, without changing how much resources other user’s data flow’s receive (intra-user). Alternatively, the prioritization may be implemented across data flows from different users (inter-user).

In the event of insufficient resources, the identification of an application corresponding to a particular data flow may enable alternatives to handling packets in the order they are received to be implemented. Thus, knowledge of the data flow-application mapping can give rise to intelligent context and application aware prioritising. The network side consumer of the process name transferred by the socket monitor 48 to the network 44 may be an entity that performs QoS/ QoE monitoring or application aware traffic management. One example is an intelligent RAN packet scheduler that, based on the application, arbitrates the resource allocation of the data radio bearer (DRB) that serves the application. By receiving the process name from the user device 42 during the establishment of each data flow (e.g. IP flow), the network 44 can unambiguously track which data flow belongs to which application at the user device and may manage QoS flows accordingly (including, for example, the mapping of IP flows to QoS flows and selecting the values for the QoS parameters). Additionally, by knowing the process name, it may be possible to interpret the packet level behaviour of the flows (e.g., observing continuous bulk download patterns with an application that is known to be a dynamic adaptive streaming over HTTP (DASH) client means that the client may not able to reach sufficient throughput and the QoE may be compromised, whereas the same pattern from a software updater does not indicate any problem).

FIG. 11 is a flow chart showing an algorithm, indicated generally by the reference numeral no, in accordance with an example embodiment. The algorithm 110 shows an example use of the principles described herein.

The algorithm 110 starts at operation 111, where an application corresponding to a data flow from a user-side application 42 to a network-side entity 44 is identified. At operation 112, the identity of the application is used to provide an application-specific service. A differential application-based service may be provided to the user. For example, if data transfer for a first application is free of charge, this can only be enabled if the application generating a particular data flow can be identified reliably. Thus, for example, an application-centric data plan could be provided in the operation 112. Other examples of differential application-based services include parental controls in which the identity of an application might be used to determine whether or not the user is allowed to access that application.

For completeness, FIG. 12 is a schematic diagram of components of one or more of the example embodiments described previously, which hereafter are referred to generically as processing systems 300. A processing system 300 may have a processor 302, a memory 304 closely coupled to the processor and comprised of a RAM 314 and ROM 312, and, optionally, user input 310 and a display 318. The processing system 300 may comprise one or more network/apparatus interfaces 308 for connection to a network/apparatus, e.g. a modem which may be wired or wireless. Interface 308 may also operate as a connection to other apparatus such as device/ apparatus which is not network side apparatus. Thus direct connection between devices/apparatus without network participation is possible.

The processor 302 is connected to each of the other components in order to control operation thereof. The memory 304 may comprise a non-volatile memory, such as a hard disk drive

(HDD) or a solid state drive (SSD). The ROM 312 of the memory 314 stores, amongst other things, an operating system 315 and may store software applications 316. The RAM 314 of the memoiy 304 is used by the processor 302 for the temporary storage of data. The operating system 315 may contain code which, when executed by the processor implements aspects of the algorithms 30, 60, 70, 80, 90, 100 and 110 described above. Note that in the case of small device/ apparatus the memory can be most suitable for small size usage i.e. not always hard disk drive (HDD) or solid state drive (SSD) is used. The processor 302 may take any suitable form. For instance, it may be a

microcontroller, a plurality of microcontrollers, a processor, or a plurality of processors.

The processing system 300 may be a standalone computer, a server, a console, or a network thereof. The processing system 300 and needed structural parts may be all inside device/apparatus such as IoT device/apparatus i.e. embedded to very small size

In some example embodiments, the processing system 300 may also be associated with external software applications. These may be applications stored on a remote server device/ apparatus and may run partly or exclusively on the remote server

device/apparatus. These applications maybe termed cloud-hosted applications. The processing system 300 may be in communication with the remote server

device/apparatus in order to utilize the software application stored there. FIGS. 13A and 13B show tangible media, respectively a removable memoiy unit 365 and a compact disc (CD) 368, storing computer-readable code which when run by a computer may perform methods according to example embodiments described above. The removable memory unit 365 may be a memory stick, e.g. a USB memory stick, having internal memory 366 storing the computer-readable code. The memory 366 may be accessed by a computer system via a connector 367. The CD 368 may be a CD- ROM or a DVD or similar. Other forms of tangible storage media may be used.

Tangible media can be any device/apparatus capable of storing data/information which data/information can be exchanged between devices/ apparatus/network.

Embodiments of the present invention may be implemented in software, hardware, application logic or a combination of software, hardware and application logic. The software, application logic and/or hardware may reside on memoiy, or any computer media. In an example embodiment, the application logic, software or an instruction set is maintained on any one of various conventional computer-readable media. In the context of this document, a“memory” or“computer-readable medium” may be any non-transitory media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.

Reference to, where relevant,“computer-readable storage medium”,“computer program product”,“tangibly embodied computer program” etc., or a“processor” or “processing circuitry” etc. should be understood to encompass not only computers having differing architectures such as single/multi-processor architectures and sequencers/parallel architectures, but also specialised circuits such as field

programmable gate arrays FPGA, application specify circuits ASIC, signal processing devices/ apparatus and other devices/ apparatus. References to computer program, instructions, code etc. should be understood to express software for a programmable processor firmware such as the programmable content of a hardware device/apparatus as instructions for a processor or configured or configuration settings for a fixed function device/apparatus, gate array, programmable logic device/apparatus, etc.

As used in this application, the term“circuitry” refers to all of the following: (a) hardware-only circuit implementations (such as implementations in only analogue and/or digital circuitiy) and (b) to combinations of circuits and software (and/or firmware), such as (as applicable): (i) to a combination of processor(s) or (ii) to portions of processor(s)/software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a server, to perform various functions) and (c) to circuits, such as a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation, even if the software or firmware is not physically present. If desired, the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the above-described functions may be optional or may be combined. Similarly, it will also be appreciated that the flow diagrams of Figures 3 and 6 to 11 are examples only and that various operations depicted therein may be omitted, reordered and/or combined.

It will be appreciated that the above described example embodiments are purely illustrative and are not limiting on the scope of the invention. Other variations and modifications will be apparent to persons skilled in the art upon reading the present specification.

Moreover, the disclosure of the present application should be understood to include any novel features or any novel combination of features either explicitly or implicitly disclosed herein or any generalization thereof and during the prosecution of the present application or of any application derived therefrom, new claims may be formulated to cover any such features and/ or combination of such features.