Internet latency management

Abstract

Method and system for managing latency in a broadband connection to a local network, the method comprising the steps of measuring 110, within a network component, latency for a plurality of sections 120 of the broadband connection between a data service and the local network for a plurality of data packets. Determining for each section of the plurality of sections of the broadband connection a distribution of latency using the measured latency for the plurality of sections of the broadband connection between the data service and the local network for the plurality of data packets. Receiving a request 130 and in response to the request, providing data 140 indicating corresponding portions of the distributions for each section of the plurality of sections of the broadband connection.

Description

Field of the Invention The present invention relates to a system and method for monitoring and managing a broadband connection, and in particular, providing data regarding individual broadband connections to third party data service providers or other requesters. Background of the Invention A broadband router or a broadband modem provides internet or data services to one or more clients (e.g., mobile devices, computers or other devices) within a local network, such as a home or office. The broadband router may provide such services over a wired connection (e.g., Ethernet) or more usually using Wi-Fi (RTM). The client may demand services from an external server or data service (e.g., a web page, application, streaming service, etc.) by forming a wired or wireless connection to the broadband router, which is connected to a broadband service (e.g., an internet service provider - ISP). Typically, a domain name system (DNS) within the ISP handles requests from the clients and passes on responses from the server or service provider. Typical service requests and responses will have some level of latency depending on the performance of different parts of the network and the distance between nodes. For example, the Wi-Fi connection can introduce a portion of the latency, the broadband connection between the broadband router and the DNS can introduce further latency and the end service provider or content application provider (and wider internet) can introduce yet more latency. As experienced at the client, it may not be apparent where the latency has been incurred. For some services (e.g., email), latency can have little or no effect on the quality of service. For other services, e.g., gaming or virtual reality applications, latency can have a serious impact on the quality of service. It can therefore be important to identify different sources of latency so that the overall quality of service can be measured and optimised. Internet speed tests are common ways to test a broadband connection. Whilst some internet speed tests include a latency measurement (e.g., 10ms) as part of the test results, such internet speed tests usually involve transferring several MB of data, which can cause a degradation in latency during the test. Furthermore, different contributors of latency in the system are not apparent from such tests. Third party applications operating on devices may rely on the quality and reliability of the broadband connection. Every application may have a minimum level of latency and / or packet loss below which end user experience may be poor or unacceptable. Some applications may be more or less sensitive to the quality of the broadband connection. The application operating within a device within the local network may be able to determine a degradation in latency and report this back to the content or data provider. Whilst this could be used to send a prompt to the user to take some action to improve their broadband connection (e.g., upgrade their router or internet service provider broadband package) there are few options for improving the user’s immediate experience. Therefore, there is required a method and system that overcomes these problems. Summary of the Invention A broadband service provider or other entity within the network has the ability to monitor latency in different sections of an internet connection between a customer or client within their own local network and a plurality of data service providers distributed throughout the internet. For example, the broadband or internet service provider (ISP) can monitor and measure data packet timings (and any losses) from requests originating at the client’s local network to the provision of data from the data service provider or application server. A network component may carry out such tests as and when required, at regular intervals or constantly, for example. The network component may also receive measurement results from other components, such as broadband routers, client devices, application servers or others. Latency conditions may vary dynamically due to instantaneous network events. Therefore, there will be a distribution of latency times for different data packets passing across the broadband connection at different times for even the same client. The network component or other serving entity generates a distribution of latency for each section of the broadband connection that it monitors or receives results from. Some of these sections may be specific for a particular client (e.g., from broadband router to an access node) and some may be the same for different clients (e.g., from a core network to an application server). A distribution of latency values (e.g., times) is generated for each section of the broadband connection and the overall end-to-end connection. This may require a minimum of data packets to determine (e.g., 30, 50, 100, etc.) that can be section dependent. Once the latency or transit times for a sufficient number of data packets have been measured (e.g., a predetermined number) then the different distributions may be generated. Example distributions may be cumulative distribution function (CDF), complimentary CDF (CCDF), or a probability density function (PDF) for example. An external entity (e.g., a data service provider or a server providing the client application with data services) can make a request for latency information from the network component. In response, the network component provides data or values indicating different portions of the distribution for two or more sections of the broadband connection. For example, the network component may respond by providing the 50th and 99th percentile values of each distribution (e.g., from the broadband router of a particular local network to the ISP core and the corresponding percentile values for the end-to-end broadband connection). For example, the response may state “50th percentile (ISP core): 4ms, 90th percentile (ISP core): 9ms; 50th percentile (end-to-end): 8ms, 90th percentile (end-to-end): 15ms” or take another suitable format. The request and response may be achieved using an application programming interface (API), for example. The response may also or alternatively indicate to the requester that a set of requirements for each section in the broadband connection have been met or all requirements for all sections have been met. The request may indicate these requirements, or these may be predetermined and based on request type or requester identity, for example. Therefore, this assessment may be made by the requester or the network component. The request may trigger the collection of data and generation of the distributions, or these tasks may be carried out in the background so that any requests are responded to more quickly with the data kept up to date. The provision of this information on a request basis may provide its own benefits to third parties, such as application providers. However, the information may be used to directly improve the broadband connection of users who are currently experiencing service degradation. Being aware of service degradation caused by latency increases on a peruser basis allows any remedial action to be targeted more effectively. For example, only users currently using particularly latency-sensitive applications need have their broadband connection enhanced. The degree of enhancement may also be determined based on degradation value (e.g., compared to minimum requirements). Actions that may be triggered may include issuing further API requests for temporary broadband enhancements, initiating a local multi-access edge computing (MEC) component and / or instantiating a local or regional virtual machine to service a plurality of nearby end users to reduce latency. In accordance with a first aspect there is provided a method or computer implemented method for managing, measuring or reporting latency in a broadband connection to a local network, the method comprising the steps of: measuring, within a network component, latency for a plurality of sections of the broadband connection between a data service and the local network for a plurality of data packets; determining for each section of the plurality of sections of the broadband connection a distribution of latency using the measured latency for the plurality of sections of the broadband connection between the data service and the local network for the plurality of data packets; receiving a request; and in response to the request, providing data indicating corresponding portions of the distributions for each section of the plurality of sections of the broadband connection. Therefore, information about conditions of a broadband connection on a per user or per group of users basis may be provided on request to external parties. This enables more effective management of broadband connections. For example, dynamic management of the environment may be made. The broadband connection to the local network may terminate at individual client devices within the local network or the broadband connection may be considered to terminate at an edge device (e.g., a broadband router serving the local network). The portions of the distributions (returned in the response) may be a single number indicating a timing or latency time within which a proportion (e.g., 50%) of all data or data packets are returned or communicated in that section of the broadband connection. Optionally, the request may comprise an application programming interface (API) call. APIs can be used to effectively couple and communicate between different entities without significant security or configuration overheads. However, other forms of communication may be used (e.g., based on standard internet protocols). Optionally, the response may further include data indicating a contribution of latency of each section of the broadband connection to an end-to-end broadband connection to the local network. The separate data values in the response may indicate sections having a common starting point (e.g., a client device or broadband router). Therefore, the requester can determine a contribution of latencies from different components of the broadband connection by subtraction. Alternatively, each separate data value may correspond to separate isolated sections. Therefore, an end-to-end latency can be calculated by addition, for example. Optionally, the broadband connection may be provided by a plurality of components comprising two or more of: a client device within the local network; a broadband router of the local network; a Wi-Fi radio within the broadband router; an Ethernet port within the broadband router; a domain name server, DNS; an access node; an edge computing processor; an edge router; the network component; a core network; a core internet service provider, ISP; a transit router; and an application server, and wherein the sections of the broadband connection are between any two or more of the plurality of components. Therefore, any one or more of the sections having their latency measured can start and end at any of these components. Other components or sections may also be considered and have their latency measured. Optionally, the method may further comprise the step of: altering a configuration of the broadband connection based on the response to the request. Further actions may also be taken, triggered or be dependent on the data within the response. One or more configuration changes may be made. The particular configuration change or changes may be dependent on the latency results (e.g., percentile or percentile comparisons). For example, the response data may indicate (or be further analysed and processed to indicate) which sections of the broadband connection require reconfiguring. Rerouting to data may also be carried out. Different application servers may be selected based on the results. Advantageously, the step of altering the configuration of the broadband connection may further comprise the step of increasing a quality-of-service (QoS) parameter for the broadband connection to the local network. This may be a temporary (e.g., only while a particular application or data service is being used) or this may be a permanent change, e.g., moving to a different service or package level of the ISP. Optionally, the step of altering the configuration of the broadband connection may further comprise the step of the server issuing an API call to an ISP providing the broadband connection to the local network. Other communication types may be used. Optionally, the method may further comprise the step of altering a configuration of the local network. This may be especially important when it is determined from the response that significant latency is being caused by the local network (e.g., Wi-Fi issues such as channel collision with neighbouring access points and routers). The local network configuration change may alter transmission power or change channel, for example. This may be achieved without use interaction within the local network. Optionally, altering the configuration of the local network may comprise the step of activating one or more Wi-Fi nodes within the local network. For example, a device such as a smart speaker, may include Wi-Fi node, repeater or mesh capability but is not being used. Any of these capabilities may be activated when determined to be required based on the response and data within the response. Optionally, the step of altering the configuration of the broadband connection may further comprise the step of activating a multi-access edge computing (MEC) component to provide the local network with data services. This can be any other local or processor that is closer (and so lower latency) than an initial application server providing data services to the local network or devices within the local network. Optionally, the distributions of response times may be calculated as cumulative distribution functions, CDF, complimentary CDF, CCDF, or a probability density function, PDF. Other distribution types may be used. Optionally, the latency of a section of the broadband connection within the local network may be determined by a client device within the local network and / or a broadband router within the local network. For example, the client device or broadband router may include testing functionality (e.g., sending “pings”) within the local network. The results of these local timing or local network latency tests or measurements may be reported to the network component, which generates an associated distribution for inclusion in a response. Optionally, the portions of the distributions for each section of the plurality of sections of the broadband connection may be any one or more of a 1st percentile; a 10th percentile; a 50th percentile; a 75th percentile; a 90th percentile; a 99th percentile; and / or a 99.9th percentile (P1, P10, P50, P75, P90, P99, and / or P99.9). Other percentiles, or divisions and portions (e.g., quartile, decile, etc.) may be used. The request may further include the specific percentiles or other portions of the distribution that are required (for example, 50th, 90th, and 99.9th). The values may be selected from a pre-defined menu of options, for example. Alternatively, a comprehensive or default set may be provided in response to every request (for example, P1, P10, P50, P75, P90, P99 and P99.9). Optionally, data of the distributions for each section of the plurality of sections of the broadband connection may be stored in a database and the step of providing data indicating corresponding portions of the distributions for each section of the plurality of sections of the broadband connection may further comprise retrieving the data from the database. A combination of stored (historical) and current latency results may also be used. Optionally, the request may trigger the measuring step. The measurements may then be performed on demand to reduce processing requirements or may be regularly generated in case a request is made, which enables much faster responses to be generated as the distributions may be maintained up to date. Optionally, the measuring step may further include recording a time of the measurement and / or the response may further include data indicating the recorded time or time range of the measurements. Therefore, the response can indicate a period when the latency data were measured, for example. Furthermore, the request may optionally include a duration of the measurement or data indicating this duration, e.g., the request can include an identifier of a set of possible durations (or “long” or “short” duration). In an example implementation, a requested short test may provide a response from a measurement time lasting seven seconds and a request for a long duration test may provide a response from a set of measurements lasting 25 seconds. Other durations may be requested. The requested duration may therefore determine how many individual measurements may be made with improved accuracy provided for longer tests at the expense of an increases in response delay. For continuous measurements, which are stored or cached then such delays may be reduced avoided. In accordance with a second aspect, there is provided a network component comprising means adapted to execute any or all of the method steps described above. In accordance with a third aspect, there is provided a system or computing system comprising: a network component external to a local network and configured to: measure latency for a plurality of sections of a broadband connection between a data service and the local network for a plurality of data packets; determine for each section of the plurality of sections of the broadband connection a distribution of latency using the measured latency for the plurality of data packets; receive a request; and in response to the request, provide data indicating corresponding portions of the distributions for each section of the plurality of sections of the broadband connection. The methods described above may be implemented as a computer program comprising program instructions to operate a computer. The computer program may be stored on a computer-readable medium, including a non-transitory computer-readable medium. The computer system may include a processor or processors (e.g., local, virtual or cloud-based) such as a Central Processing Unit (CPU), and / or a single or a collection of Graphics Processing Units (GPUs). The processor may execute logic in the form of a software program. The computer system may include a memory including volatile and nonvolatile storage medium. A computer-readable medium (CRM) may be included to store the logic or program instructions. For example, embodiments may include a non-transitory computer-readable medium (CRM) storing software comprising instructions executable by one or more computers which, upon such execution, cause the one or more computers to perform the disclosed methods. Non-transitory CRM may refer to a CRM that stores data for short periods or in the presence of power such as a memory device or Random Access Memory (RAM). For example, a non-transitory computer-readable medium may include storage components, such as, a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, and / or a magnetic tape. The different parts of the system may be connected using a network (e.g. wireless networks and wired networks). The computer system may include one or more interfaces. The computer system may contain a suitable operating system such as UNIX, Windows (RTM) or Linux, for example. It should be noted that any feature described above may be used with any particular aspect or embodiment of the invention. Brief description of the Figures The present invention may be put into practice in a number of ways and embodiments will now be described by way of example only and with reference to the accompanying drawings, in which: FIG. 1 shows a schematic diagram of a broadband connection to a local network; FIG. 2 shows a flowchart of a method for managing and / or monitoring latency the broadband connection; FIG. 3 shows a schematic diagram of a computer system used to implement the method of Figure 2; FIG. 4 shows a further schematic diagram of the broadband connection to the local network and how different section of the broadband connection contribute to latency; FIG. 5 shows a schematic diagram of a message format generated using the method of Figure 2; FIG. 6 shows a schematic diagram of an architecture used to implement the method of Figure 2; FIG. 7 shows a graphical illustration of latency requirements for a computer application utilising the broadband connection of Figure 1; FIG. 8 shows a further graphical illustration of latency requirements for a computer application utilising the broadband connection of Figure 1, illustrating an application at a limit of acceptable latency; FIG. 9 shows a further graphical illustration of latency requirements for a computer application utilising the broadband connection of Figure 1 and illustrating a limit of acceptable latency for an application; FIG. 10 shows a schematic diagram of a local network having a broadband connection and a graph showing a distribution of latency for different sections of the broadband connection; FIG. 11 shows a further schematic diagram of a local network having a broadband connection and a graph showing a distribution of latency for different sections of the broadband connection in more detail; FIG. 12 shows graphical results of latency measurements for different sections of the broadband connection of Figure 1, and how these results can be compared; FIG. 13 shows a graphical illustration of a time series of latency measurements; FIG. 14 shows a graphical illustration of a distribution of latency for different sections of the broadband connection; FIG. 15 shows further graphical results of latency measurements for different sections of the broadband connection of Figure 1; FIG. 16 shows example results using different distribution types for the latency measurements of different sections of the broadband connection of Figure 1; FIG. 17 shows and graphical illustration of cumulative probability and response times for different data packets of the broadband connection of Figure 1; FIG. 18A shows a graphical illustration of a set of latency measurements; FIG. 18B shows a graphical illustration of the distribution of latency measurements of Figure 18A; FIG. 18C shows a graphical illustration of a set of latency measurements using a larger data set to the graph of Figure 18A; and FIG. 18D shows a graphical illustration of the distribution of latency measurements of Figure 18C. It should be noted that the figures are illustrated for simplicity and are not necessarily drawn to scale. Like features are provided with the same reference numerals. Detailed description of the preferred embodiments Figure 1 illustrates schematically a system 10 for providing broadband internet services to a local network 12, such as a home or office environment. One or more client devices 20 such as laptops, mobile devices, Internet of Things (loT) devices, etc., are served by a broadband router 30. This may be either using a wired connection (e.g., Ethernet) or Wi-Fi, for example. Each client device 20 may have one or more applications 15 that require an internet connection. Each application 15 may have its own broadband quality requirement such as latency, reliability, jitter, and bandwidth. The broadband router 30 has an external access connection and interface to an access node 40 using different types of connections. These may include copper wire, microwave link, cellular connection, or fibre optic cabling. These connections provide back haul services to an internet service provider (ISP) core 60 through an edge router, or broadband network gateway (BNG) 50, for example. The ISP core 60 may interface with the wider internet 80 through a transmit router 70 or by other means. One or more data service provides or application servers 90 may have their own connections to the internet 80. Therefore, an internet connection may be defined as from the client device 20 or broadband router 30 through each section of the broadband connection across the various nodes to the application server 90. When particular latency requirements for any of the applications 15 are not met then users of the client device 20 may experience adverse application performance, as illustrated in Figure 1 (see application 15). Figure 2 shows a flow chart of a method 100 for managing latency in a broadband connection to a local network 12. This method 100 is shown as a high level with further example details provided throughout this description. At step 110, the latency for various sections of the broadband connection (e.g., as illustrated in Figure 1), are measured. There are various ways in which the latency may be measured but in general, the time taken for data or data packets to traverse different sections of the broadband connection corresponds with the latency in those sections. The different sections may include a path from the broadband router 30 and / or any individual client devices 20 through to an application server 90 providing those client devices 20 with data services. Multiple latency measurements for each section in the broadband connection may be measured. At step 120, a distribution of latency (e.g., times) is determined from these multiple measurements. Each distribution may indicate percentile or other divisions within which a proportion of the data packets are delivered. For example, for a 1st percentile of latency, only the fastest transit time would be included (i.e., only a latency time is determined so that exactly 1% of data packets are returned within this time). Therefore, the 1st percentile may be provided in terms of a low latency value (e.g., 5ms). In contrast, the 99th percentile includes a much larger latency within which 99% of data packets are delivered. For example, the 99th percentile of the distribution may be a latency of 15ms. At step 130, a request is received. This may be received from any particular entity but in an example implementation this may be from an entity associated with the application server 90 or the application server 90 itself. The request may take different forms but may include an identifier of a user or client device 20 or another way to identify the local network 12. The request may also include other parameters such as any one or more of an identifier of the requester, multiple end user identifiers in a single request the content and detail level of the requested response. At step 140, a response is made to the request. The response includes data indicating the portions of the distribution (e.g., 50th, 90th, 99th, etc.) and the percentile values for each section in (preferably) milliseconds of the broadband connection (e.g., from the broadband router 30 to the core ISP 60). The response includes values for different sections of the broadband connection and may also include an overall end-to-end latency (again for each percentile provided) for the entire route. Whilst the response requires steps 110 and 120 to take place before being able to provide the information, the request may be received either before or after steps 110 or 120 or at any time. An example implementation of the request may trigger the measurement of the latency and / or the determination of the latency distributions for each section. At step 150, an action may be taken based on the data within the response. This may be an optional step and the action may take different forms. Furthermore, the action may be taken by different entities including the application server 90, the requester of the data (which may also be the application server 90), a component within the local network 12, or another entity. The action may include steps needed to enhance any or all portions of the broadband connection. Different actions may be executed by different entities. In particular, these actions may enhance the provision of the broadband connection provided by the ISP core 60, such as allocating more resources to a particular broadband router 30, including prioritising data packets or individual data packets from different types of application servers 90. Alternatively, the actions may degrade latency if the latency requirements of the application are being met far in advance of their requirements. Deep packet inspection or other techniques may be used to determine which data packets require enhanced treatment, for example. Test data packets may also be used to measure latency. Other actions may include activating a multi-access edge computing (MEC) component located close to the broadband router 30 (e.g., at the access node 40). The action may also include steps used to enhance the broadband connection for multiple users or groups of users. For example, if an application server 90 determines that a new group of users is forming in a particular location or country, it may be determined from multiple responses to implement a virtual machine (VM) within that country or region so that the application server 90 or an instantiation of that application server 90 is located closer to a group of end users. This further reduces latency in their collective broadband connections. The method 100 described with reference to Figure 3 is implemented in a computer system that may form part of a network component (e.g., within the ISP core 60). As shown in Figure 3, the computer system 300 may include a number of components including communication interfaces 320, system circuitry 330, input / output (I / O) circuitry 340, display circuitry (not always necessary) and interfaces 350, and a datastore 370. The system circuitry 320 can include one or more processors or CPUs 380 and memory 390. The system circuitry 330 may include any combination of hardware, software, firmware, and / or other circuitry. The system circuitry 330 may be implemented, with one or more systems on a chip (SoC), application specific integrated circuits (ASIC), microprocessors, and / or analog and digital circuits. The display circuitry may provide one or more graphical user interfaces (GUIs) 360 and the I / O interface circuitry 340 may include touch sensitive or non-touch displays, sound, voice or other recognition inputs, buttons, switches, speakers, sounders, and other user interface elements. The I / O interface circuitry 340 may include microphones, cameras, headset and microphone input / output connectors, Universal Serial Bus (USB) connectors, and SD or other memory card sockets. The I / O interface circuitry 340 may further include data media interfaces (e.g., a CD-ROM or DVD drive) and other bus and display interfaces. The memory 390 may include volatile (RAM) or non-volatile memory (e.g., ROM or Flash memory). The memory may store the operating system 392 of the computer system 300, applications or software 394, dynamic data 396, and / or static data 398. The datastore or data source 370 may include one or more databases 372, 374 and / or a file store or file system, for example. The method and system may be implemented in hardware, software, or a combination of hardware and software. The method and system may be implemented either as a server comprising a single computer system or as a distributed network of servers connected across a network. Any kind of computer system or other electronic apparatus may be adapted to carry out the described methods. Figure 4 shows a further schematic diagram of the broadband connection providing internet services to the local network 12. Under this figure are a series of arrows (410-450) indicating different portions of the broadband connection. In this example, each arrow starts at the client device 20 but the different portions may start and end at any of the components (20-80) forming the end-to-end broadband connection. Each portion of the broadband connection may contribute a different amount to the overall latency. The response to the request for latency information may include any or all CDF (or other distribution types) percentiles or portions of the distribution. From this information, the requester may be able to determine which contributions to latency are acceptable or high and whether or not action may be taken to bring the end-to-end latency below an acceptable level for a particular service or application provided to the user within the local network. For example, if a portion of the latency is due to the section of broadband connection between the application server 80 and the internet then this may be under the control of the service provider. If latency is high (or has increased over time) from the core ISP 60 to the broadband router 30 then a further (e.g., temporary) request may be made (e.g., using an API call) from the application server 80 to the ISP for an improvement in quality for one or more users. In an example implementation, a user of a client device 20 within the local network 12 may start an application that requires low latency (e.g., a virtual reality headset and game). At the time that the application is initiated or soon after (e.g., when the application server 80 becomes aware of the new connection) then the application server 80 may make an API call (request) to the network component within the core ISP 60. The network component may have already been measuring latency of different sections of the broadband connection to the particular local network 12 or may initiate such tests when the request is received. The tests may be limited to data for the particular application, be test data packets or include any data packets served to the local network 12. Once sufficient data has been collected (e.g., a minimum number of data packets have been communicated) then the network component may generate a distribution of timings or latency for each section of the broadband connection. The measurement results may also be stored in a database. The response to the API call may then include particular portions (e.g., percentiles) of these separate distributions for this particular client device 20 or local network 12. The API call (request) may include an indication of the particular portions (percentiles) of the distributions to provide or a standard or default set may be provided. Figure 5 shows a schematic diagram illustrating the format of the response. In the example shown in Figure 4, five different CDFs are generated and provided. Therefore, N=5 in a response for this particular example. Any number may be provided. In this example, three percentiles are provided (50th, 90th and 99th) but any number and combination may be used. The API response includes a stream of data values. In this example, each distribution (e.g., CDF) may correspond with a predetermined section of the broadband connection and so the numbers indicate each portion. The format of the response may take the form of: [CDF1: P50, P90, P99], [CDF2: P50, P90, P99] .... With the PXX values replaced by numerical values in milliseconds. The request or API call may include a duration of the measurement or data indicating this duration, as defined by the requester. For example, the request (or API definition) may include an identifier of a set of possible durations (e.g., “long” or “short” duration that may be defined in the request or call. In an example implementation, a requested short test may provide a response from a measurement lasting seven seconds and a request for a long duration may provide a response from a measurement of 25 seconds. Other durations may be requested (e.g., 1,10, 20, 30, 60 seconds). The requested duration may determine the resolution or accuracy of the distribution, as more data packets may be investigated during longer measurement periods. Alternatively, the request may indicate a desired accuracy (e.g., high or low), resulting in longer or shorter measurement durations. Figure 6 shows a schematic diagram illustrating how a third party application provider 600 (that may operate the application server 90) makes the request and receives a response from the network component of the core ISP 60. This may be achieved using a network platform abstraction 610. A published API 620 facilitates the request and response in the form of API calls. The network platform abstraction 610 obtains data and measures the broadband network 630. In this way, network latency performance is conveyed to third parties. The API may be provided by the Vodafone network as a platform (NaaP) system, for example. This system and method allow third parties such as Application developers to understand network performance and where latency is being accrued, potentially causing degradation to application performance for their customers. It also enables actions and processes to take place to improve satisfaction and performance. Quantitative Timeliness Agreements (QTAs) allow a common language for applications and networks. Every application that requires an internet connection has some level of latency and packet loss beyond which it will deliver poor a quality of experience for the end user. The CDF values provided by the system and method provide an indication of this loss and delay. Figure 7 shows a simplified example graph illustrating this point. Line 710 illustrates the measured response time or latency. Line 720 illustrates a particular requirement for an individual application. In this example, the requirement line 720 shows that 50% of responses need to be made within 5ms and 95% of responses within 10ms for an adequate user experience. There may be an overall 0.1% failure rate (packet loss) that is acceptable. In the example shown in Figure 7, the requirements are met. Providing the CDF percentiles enables this to be determined by the requester of the data. In summary, any CDF whose curve is always to the left and above of the requirements line indicates an outcome that is “acceptable”. If the lines cross, then there may be performance hazard. Thresholds on the CDF can be used to express network capability (end-to-end and per link), application requirements and service level agreements (SLAs). However, the exact “threshold” (i.e. 99%, 99.5%, 99.9% ...) varies by application and for example, control plane vs user / data plane traffic. This is related to “ensuring fitness for purpose” in the data transport. Having such differentiation is useful and can avoid “quality creep” where, because an operator doesn’t have this information, they can’t determine what network conditions are required to fulfil a stringent requirement. This can lead to wasted resources as all (or a large fraction) of the traffic needs to be handled with higher than necessary performance to guarantee that the requirements are met. This can lead to inefficiencies. Figure 8 illustrates a point at which degradation becomes apparent to users and Figure 9 shows when operation is not possible at all. Figure 10 shows a schematic diagram illustrating two sections of the broadband connection to a local network 11 that obtains internet services. The latency contribution to the overall broadband connection generated from the local network is shown by the left line on the graph. The contribution of latency by the remaining portions of the broadband connection is shown as the right line. Figure 11 shows schematically a similar broadband connection but with greater granularity (i.e., three sections of the broadband connection in this example). Again, CDF distributions are shown for each section (local network), broadband router 30 to core ISP 60, and core ISP to application server 90. These CDF distributions are shown as the three lines (left to right respectively) in the graph of this figure. Figure 12 shows further example latency distributions for two sections of the broadband connection (within the local network and internet latency). This figure illustrates one possible way in which the latency data can be compared but there may be many others. In this example, a simple numerical percentage can be considered. A difference or ratio between P50, P90 &P99 CDFs may be compared for different sections of the broadband connection to the end-to-end latency of the full broadband connection (e.g., to the client device 20 from the application server 90). This may be a round-trip latency, for example. An advantage of this procedure is that it is easy to calculate and results may be stored efficiently. If the CDF percentiles for both sections of the broadband connection are labeled as Ph (home router or local network 12) and Pi (internet latency), then the home router latency portion as a fraction of the overall Internet latency could be estimated as: Home router latency as % of Internet latency = (Ph50 + Ph90 + Ph99) / (Pi50 + Pi90 + Pi99) x 100 This uses the 50th, 90th and 99,h percentiles for each distribution. The above equation provides a simple relative percentage comparison for the requester of the information to use or pass on to end users. When latency measurement granularity is increased then latency measurements to a server in the broadband operator’s network (core ISP 60) may also be included in the equation and subsequent calculations. These values may be labelled as Pn50, Pn90, Pn99). Therefore, these may also be included as a percentage or fraction of the overall end-to-end broadband latency as well. For example, Core ISP latency as % of Internet latency = (Pn50 + Pn90 + Pn99) / (Pi50 + Pi90 + Pi99) x 100 Any combinations may be used and presented as an output to be used to assess or compare the performance of any sections of the broadband connection. Figures 13 and 14 illustrate graphically an example of a network latency spike and the effect and implications of particular percentiles that are investigated. This provides data that may be used to select appropriate percentiles from the distributions under different conditions or to determine different types of performance and network behaviour. This also illustrates a need for flexibility in such selections. For example, the request may also include the percentiles (or other values) that need to be returned. Therefore, different requesters may request different data to be used according to their own requirements. A latency spike may become apparent when one (or more) of the latency measurements is obtained that exceeds the highest latencies measured on for the end-to-end broadband connection measurements (e.g., these may be taken at different times). This could be due to a transient traffic burst loading network equipment buffers. If traffic load and / or impact is of particular interest, then the P99.9 (99.9th) percentile may be requested or investigated. However, if the objective is to compare the (non-loaded) relative latency contributions of the various broadband sections or domains, then the P1 (1st) and P50 (50th) percentile CDF values may be of more interest. There may be different ways to measure latency. However, the described methods are independent of the latency measurement protocol, e.g., Internet Control Message Protocol (ICMP), two way active measurement protocol (TWAMP), STAMP, etc. Any or all of these protocols and others may be used. The network measurement technique, granularity (number of measurement data points used to construct the CDFs), accuracy, and / or number of network sub-domains offered can change over time, as implemented by the network operator (ISP) independent of the API or any other request and response technique. Use of an API abstracts the detail and complexity from the API customer (e.g., the application developer or data service provider). As illustrated schematically in Figure 15, the requester or in this example, the API customer or call can obtain full control when obtaining the CDF results. The results can indicate where performance bottlenecks are found, and measures or actions may be taken to address them so that application performance can be maintained. Alternatives to CDF percentiles could also be provided in response to the request (e.g., the API call). Other statistical distributions may be used such as probability density function (PDF), complimentary CDF (CCDF), or CCDF with log scale. Examples of these distributions are shown in the graphs of Figure 16. Better network performance on the CDF plot may be indicated by few or no dropping of packets of data (i.e., with a probability of return of a data packet to a request rising to one). A desirable latency characteristic may also be indicated by a rapid rise in the curve. This can indicate that a large percentage of the measured traffic has low and consistent latencies, hence low jitter (variation). Conversely, undesirable latency measurement result characteristics may be indicated by higher dropped packet percentages and highly variable (high jitter) latencies. The lower plots in Figure 16 illustrate a request determining requirements for a particular application or data service and then comparing the measured and returned results with these requirements. Actions may be taken or triggered when performance in one or more sections of the broadband connection don’t meet these determined or predetermined requirements. Using a fixed percentile of latency, such as the 99th or 99.9th percentile, has the benefit of capturing relatively rare events. These metrics can help offset the problems with using a simple mean by including information about the size of latencies in the tail of the distribution. One problem with using only the 99th percentile (or any other percentile) is that it can also hide information. As demonstrated in the graph of Figure 17, including the P50 and P90 percentiles may better distinguish between the CDFs on the right, which both have the same P99 percentile. The particular selection of CDF percentiles in any subsequent calculation or comparison may depend on an objective of the analysis. The lower percentiles (e.g., 1st and 50th) provide insight into “structural” differences, e.g., due to network topology and technology. The 1st percentile could indicate the best achievable latency on that part of the broadband connection when traffic loading is lowest (i.e., an emptier network) and where IP packets are smallest. However, if the objective is to assess the impact of traffic load variation / spikes, then the 90th to 99.9th percentile range may be more appropriate. For example, if an application 15 at the client device 20 has to wait a significant time for the last packet of a “chunk” of data representing a video image before it can decode and render the picture, that may be responsible for any perceived lag. Outliers around the 99.9% point may determine the impact on the perception and quality of experience (QoE) of the application’s performance. Comparing the difference between the high percentiles vs the low percentiles provides an indication of how much network latency degrades when it is more loaded (e.g., in the evening busy hour) - and an indication of the network’s capacity headroom and congestion management. It is possible to work with latency distributions on their own, without including the packet loss percentage. This metric does provide some of the properties of quality attenuation, such as the ability to add the contributions of different network segments when computing end-to-end delay or assigning budgets. However, if the ability to compute application outcomes is required then it is preferable to include packet loss because packet losses can contribute a lot to the user-perceived performance. Packet loss information can be included in the response (e.g., API response), for example. Figures 18A-D illustrate graphically how the volume of measurements can affect results (e.g., accuracy and run-time). Figure 18A shows example results with five network pings (a network timing utility) for each packet size under investigation (six), resulting in 30 measurements per target IP address and executing in 8 seconds. Figure 18C illustrates results from using 20 pings for each packet size, resulting in 120 measurements per target IP address and running in 33 seconds. These time series plots illustrate more granular results with four times the number of measurements. Figure 20B shows the CDF distribution of the results of Figure 18A. Figure 18D shows the CDF distribution of the results of Figure 18B. In can be noted that the CDF diagrams, which show the statistical distribution of the results, appear to be extremely similar. This demonstrates that using fewer data points (network pings) does not significantly adversely affect the statistical distribution (CDF) but will reduce the run time of the measurement. There will be a minimum value of required measurements, however. The measurement volume can be tuned or varied for each section or segment in the broadband connection. Despite the time series looking more coarse, the key statistics are effectively invariant over the time scale of these two measurement sets (which took place within 3 minutes of each other). Hence if we derive key performance metrics (e.g. 50 percentile latency, 99 percentile latency etc.) from the CDF, it is acceptable (no detriment to interpretation of the results) to use the reduced number of data measurements that will fit within a runtime design target of less than 10 seconds. Whilst the CDFs don’t necessarily change significantly with a longer test or measurement duration, this may be more apparent when analysing lower percentiles (<P50), which can reflect structural delay in the network. However, if the API user or requester needs to explore the higher percentiles in more detail (e.g., >P99) to assess the occurrence of occasional latency spikes, then requesting a longer test via the API could be advantageous. For such implementations, the request can define more precisely what percentiles are required and the duration of the measurements. As used throughout, including in the claims, unless the context indicates otherwise, singular forms of the terms herein are to be construed as including the plural form and vice versa. For instance, unless the context indicates otherwise, a singular reference herein including in the claims, such as "a" or "an" (such as an ion multipole device) means "one or more" (for instance, one or more ion multipole device). Throughout the description and claims of this disclosure, the words "comprise", "including", "having" and "contain" and variations of the words, for example "comprising" and "comprises" or similar, mean "including but not limited to", and are not intended to (and do not) exclude other components. Also, the use of “or” is inclusive, such that the phrase “A or B” is true when “A” is true, “B is true”, or both “A” and “B” are true. The use of any and all examples, or exemplary language ("for instance", "such as", "for example" and like language) provided herein, is intended merely to better illustrate the disclosure and does not indicate a limitation on the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure. The terms “first” and “second” may be reversed without changing the scope of the disclosure. That is, an element termed a “first” element may instead be termed a “second” element and an element termed a “second” element may instead be considered a “first” element. Any steps described in this specification may be performed in any order or simultaneously unless stated or the context requires otherwise. Moreover, where a step is described as being performed after a step, this does not preclude intervening steps being performed. It is also to be understood that, for any given component or embodiment described throughout, any of the possible candidates or alternatives listed for that component may generally be used individually or in combination with one another, unless implicitly or explicitly understood or stated otherwise. It will be understood that any list of such candidates or alternatives is merely illustrative, not limiting, unless implicitly or explicitly understood or stated otherwise. Unless otherwise described, all technical and scientific terms used throughout have a meaning as is commonly understood by one of ordinary skill in the art to which the various embodiments described herein belongs. As will be appreciated by the skilled person, details of the above embodiment may be varied without departing from the scope of the present invention, as defined by the appended claims. For example, whilst the application server or service provider is described as requesting the data, the requests (e.g., API requests) may come from any party or entity, including the ISP, end-user or external monitoring service. The response may also include a timestamp indicating when the latency measurements used to generate the distributions were carried (or a time period). The latency measurements may use the same data packet size or a selection of data packets sizes. This can contribute to the difference in latency for particular sections. For example, the different packets sizes may be any of 64B, 128B, 256B, 512B, 1024B, and / or 1444B. Whilst a fixed line broadband connection has been described, the method and system may be expanded to wireless broadband connections or cellular networks, for example. The request or API customer can calculate quality of outcome QoO or any other metric themselves based on the response to their requests. Many combinations, modifications, or alterations to the features of the above embodiments will be readily apparent to the skilled person and are intended to form part of the invention. Any of the features described specifically relating to one embodiment or example may be used in any other embodiment by making the appropriate changes.

