Network latency testing

Abstract

Method and system for testing network latency, comprising a browser of a computer within a local network, downloading a first WebRTC client application. The first WebRTC client application making a connection over the internet with a control server external to the local network. The control server transmitting data causing a communication connection to be set up between the first WebRTC client application and a second WebRTC client application. Transmitting a plurality of data packets between the first WebRTC client application and the second WebRTC client application and reflected back to an originating WebRTC client application, wherein one of the first WebRTC client application and the second WebRTC client application is the originating WebRTC client application. The originating WebRTC client application determining a round-trip time, RTT, of the plurality of data packets. The second WebRTC client may be external to the local network and communicated with across the internet. The originating WebRTC client application may also determine a packet loss related to the plurality of data packets. The control server may collect RTT measurements and may determine an action to take based on local network parameters and the determined RTT. The plurality of packets may have different packet sizes.

Description

Field of the Invention The present invention relates to a system and method for monitoring and managing broadband connections, and in particular, providing data regarding individual broadband connections and measuring latency incurred within a local network and across the internet. 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). 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 a 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, video conference, 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. 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. Different devices within the same local network may experience different amounts of latency. This can be due to the location of the particular device (e.g., laptop computer or smartphone), software running on the device or hardware limitations. Again, a user of each device will not be able to determine the cause of their device’s latency, if moving the device will improve this, or if other configuration or software changes will have a beneficial effect. Furthermore, a user may blame their internet service provider for poor broadband performance even though this may be caused by their local network or other parameters. Therefore, there is required a method and system that overcomes these problems. Summary of the Invention Web Real-Time Communication (WebRTC) enables peer-to-peer communication and streaming services using application programming interfaces (APIs). All common web browsers include WebRTC, which removes the need for plugins and dedicated applications to be downloaded to local machines. Instead, a standardise approach can be used for such communications. WebRTC includes capability for traversal of Network Address Translation implementations, such as might be implemented in a broadband router. This capability enables peer-to-peer connections to be created between endpoints that cannot otherwise easily communicate with each other. Instead of using WebRTC to set up peer-to-peer video, audio or data collaboration communications, WebRTC client applications on different machines initiate and configure end points so that multiple connections can be made to measure latency. Data packets are transmitted between these end points and the transit times of the data packets are measured to determine the latency values between the different end points and for end-to-end communication. This may be achieved by using data packets sequence numbers, time stamps within data packet headers or other identifiers and timing mechanisms. When a data packet is received by a WebRTC client application, it is reflected back to the source. When the reflected data packet arrives at its originator, its transit time, latency and any packet loss can be determined. The originator of the data packets can be another WebRTC client application within the same local network or a WebRTC client application external located external to the local network (i.e., across the internet). A control server can determine which WebRTC client application should be the originator and which WebRTC is a reflector of incoming data packets. These designations can be varied within the same or different tests or measurements. A WebRTC client application is within a browser of a machine (e.g., smart phone, laptop computer, tablet computer, or desktop computer) within the local network. This WebRTC client application may be downloaded from a web server when a particular web page is visited by the browser. The WebRTC client application may also be descrbribed as a WebRTC client or WebRTC code. The local network can be a home, office, or other location served by a gateway or router (e.g., a Wi-Fi router). The data packets returned to the originating WebRTC client application can contain data indicating each hop or segment in a data packet route. For example, a plurality of data packets can be sent through the internet (or within the local network) from the originating WebRTC client application, to reflect or pass-through WebRTC client applications. Different types of information can be obtained once the reflected data packets have been received enabling the time spent on each hop, including the time within the local network, to be determined by the originating WebRTC client application and / or the control server. For example, the transmission and receipt times may be recorded and compared to determine travel time. Therefore, latency in different parts of the internet and within the local network can be measured and monitored. For example, this information may be used to determine how much delay is encountered within the local network compared with the internet. Different actions can be taken based on this latency information (and / or data loss). For example, the user can be instructed to move the machine hosting a particular WebRTC client application closer the gateway or Wi-Fi router, update firmware or software, add memory, close windows or browser tabs or other actions. Automatic actions may also be taken, such as switching WiFi channels on the Wi-Fi router, increasing or decreasing Wi-Fi transmission power, applying data packet prioritisation schemes within an internet service provider, etc. These actions can improve the performance of the communication system for individual users or groups of users. A plurality of WebRTC client applications can be set up within different machines within the same local network. Therefore, issues and problems within a local network can be diagnosed more easily. For example, if a WebRTC client application in one machine exhibits much greater latency or data packet loss than another machine then that could indicate a hardware, software or networking performance issue or failure. In accordance with a first aspect there is provided a method for testing network latency, the method comprising the steps of: a browser of a computer within a local network, downloading a first WebRTC client application; the first WebRTC client application making a connection over the internet with a control server external to the local network; the control server transmitting data causing a communication connection to be set up between the first WebRTC client application and a second WebRTC client application; transmitting a plurality of data packets between the first WebRTC client application and the second WebRTC client application and back to an originating WebRTC client application, wherein one of the first WebRTC client application and the second WebRTC client application is the originating WebRTC client application; and the originating WebRTC client application determining a round-trip time of the plurality of data packets. Web applications usually use WebRTC to provide peer-to-peer multimedia functionality within web browsers so that services such as video, voice and realtime collaborations can be made. Advantageously, most web browsers support WebRTC. However, instead of providing such end-to-end services for a browser user, the WebRTC client application that is downloaded to the browser is used to measure the time taken for different data packets to pass through the internet from the local network and back again. This provides an indication of latency to the WebRTC client application. This information is useful in isolation as it can inform the user of a failures or if a particular application is likely to provide poor service (e.g., video conferencing with high latency). The information can also be used to measure a proportion of the apparent latency caused by the internet or internet service provider, compared with the latency of the local network (e.g., wired Ethernet or Wi-Fi). In any case, action may be taken to improve the latency. This can be manual action such as moving the computer closer to a broadband router. Automatic actions may also be taken triggered by the latency breaching a particular threshold or value. These automatic actions may include changing parameters of the local network (e.g., broadband router or gateway parameters such as Wi-Fi channel, Wi-Fi power, Wi-Fi protocol, etc.). Automatic actions may be taken outside of the local network, such as implementing data packet prioritisation for certain packet types, increasing bandwidth or otherwise altering the broadband service either permanently or temporarily. Optionally, the second WebRTC client application may be external to the local network and further wherein the plurality of data packets are transmitted across the internet. For example, the second WebRTC client application may be located near to or within the control server or at a separate device. The second WebRTC client application may also be located within the local network. This enables more specific latency measurements of different parts or nodes within the local network. Optionally, the originating WebRTC client application may further determine a loss of data packets of the plurality of data packets. This information may be used to improve network conditions to avoid data packet loss and / or reported to the control server for further use and analysis. Preferably, the method may further comprise the step of: the originating WebRTC client application transmitting data indicating the determined round-trip time of the plurality of data packets to the control server. Therefore, the control server can record changes in latency over time, latency for different clients, and / or take action based on the data collected. Optionally, the method may further comprise the steps of: the control server determining a browser type of the browser; determining from the browser type an expected browser latency; and calculating a network latency using the data indicating the determined round-trip time and the expected browser latency. Different browsers contribute different delays and latency to data that they process. To provide realistic and more accurate results, the control server can estimate or lookup (from a data store) an expected amount of latency or delay for each browser type. The latency contribution of each browser type can be subtracted from the round-trip times provided by the WebRTC client applications. The WebRTC client application can send details of the browser that it is used with the round-trip time data (e.g., as a header). Optionally, the method may further comprise the steps of: the control server sending a request to a client within a gateway providing the local network; and in response to the request, the client within the gateway transmitting data indicating local network parameters to the control server. The client within the gateway may be an application that sends data to the control server indicating operating parameters of the gateway. As the gateway provides the local network then these parameters can affect the operation and performance of the local network (e.g., Wi-Fi and / or Ethernet network). These parameters can affect latency and the transit times of the data packets through local network. Preferably, the gateway may be a broadband Wi-Fi router. The broadband router can have an interface (e.g., telephone, cable or optic fibre) providing broadband internet connectivity. Optionally, the local network parameters may include any one or more of: Wi-Fi band of the WebRTC client application; Wi-Fi signal strength; firmware version; browser version; and gateway hardware version. Other parameters may be included. Optionally, the method may further comprise the steps of the control server receiving data indicating the round-trip time of the plurality of data packets from the originating WebRTC client application; and determining an action based on the data indicating the local network parameters and the data indicating the round-trip time of the plurality of data packets. The actions could include manual or automated actions triggered by the data or thresholds being compared with the data values. Optionally, the action may include any one or more of: sending data to the gateway causing the gateway to vary one or more of the local network parameters, sending an instruction to the first WebRTC client application causing a message to be sent to a user of the computer, and / or changing one or more parameters controlling the communications network. Other actions may be taken within and / or outside of the local network. Optionally, the method may further comprise the step of: at a second browser on a second computer within the local network, downloading a third WebRTC client application, the control server transmitting data causing a further communication connection to be set up between the first WebRTC client application and the second WebRTC client application including the third WebRTC client application; transmitting across the internet a further plurality of data packets between the first WebRTC client application, the third WebRTC client application and the second WebRTC client application and back to an originating WebRTC client application, wherein one of the first WebRTC client application and the second WebRTC client application is the originating WebRTC client application, wherein a timestamp is added to the further plurality of data packets as the further data packets pass through the third WebRTC client application between the first WebRTC client application and the second WebRTC client application; and the originating WebRTC client application determining transit times for the further plurality of data packets between the first WebRTC client application and the third WebRTC client application and transit times between the third WebRTC client application and the second WebRTC client application based on the timestamps. Therefore, a separate route for different data packets may be set up between the first and second WebRTC client applications. This separate route may include one or more steps or hops within the local network. Therefore, different parts of the local network can be investigated as locations or computers within the local network may experience or contribute different levels of latency. The data from the first connection (without the third WebRTC client application) may be compared with the data from the second connection (including the third WebRTC client application). The difference in timings, average timings or timings from the same data packets sizes may be compared to determine the latency incurred or caused by the third WebRTC client application to a gateway or broadband router. Optionally, the method may further comprise the steps of: the originating WebRTC client application transmitting data indicating the determined transit times, to the control server; the control server receiving from a gateway providing the local network, data indicating local network parameters relating to the computer of the first WebRTC client application and the second computer; and determining action to reduce transit times based on the received local network parameters and the transit times of the further plurality of data packets. For example, the computers hosting the first and third WebRTC client applications may have different Wi-Fi signals or use different Wi-Fi channels. Therefore, the effect of these differences may be calculated based on the recorded or inferred transit times of the data packets. Preferably, the plurality of data packets may have different packet sizes. Different sized data packets may cause different latency values. Therefore, the effect of latency on packet size can be determined by using different sizes. Statistical analysis may also be made to get averages and trends. Optionally, the different packet sizes may be any of 64B, 128B, 256B, 512B, 1024B, and / or 1444B. Other packets sizes may be used. Optionally, the method may further comprise the step of preventing the browser or a browser tab in the browser from entering a low power or sleep state. In sleep mode, the browser may cause additional delay in processing requests and so add to the time or cause additional latency. Therefore, preventing sleep of a browser or specific tab hosting the WebRTC client application prevents this and improves timing accuracy. According to a second aspect, there is provided a WebRTC client application which, when the WebRTC client application is executed within a browser of a computer within a local network, causes the computer to carry out the steps of: making a connection over the internet with a control server external to the local network; transmitting across the internet a plurality of data packets between the WebRTC client application and the second WebRTC client application and back to an originating WebRTC client application; and determining a round-trip time of the plurality of data packets. Optionally, the WebRTC client application may further cause the computer to carry out the step of: transmitting data indicating the determined round-trip time of the plurality of data packets to the control server. According to a third aspect, there is provided a control server comprising: a processor; and memory storing computer-executable instructions that, when executed by the processor, cause the control server to: receive over the internet a connection from a first WebRTC client application executing in a browser of a computer within a local network; transmit to the first WebRTC client application data causing a communication connection to be set up between the first WebRTC client application and a second WebRTC client application external to the local network; transmit data causing a plurality of data packets to be transmitted between the first WebRTC client application and the second WebRTC client application and back to an originating WebRTC client application, wherein one of the first WebRTC client application and the second WebRTC client application is the originating WebRTC client application; and receive from the originating WebRTC client application data indicating a determined round-trip time for each of the data packets of the plurality of data packets. The control server may be a real or virtual server, for example. According to a fourth aspect, there is provided a system comprising: any the WebRTC client applications described above; and the control server described above. Optionally, the WebRTC client application may be a further WebRTC client application, and the system may further comprise: a third WebRTC client application within a browser of a second computer within the local network, wherein the computer-executable instructions of the control server further cause the computer of the control server to carry out the step of: transmitting data causing: a further communication connection to be set up between the first WebRTC client application and the second WebRTC client application including the third WebRTC client application, and a transmission across the internet of a further plurality of data packets between the first WebRTC client application, the third WebRTC client application and the second WebRTC client application and back to an originating WebRTC client application, wherein one of the first WebRTC client application and the second WebRTC client application is the originating WebRTC client application, wherein the originating WebRTC client application determines transit times for the further plurality of data packets between the first WebRTC client application and the third WebRTC client application and transit times between the third WebRTC client application and the second WebRTC client application. Additional WebRTC client applications may be used within the same local network in a similar way so that the latency of further parts of the local network can be determined. Optionally, the third WebRTC client application may cause the second computer to carry out the step of a adding a timestamp to the further plurality of data packets as the further data packets pass through the third WebRTC client application between the first WebRTC client application and the second WebRTC client application. Therefore, the originating WebRTC client application may determine the data packet transit times based on the timestamps and / or timing information determined at initial transmission from the originating WebRTC client application. Preferably, the system may further comprise a gateway providing the local network, wherein the gateway has a client having computer-executable instructions that, when executed by the gateway, cause the gateway to transmit data indicating local network parameters to the control server in response to a request from the control server. The gateway can be an access point, router, broadband router, or Wi-Fi broadband router, for example. 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 system providing internet service to a local network; FIG. 2 shows a flowchart of a method for measuring latency in the internet service provided to the local network of Figure 1; FIG. 3 shows a schematic diagram of a computer system used to implement the method of Figure 2; FIG. 4 shows example results of latency measured providing internet services to the local network of Figure 1; FIG. 5 shows a sequence diagram of an example implementation of the method of Figure 2; FIG. 6 shows a sequence diagram of a further example implementation of the method of Figure 2; and FIG. 7 shows example graphical results of the method of Figure 2. 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 20, such as a home or office environment. One or more client devices 90, 95 such as laptops, mobile devices, Internet of Things (loT) devices, etc., are served by a broadband router 80. This may be either using a wired connection 70 (e.g., Ethernet) or Wi-Fi 60, for example. Each client device 90, 95 may have one or more applications that require an internet connection. Each application may have its own broadband quality requirement such as latency, reliability, jitter, and bandwidth. The broadband router 80 has an external access connection and interface to an access node using any one or more of 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 through an edge router, or broadband network gateway (BNG), for example. The ISP core may interface with the wider internet 30 through a transmit router or by other means. One or more data service providers or application servers may have their own connections to the internet 30. Therefore, an internet connection 50 may be defined as from the client device 90, 95 or broadband router 80 through each section of the broadband connection across the various nodes to an application server 40. When particular latency requirements for any of the applications are not met then users of the client device 90, 95 may experience adverse application performance. Latency and loss are critical to end user experience. Every Wi-Fi endpoint gets different performance. Ideally, a dedicated test client may be installed on all devices in the home, but this is unfeasible. Almost every web browser supports WebRTC. WebRTC is a standard for peer-to-peer real time communications supporting multiple useful capabilities such as NAT traversal. It has been realised that WebRTC can be repurposed to explicitly evaluate latency and loss between any web browser. This requires end users to access a website (e.g., via a web server) which hosts a latency analysis service. This downloads a specific WebRTC client application on to the web browser on the user’s machine. This has an added benefit that latency is tested by a component used by the services themselves, improving measurement accuracy. This is because many data and interactive services already use WebRTC and so the actual performance seen by applications can be measured. The described methods and systems make use of WebRTC to evaluate latency and loss performance to (and between) end devices in the local network such as a home or office. WebRTC data channels may be used in unreliable and unordered modes so that true loss and latency may be measured without retransmissions or reordering. Other modes may be used. Dummy media tracks along with the associated real-time transport control protocol (RTCP) statistics may be used as the transmitted and tested data packets. The peer-to-peer and NAT traversal nature capabilities of WebRTC may be used to create latency and loss test paths between devices that cannot normally communicate directly. Routing test payloads across multiple hops of WebRTC peer connections accurately measures latency along a path that cannot be easily measured from a central point. A correlation may be made between the WebRTC latency or data packet transit times of endpoints (devices) and data connection details (e.g., operating parameters) of a gateway servicing for the same endpoint. These operating parameters may include Wi-Fi band and signal strength. Therefore, it can be measured and detected if these operating parameters are sub-optimal and require changes to improve the performance of the service provided to each endpoint. The effect of parameter changes may also be tested using ongoing WebRTC latency measurements. The WebRTC code (client) runs in a browser. Browsers generally slow down the internal timers for background tabs. Data packets may be generated at a central or control server (server external to the local network), which may instruct the WebRTC client application to generate particular data packets, which are communicated between WebRTC client applications. This ensures accurate results, as browsers will generally run code immediately on reception of a WebRTC data packet. Furthermore, browser senders that have gone to sleep may be identified by the fact that they generate reduced numbers of packets per second (PPS) data. Browsers may also introduce variation in delay due to batching capabilities of SCTP (the underlying transport for the data channel) and underlying browser functions such as garbage collection. The performance of the different browsers may be evaluated in advance and stored (e.g., in a database at the control server) such that latency variation introduced by the browser can be statistically removed from the results. Browser type information (i.e., the host of the WebRTC client application) can be sent to the control server, which can adjust the measurement results based on browser type. As the latency caused by the browser will be present in real customer or user applications, the effect of application performance for different browsers can also be evaluated and recorded. As browsers do not have access to the accurate clocks and timing can only be accessed once the packet is provided from the browser to sandboxed code, wherever possible, the data packets may be generated by the WebRTC client application (endpoint), which can provide more accurate packet timestamping. The browser code may be limited to only reflecting or onward routing the test payload (data packets). Figure 2 shows a flowchart of the method 100 used to determine latency. This figure illustrates the method 100 at a high level. This method uses a first WebRTC client application and a second WebRTC client application acting as endpoints. The WebRTC client applications may be located within the local (e.g., home or office) network or external to the local network. At step 110, a first WebRTC client application is downloaded by visiting a website that hosts the WebRTC client application code using a browser on a first computer or device 90 that is within the local network 20 served by the gateway 80. At step 120, a communication connection is made between the first WebRTC client application and a control server located outside of the local network 20 (i.e., across the internet). This connection may be prompted by the code executing within the first WebRTC client application 90 or by the control server. At step 130, the control server instructs the first WebRTC client application 90 to set up a data connection with a second WebRTC client application. This second WebRTC client application may be within the local network 20 or external to the local network 20. This data connection takes the form of a usual WebRTC data connection (i.e., one used to provide media services between WebRTC client applications). At step 140, one of the WebRTC client applications initiates the transmission of data packets to the other WebRTC client application, which acts as a reflector. The reflector WebRTC client application may optionally add a timestamp to data packets as they are retransmitted back to the originating WebRTC client application 90 (e.g., as part of its header). Therefore, at step 150 the originator WebRTC client application determines a round-trip time (and so latency) of the data connection between the first and second WebRTC client applications. The originator WebRTC client application can record when each data packet is sent and when it is received back (e.g., using a clock, timestamp and data packet identifier sent with the data packet). The originator WebRTC client application may also determine any data loss. If time stamps have been added to the data packets then the time take for both outbound and inbound journeys of the data packets may be calculated. The originator WebRTC client application can record the time at which each data packet is transmitted and each data packet may have an identifier stored together with this time. Different sized and / or types of data packets may be transmitted between WebRTC client applications. Therefore, data or statistics may be determined regarding latency for different sizes and / or data packet types. Any or all of these data determined following the data packet transmission tests may be sent to the control server (step 160) for further analysis, storage, and / or to use to carry out further actions. The method 100 described with reference to Figure 2 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 analogue 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. 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 or local network connections 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) may be generated for the overall end-to-end network connection and / or for different sections of the broadband connection (if timestamps are added for each hop to a different WebRTC client application). This may require a minimum of data packets to determine (e.g., 30, 50, 100, etc.). 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. Figure 4 shows 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 or percentiles (Ph - home, Pi - internet) can be considered. Figure 5 shows a sequence diagram of an example implementation of method 100 where the first WebRTC client application 90 is located within browser 410 and the second WebRTC client application is located within a central client 420 used for one or more local networks 20 and located external to the local network 20 (e.g., at or close to the control server 440). The browser 410 may execute within a device or computer (e.g., device 90 of Figure 1) located within the local network 20. The central client 420 may also operate or execute within a computer or server but located outside of the local network 20. A web server 450 provides the WebRTC client application code downloaded to each browser. A results database 430 can be used to store or aggregate any data received from one or more WebRTC client applications as and when latency measurement tests are conducted. The results database 430 may also store other data related to the tests, such as browser type, gateway parameters, IP addresses of the local network, etc. As described with reference to Figure 5, the browser 410 gets the WebRTC client application code from the web server 450. In this example implementation, the WebRTC client application is already installed and operating with the central client 420 (which may be another browser instance or similar host). Once the WebRTC client application has been installed and is operating on the browser 410, a control channel is set up between the WebRTC client application and the control server 440. The control server 440 adds an identifier (e.g., unique identifier or IP address) of the newly installed WebRTC client application and any information about the local network serving the browser 410 to the results database 430 or another data store. The control server 440 manages data connections between different WebRTC client applications. In this example, the only WebRTC client applications are those installed on the browser 410 and on the central client 420. In this example, the WebRTC client application operating within the central client 420 acts as the originator of the data packets and also generates the data packets. This is instructed by the control server 440 sending an instruction or message to the WebRTC client application of the central client 420. A message or instruction is also sent from the control server 440 to the WebRTC client application of the browser 410 so that this WebRTC client application acts as the reflector or receiver and re-transmitter of incoming data packets. The control server 440 also sets up or instructs the setting up of a WebRTC connection between the two WebRTC client applications taking the form of a peer connection. In this example, an unordered and unreliable data channel is created between the WebRTC client application of the browser 410 and the WebRTC client application of the central client 420. A test is initiated using the WebRTC peer connection with data packets (test payload) transmitted and reflected back to the originating WebRTC client application in the central client 420. The test may be repeated for a period of time (determined by the control server 440) or until a certain number of data packets have been sent (determined by the control server 440). Test results may be collated and analysed by the originating WebRTC client application with summarised results optionally sent to the browser 410 for display to a user on a display screen. Test results (e.g., timing, latency, packet loss details, etc.) may be sent to the results database 430 directly or via the control server 440. The data may be sent as it is generated during the test or at the end of a particular test. The duration of the test may be managed by the WebRTC client application based on instructions or data sent by the control server 440. The results database 430 may store results from one or more tests for the same local network 20 or for a plurality of local networks. These data may be used to determine the performance of different types of local networks or different settings and parameters for these local networks. It should be noted that a similar operation may be conducted with the central client 420 being replaced by a different browser operating within the same local network 20 as browser 410. However, the control server 440 can still manage the creation of WebRTC peer connections between the two WebRTC client applications. Figure 6 shows a sequence diagram of a further example implementation. Similar steps are executed to those of Figure 5 and similar components have the same reference numerals. However, a further WebRTC client application is used within the method described with reference to Figure 6. This further WebRTC client application is downloaded from the web server 450 by a further browser 510 operating within a different device (e.g., computer) within the local network (e.g., device 95 shown in Figure 1). The method illustrated in Figure 6 starts after the WebRTC client applications already downloaded from the web server 450 and installed on the computers 90, 95 within the local network 20. As with the method described with reference to Figure 5, the control server 440 manages the functions of each WebRTC client application and sets up the communications channels and connections between the different WebRTC client applications. The control server 440 also defines the routing of the data packets between the WebRTC client applications. In this example implementation the WebRTC client application within the central client 420 also acts as the originator of the data packets (although this can also be any of the other two WebRTC client applications). The data packets are still routed to the WebRTC client application of browser 410 (client 1) but this time they are transmitted or reflected back to the WebRTC client application of the central client 420 via the WebRTC client application of browser 510 (client 2). Therefore, the time taken to pass directly from the central client 420 to browser 410 (clientl) can be compared with the time taken to pass through browser 510 (client 2) with all returning data packets passing through the WebRTC client application of browser 510. Data loss information for both routes may also be measured and investigated. Alternatively, the outgoing data packets can pass through the WebRTC client application of browser 510 and be reflected directly back to the originating WebRTC client application. The WebRTC client application of browser 510 (client 2) may also add a timestamp to the data packets as they pass through so further data can be acquired. The results data may be displayed and stored in a similar way that described with reference to Figure 5. During or following test measurements, results may be displayed in different ways. Figure 7 shows a graphical display of timing or latency data (ms) between different nodes hosting separate WebRTC client applications (named uniquely). The WebRTC client applications within the same local network are surrounded by a circle in this figure. In these example results WebRTC client application “lucy” is the central client 420. As can be seen by the results, different routes and latency data can be acquired by the control server 440. The graph at the bottom of figure 7 shows the CDFs of the latency results. 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, the WebRTC code may be implemented in JavaScript. Information describing different parameters of the local network may be sent back with the timing or latency results to the control server and / or results database. Different numbers of WebRTC client applications may be included in the path of the data packets. The hops may be sequential, parallel or pass back and forth, for example. The computer executing the WebRTC client application may be connected by Ethernet or Wi-Fi. Endpoints (WebRTC client applications) operating in the same local network may be identified by their public or local IP addresses. An optional WebRTC client application may also operate on the gateway and provide accurate (or a single synchronised) time or timestamps to the other WebRTC client applications in the local network so that the measurements are more accurate. The WebRTC client application external to the local network may also provide a central or synchronised time or timestamp. Results presented to the user within the local network may also include estimated latency caused by the browser based on browser type or version. A WebRTC client or WebRTC client application may optionally run as a native application and not within a browser. This can provide a more accurate endpoint on a home router or on the internet. In this case, it is not necessary to download the WebRTC client application onto one or more of the browsers for the method or system to operate. Instead, the native application can be installed on a computer or other device in advance of the test. 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 testing network latency, the method comprising the steps of:a browser of a computer within a local network, downloading a first WebRTC client application;the first WebRTC client application making a connection over the internet with a control server external to the local network;the control server transmitting data causing a communication connection to be set up between the first WebRTC client application and a second WebRTC client application;transmitting a plurality of data packets between the first WebRTC client application and the second WebRTC client application and back to an originating WebRTC client application, wherein one of the first WebRTC client application and the second WebRTC client application is the originating WebRTC client application; andthe originating WebRTC client application determining a round-trip time of the plurality of data packets.