Claims

1. A method for managing latency in a broadband connection to a local network, the method comprising the steps of:measuring, within a network component, latency for a plurality of sections of the broadband connection between a data service and the local network for a plurality of data packets;determining for each section of the plurality of sections of the broadband connection a distribution of latency using the measured latency for the plurality of sections of the broadband connection between the data service and the local network for the plurality of data packets;receiving a request; andin response to the request, providing data indicating corresponding portions of the distributions for each section of the plurality of sections of the broadband connection.

2. The method of claim 1, wherein the request comprises an application programming interface, API, call.

3. The method of claim 1 or claim 2, wherein the response further includes data indicating a contribution of latency of each section of the broadband connection to an end-to-end broadband connection to the local network.

4. The method according to any previous claim, wherein the broadband connection is provided by a plurality of components comprising two or more of:a client device within the local network;a broadband router of the local network;a Wi-Fi radio within the broadband router;an Ethernet port within the broadband router;a domain name server, DNS;an access node;an edge computing processor;an edge router;the network component;a core network;a core internet service provider, ISP;a transit router; andan application server, and wherein the sections of the broadband connection are between any two or more of the plurality of components.

5. The method according to any previous claim further comprising the step of: altering a configuration of the broadband connection based on the response to the request.

6. The method of claim 5, wherein the step of altering the configuration of the broadband connection further comprises the step of increasing a quality of service parameter for the broadband connection to the local network.