2. The method of claim 1, wherein the second WebRTC client application is external to the local network and further wherein the plurality of data packets are transmitted across the internet.

3. The method of claim 1 or claim 2, wherein the originating WebRTC client application further determines a loss of data packets of the plurality of data packets.

4. The method according to any previous claim further comprising the step of:the originating WebRTC client application transmitting data indicating the determined round-trip time of the plurality of data packets to the control server.

5. The method of claim 4 further comprising the steps of:the control server determining a browser type of the browser;determining from the browser type an expected browser latency; andcalculating a network latency using the data indicating the determined round-trip time and the expected browser latency.

6. The method of according to any previous further comprising the steps of:the control server sending a request to a client within a gateway providing the local network; andin response to the request, the client within the gateway transmitting data indicating local network parameters to the control server.

7. The method of claim 6, wherein the gateway is a broadband Wi-Fi router.

8. The method of claim 6 or claim 7, wherein local network parameters include anyone or more of: Wi-Fi band of the WebRTC client application; Wi-Fi signal strength; firmware version; browser version; and gateway hardware version.

9. The method according to any of claims 6 to 8 further comprising the steps of the control server receiving data indicating the round-trip time of the plurality of data packets from the originating WebRTC client application; anddetermining an action based on the data indicating the local network parameters and the data indicating the round-trip time of the plurality of data packets.

10. The method of claim 9, wherein the action includes any one or more of:sending data to the gateway causing the gateway to vary one or more of the local network parameters, sending an instruction to the first WebRTC client application causing a message to be sent to a user of the computer, and / or changing one or more parameters controlling the communications network.

11. The method according to any previous claim further comprising the step of:at a second browser on a second computer within the local network, downloading a third WebRTC client application,the control server transmitting data causing a further communication connection to be set up between the first WebRTC client application and the second WebRTC client application including the third WebRTC client application;transmitting across the internet a further plurality of data packets between the first WebRTC client application, the third WebRTC client application and the second WebRTC client application and back to an originating WebRTC client application, wherein one of the first WebRTC client application and the second WebRTC client application is the originating WebRTC client application, wherein a timestamp is added to the further plurality of datapackets as the further data packets pass through the third WebRTC client application between the first WebRTC client application and the second WebRTC client application; andthe originating WebRTC client application determining transit times for the further plurality of data packets between the first WebRTC client application and the third WebRTC client application and transit times between the third WebRTC client application and the second WebRTC client application based on the timestamps.

12. The method of claim 11, further comprising the steps of:the originating WebRTC client application transmitting data indicating the determined transit times, to the control server;the control server receiving from a gateway providing the local network, data indicating local network parameters relating to the computer of the first WebRTC client application and the second computer; anddetermining action to reduce transit times based on the received local network parameters and the transit times of the further plurality of data packets.