7. The method of claim 5 or claim 6, wherein the step of altering the configuration of the broadband connection further comprises the step of the server issuing an API call to an ISP providing the broadband connection to the local network.

8. The method according to any of claim 5 to 7 further comprising the step of altering a configuration of the local network.

9. The method of claim 8, wherein altering the configuration of the local network comprises the step of activating one or more Wi-Fi nodes within the local network.

10. The method according to any of claims 5 to 9, wherein the step of altering the configuration of the broadband connection further comprises the step of activating a multiaccess edge computing, MEG, component to provide the local network with data services.

11. The method according to any previous claim, wherein distributions of response times are calculated as cumulative distribution functions, CDF, complimentary CDF, CCDF, or a probability density function, PDF.

12. The method according to any previous claim, wherein latency of a section of the broadband connection within the local network is determined by a client device within the local network and / or a broadband router within the local network.

13. The method according to any previous claim, wherein the portions of the distributions for each section of the plurality of sections of the broadband connection are any one or more of a 1st percentile; a 10th percentile; a 50th percentile; a 75th percentile; a 90th percentile; a 99th percentile; and / or a 99.9th percentile.

14. The method according to any previous claim, wherein data of the distributions for each section of the plurality of sections of the broadband connection are stored in a database and the step of providing data indicating corresponding portions of the distributions for each section of the plurality of sections of the broadband connection further comprises retrieving the data from the database.

15. The method according to any previous claim, wherein the request triggers the measuring step.

16. The method according to any previous claim, wherein the measuring step further includes recording a time of the measurement and / or the response further includes data indicating the recorded time or time range of the measurements.

17. A network component comprising means adapted to execute the steps of the method according to any previous claim.

18. A system comprising:a network component external to a local network and configured to: measure latency for a plurality of sections of a broadband connection between a data service and the local network for a plurality of data packets;determine for each section of the plurality of sections of the broadband connection a distribution of latency using the measured latency for the plurality of data packets;receive a request; andin response to the request, provide data indicating corresponding portions of the distributions for each section of the plurality of sections of the broadband connection.27

Images