13. The method according to any previous claim where the plurality of data packets have different packet sizes.

14. The method of claim 13, wherein the different packet sizes are any of 64B, 128B, 256B, 512B, 1024B, and / or 1444B.

15. The method according to any previous claim further comprising the step or preventing the browser or a browser tab in the browser from entering a low power or sleep state.

16. A WebRTC client application which, when the WebRTC client application is executed within a browser of a computer within a local network, causes the computer to carry out the steps of:making a connection over the internet with a control server external to the local network;transmitting across the internet a plurality of data packets between the WebRTC client application and the second WebRTC client application and back to an originating WebRTC client application; anddetermining a round-trip time of the plurality of data packets.

17. The WebRTC client application of claim 16, wherein the WebRTC client application further causes the computer to carry out the step of:transmitting data indicating the determined round-trip time of the plurality of data packets to the control server.

18. A control server comprising:a processor; andmemory storing computer-executable instructions that, when executed by the processor, cause the control server to:receive over the internet a connection from a first WebRTC client application executing in a browser of a computer within a local network;transmit to the first WebRTC client application data causing a communication connection to be set up between the first WebRTC client application and a second WebRTC client application external to the local network;transmit data causing a plurality of data packets to be transmitted between the first WebRTC client application and the second WebRTC client application and back to an originating WebRTC client application, wherein one of the first WebRTC client application and the second WebRTC client application is the originating WebRTC client application; andreceive from the originating WebRTC client application data indicating a determined round-trip time for each of the data packets of the plurality of data packets.

19. A system comprising:the WebRTC client application of claim 16 or claim 17; andthe control server of claim 18.

20. The system of claim 19, wherein the WebRTC client application is a further WebRTC client application, the system further comprising:a third WebRTC client application within a browser of a second computer within the local network, wherein the computer-executable instructions of the control server further cause the computer of the control server to carry out the step of:transmitting data causing:a further communication connection to be set up between the first WebRTC client application and the second WebRTC client application including the third WebRTC client application, anda transmission across the internet of a further plurality of data packets between the first WebRTC client application, the third WebRTC client application and the second WebRTC client application and back to an originating WebRTC client application, wherein one of the first WebRTC client application and the second WebRTC client application is the originating WebRTC client application, wherein the originating WebRTC client application determines transit times for the further plurality of data packets between the first WebRTC client application and the third WebRTC client application and transit times between the third WebRTC client application and the second WebRTC client application.

21. The system of claim 20, wherein the third WebRTC client application further causes the second computer to carry out the step of a adding a timestamp to the further plurality of data packets as the further data packets pass through the third WebRTC client application between the first WebRTC client application and the second WebRTC client application, and wherein the originating WebRTC client application determines transit times for the further plurality of data packets based the timestamp.

22. The system according to any of claims 19 to 21 further comprising a gateway providing the local network, wherein the gateway has a client having computer-executable instructions that, when executed by the gateway, cause the gateway to transmit data indicating local network parameters to the control server in response to a request from the control server.02 05 25AMENDMENTS TO THE CLAIMS HAVE BEEN FILED AS FOLLOWS:CLAIMS:

1. A method for testing network latency, the method comprising the steps of:a browser of a computer within a local network, downloading a first WebRTC client5 application;the first WebRTC client application making a connection over the internet with a control server external to the local network;the control server transmitting data causing a communication connection to be set up between the first WebRTC client application and a second WebRTC client application;10 transmitting a plurality of data packets between the first WebRTC client applicationand the second WebRTC client application and back to an originating WebRTC client application, wherein one of the first WebRTC client application and the second WebRTC client application is the originating WebRTC client application; andthe originating WebRTC client application determining a round-trip time of the15 plurality of data packets.

2. The method of claim 1, wherein the second WebRTC client application is external to the local network and further wherein the plurality of data packets are transmitted across the internet.

203. The method of claim 1 or claim 2, wherein the originating WebRTC client application further determines a loss of data packets of the plurality of data packets.

4. The method according to any previous claim further comprising the step of:25 the originating WebRTC client application transmitting data indicating thedetermined round-trip time of the plurality of data packets to the control server.

5. The method of claim 4 further comprising the steps of:the control server determining a browser type of the browser;30 determining from the browser type an expected browser latency; andcalculating a network latency using the data indicating the determined round-trip time and the expected browser latency.3502 05 256. The method of according to any previous further comprising the steps of: the control server sending a request to a client within a gateway providing the local network; andin response to the request, the client within the gateway transmitting data indicating 5 local network parameters to the control server.

7. The method of claim 6, wherein the gateway is a broadband Wi-Fi router.

8. The method of claim 6 or claim 7, wherein local network parameters include any10 one or more of: Wi-Fi band of the WebRTC client application; Wi-Fi signal strength; firmware version; browser version; and gateway hardware version.

9. The method according to any of claims 6 to 8 further comprising the steps of the control server receiving data indicating the round-trip time of the plurality of data packets15 from the originating WebRTC client application; and determining an action based on the data indicating the local network parameters and the data indicating the round-trip time of the plurality of data packets.

10. The method of claim 9, wherein the action includes any one or more of:20 sending data to the gateway causing the gateway to vary one or more of the localnetwork parameters, sending an instruction to the first WebRTC client application causing a message to be sent to a user of the computer, and / or changing one or more parameters controlling the communications network.25 11. The method according to any previous claim further comprising the step of:at a second browser on a second computer within the local network, downloading a third WebRTC client application,the control server transmitting data causing a further communication connection to be set up between the first WebRTC client application and the second WebRTC client30 application including the third WebRTC client application;transmitting across the internet a further plurality of data packets between the first WebRTC client application, the third WebRTC client application and the second WebRTC client application and back to an originating WebRTC client application, wherein one of the first WebRTC client application and the second WebRTC client application is the originating35 WebRTC client application, wherein a timestamp is added to the further plurality of data02 05 25packets as the further data packets pass through the third WebRTC client application between the first WebRTC client application and the second WebRTC client application; andthe originating WebRTC client application determining transit times for the further5 plurality of data packets between the first WebRTC client application and the third WebRTC client application and transit times between the third WebRTC client application and the second WebRTC client application based on the timestamps.

12. The method of claim 11, further comprising the steps of:10 the originating WebRTC client application transmitting data indicating thedetermined transit times, to the control server;the control server receiving from a gateway providing the local network, data indicating local network parameters relating to the computer of the first WebRTC client application and the second computer; and15 determining action to reduce transit times based on the received local networkparameters and the transit times of the further plurality of data packets.

13. The method according to any previous claim where the plurality of data packets have different packet sizes.2014. The method of claim 13, wherein the different packet sizes are any of 64B, 128B, 256B, 512B, 1024B, and / or 1444B.

15. The method according to any previous claim further comprising the step or25 preventing the browser or a browser tab in the browser from entering a low power or sleep state.

16. A WebRTC client application which, when the WebRTC client application is executed within a browser of a computer within a local network, causes the computer to30 carry out the steps of:making a connection over the internet with a control server external to the local network;receiving from the control server data causing a communication connection to be set up between the first WebRTC client application and a second WebRTC client35 application;02 05 25transmitting across the internet a plurality of data packets between the WebRTC client application and the second WebRTC client application and back to an originating WebRTC client application; anddetermining a round-trip time of the plurality of data packets.

517. The WebRTC client application of claim 16, wherein the WebRTC client application further causes the computer to carry out the step of:transmitting data indicating the determined round-trip time of the plurality of data packets to the control server.1018. A control server comprising: a processor; and memory storing computer-executable instructions that, when executed by the processor, cause the control server to:15 receive over the internet a connection from a first WebRTC client applicationexecuting in a browser of a computer within a local network;transmit to the first WebRTC client application data causing a communication connection to be set up between the first WebRTC client application and a second WebRTC client application external to the local network;20 transmit data causing a plurality of data packets to be transmitted between the firstWebRTC client application and the second WebRTC client application and back to an originating WebRTC client application, wherein one of the first WebRTC client application and the second WebRTC client application is the originating WebRTC client application; and25 receive from the originating WebRTC client application data indicating a determinedround-trip time for each of the data packets of the plurality of data packets.

19. A system comprising:the WebRTC client application of claim 16 or claim 17; and30 the control server of claim 18.

20. The system of claim 19, wherein the WebRTC client application is a further WebRTC client application, the system further comprising:02 05 25a third WebRTC client application within a browser of a second computer within the local network, wherein the computer-executable instructions of the control server further cause the computer of the control server to carry out the step of:transmitting data causing:5 a further communication connection to be set up between the first WebRTCclient application and the second WebRTC client application including the third WebRTC client application, anda transmission across the internet of a further plurality of data packets between the first WebRTC client application, the third WebRTC client application10 and the second WebRTC client application and back to an originating WebRTCclient application, wherein one of the first WebRTC client application and the second WebRTC client application is the originating WebRTC client application, wherein the originating WebRTC client application determines transit times for the further plurality of data packets between the first WebRTC client application and the third15 WebRTC client application and transit times between the third WebRTC client application and the second WebRTC client application.

21. The system of claim 20, wherein the third WebRTC client application further causes the second computer to carry out the step of a adding a timestamp to the further plurality of20 data packets as the further data packets pass through the third WebRTC client application between the first WebRTC client application and the second WebRTC client application, and wherein the originating WebRTC client application determines transit times for the further plurality of data packets based the timestamp.25 22. The system according to any of claims 19 to 21 further comprising a gatewayproviding the local network, wherein the gateway has a client having computer-executable instructions that, when executed by the gateway, cause the gateway to transmit data indicating local network parameters to the control server in response to a request from the control server.30

Images