KR20220008834A - Active test systems for mobile IOT networks and test methods using such test systems - Google Patents

Abstract

Presented herein is an active test system 1 for a mobile IoT network 2 providing connectivity and services to mobile IoT (MIOT) devices in low power wide area (LPWA) technology. The test system has at least one test probe 3 connected to the MIoT network 2 via an LTE-Uu interface 5 and/or at least one test probe connected to the MIoT network via an S1 interface. The central test unit 5a is connected 8 to the at least one test probe 3 via a wireless backhaul network or a static IP network 7 . A SIM multiplexer 12 is provided to transmit SIM data to at least one test probe 3 in the test field. A test system with enhanced features ensures a mobile IoT experience.

Description

Active test systems for mobile IOT networks and test methods using such test systems

This application claims priority to German patent application DE 10 2019 207 051.5 and US patent application US 16/412 459, the contents of which are incorporated herein by reference.

The present invention relates to an active test system for a mobile IoT network. The present invention also relates to a test method using such a test system.

Test systems for mobile networks are known, for example, from US 10,097,981 B1, US 7,831,249 B2 and WO 2004/049746 A1.

US 9,768,893 B1 discloses a method and device for separating radio segments within a mobile communication network. DE 10 2005 027 027 B4 discloses a method and a test system for authenticating a mobile test device in a mobile communication network.

It is an object of the present invention to improve the capability of such a test system for testing mobile networks.

This object is achieved by an active test system comprising the features of claim 1 .

The test system according to the present invention may perform a test of a mobile IoT (Internet of Things) network that provides connectivity and rendering services to an MIoT (mobile IoT) device. These tests are active tests, ie they require at least one component to actively initiate each test method. For example, a central test unit or part thereof may be a component for actively initiating a test method.

The mobile IoT network to be tested is considered a subtype of installed 4G network enhanced with Low Power Wide Area (LPWA) technology for device power saving, improved coverage and small amount of data transmission, and tolerable latency.

The installed LPWA technology may be LTE-M and/or NB-IoT. LPWA mobile devices connected to an MIoT network are smart meters, home automation devices, building automation devices, part of a smart grid, part of an industrial production line or pipeline management, part of an automobile, transport device or part of logistics, drones, home security devices. Part of a patient monitoring device, eg part of an agricultural appliance that performs irrigation or shadowing, part of a street lighting device, part of a tracking device, part of an industrial asset management device, part of a retail/store device, or as part of an example It may be part of a wrist watch or part of a wearable device such as part of a smartphone. In addition, voice service over LTE-M can also be tested.

The mobile IoT network may be connected to the MIoT application platform and/or the IoT application platform through the application server.

With this test system, an MIoT network connectivity test and/or an MIoT application platform test can be performed. The test system may adapt and install at least one test probe according to the IoT network architecture and scalability. Test probes may be placed in different locations (test fields) within a single IoT network or across multiple interconnected networks. In particular, the data communication implemented by the SIM of the mobile IoT device may be simulated and/or emulated via the LTE-Uu air interface or the S1 core network interface.

The SIM multiplexer may transmit SIM data virtually and/or securely to the at least one test probe.

A SIM multiplexer may be implemented as support for carrying multiple SIMs, eg up to three or more SIMs.

The test system may be configured to execute a mobile IoT test procedure that deploys an end-to-end active test methodology between at least one test probe and the MIoT network under test. The test system may be configured to control the test probe(s) via a specific active test platform comprising a central test device. In addition, the test system can automatically execute IoT test procedures, collect test results, and generate test reports and dashboards through a central test unit.

Within the test system, test methods and test sequences are deployed to test MIoT applications and/or services running beyond the IoT connectivity provided by the MIoT network under test.

“End-to-end” testing ensures that the connectivity between the MIoT device and the MIoT application server and the services provided to the MIoT device by the MIoT application are to/from the MIoT device, in particular the MIoT device. means tested by using data transfer to/from at least one test probe that represents and simulates.

In particular, it is tested whether the application's service data flow behaves as expected from start to finish. In particular, every step of the application and/or service is tested.

Download and upload data rates and/or download/upload bandwidths may be tested.

The data transmission test may be performed with different sizes of transmitted/received data, in particular different numbers of data packets and/or different data volumes.

Data transmission quality and data transmission integrity may also be tested.

In addition, the test system may be designed to test the functionality of the MIoT network in the deployment of extended discontinuous reception (eDRX) and/or power saving mode (PSM) for MIoT applications. In addition, the test system may be designed to test the IoT application server on the IoT application platform.

The test system may be designed to configure and initiate at least one test probe to trigger and initiate at least one of a group of power saving mode (PSM) or extended discontinuous reception (eDRX) mode in the serving MIoT network under test. The test system may be specifically designed for negotiation of power saving mode and eDRX mode with configuration and initiation of test probes for Evolved Packet System (EPS) connections in the serving MIoT network under test.

The test system was tested by using a variety of protocols including, but not limited to, oneM2M, Hypercat, CoAP (Restricted Application Protocol), Message Queued Telemetry Transport (MQTT/MQTT-SN), Real-Time Streaming Protocol (RTSP), or HTTP It may be designed to configure and initiate at least one test probe to access and query the IoT application server via a device specific interface such as JavaScript Object Notation (JSON) and/or Extensible Mark-up Language (XML) via.

A reference to the oneM2M protocol can be accessed via www.onem2m.org. Information on the protocol Hypercat can be found in John Davies' Hypercat: resource discovery on the internet of things (January 12, 2016): IEEE Internet, published March 2, 2017 and available via http://iot.ieee.org of Things. Information regarding protocol CoAP can be found through standard RFC7252 available at https://tools.ietf.org/html/rfc7252. Information about JSON can be found through the standards RFC8259 and ECMA-404. Information on RTSP can be found through standard RFC2326.

The signal and data exchange according to claim 2 enables testing of the most common types of signal messages and data using a test system.

A configuration according to claim 3 has proven essential to the most general test requirements.

This is especially true of the test system according to claim 4 .

The message structure according to claim 5 is suitable for IoT application platform testing. Alternatively or additionally, applicable protocols and/or interfaces for communicating with such test systems are oneM2M, Hypercat, CoAP, RTSP, JSON, XML.

The test method according to claim 6 has the advantages described above in connection with the test system according to the invention. This test method is specifically an end-to-end test method. This test method includes in particular testing IoT application platforms, in particular servers of such platforms.

With the method according to claim 7, by simulating/emulating each mobile IoT device using a test probe in the IoT network, the IoT service availability of the network can be tested. The test steps may be repeated periodically during the test method. The recorded test results can be aggregated and further statistically evaluated.

With the test method of claim 8, a mobile IoT connection may be performed. Here again, the iteration step may be repeated periodically, and the test results may be aggregated for further statistical evaluation.

Through this ping test, it is possible to evaluate the IoT network accessibility to the ping test probe and/or the round trip time of the ping/echo.

With the test method according to claim 9, the power saving function of each mobile IoT device may be tested. Here again, the iteration step may be repeated periodically, and the test results may be aggregated for further statistical evaluation.

As part of this power saving test method, the MT data transmission combined with the power saving function to be managed by the IoT serving network under test sends downlink data towards the test probe while the T3324 active timer is running, and the test probe is fully downlinked. It can be tested by confirming that the data packet has been received, monitoring and logging all test events, and repeating the above test according to a given schedule. Here again, the iteration step may be repeated periodically, and the test results may be aggregated for further statistical evaluation.

In addition, in this power saving test, the MT SMS combined with the power saving function to be managed by the IoT serving network under test sends an SMS to the test probe while the T3324 active timer is running, the test probe confirms that the SMS has been received, All test events are monitored and logged, and can be tested by repeating the tests described above according to a given test schedule. Here again, the iteration step may be repeated periodically, and the test results may be aggregated for further statistical evaluation.

In the test method according to claim 10, the eDRX functionality can be tested and consequently the ability of the additional power saving function can be evaluated. Here again, the iteration step may be repeated periodically, and the test results may be aggregated for further statistical evaluation.

In this eDRX test method, the MT data transmission combined with the eDRx function to be managed by the IoT serving network under test sends downlink data towards the test probe within the paging time window (PTW), and the test probe sends the complete downlink data It can be tested by confirming that packets have been received, monitoring and logging all test events, and repeating the above-mentioned tests according to a given test schedule. Here again, the iteration step may be repeated periodically, and the test results may be aggregated for further statistical evaluation.

In addition, in this eDRX test method, the MT SMS combined with the eDRX function to be managed by the IoT serving network under test sends an SMS to the test probe within the paging time window (PTW), and confirms that the test probe has received the SMS , monitoring and recording all test events, and repeating the tests described above according to a given test schedule. Here again, the iteration step may be repeated periodically, and the test results may be aggregated for further statistical evaluation.

With the test method according to claim 11 , the connection maintenance power and the request to disconnect the network initiated without a request can be tested.

With the test method of claim 12, mobile origination (MO) data transmission may be tested.

With the test method of claim 13, MT (Mobile Termination) data transmission may be tested.

With the test method according to claim 14, MO SMS transmission can be tested.

With the test method according to claim 15, MT SMS delivery can be tested.

Data and SMS data delivery can be tested during and after sleep mode.

Exemplary embodiments of the present invention are further described with reference to the accompanying drawings. From the drawing:
1 shows the main components of an active test system for a mobile Internet of Things (IoT) network comprising at least one test probe connected to an IoT network via a wireless interface;
Fig. 2 is a view similar to Fig. 1, showing another embodiment of a test system for a mobile IoT network comprising a test probe connected to the IoT network via an S1 interface;
Fig. 3 is a view similar to Fig. 1, showing an embodiment of a test system configured to test an IoT service network on a test connection path across a roaming interface; and
4 is a diagram illustrating the main components of an embodiment of a test system comprising two test probes configured to communicate with an IoT application platform of an IoT service via MQTT/MQTT-SN messages;

FIG. 1 shows the main components of an active test system 1 for a mobile Internet of Things (IoT) network 2 represented by the various communication lines shown in FIG. 1 . The communication line may be a pure signal path, a signal path embedded with IoT data, or an IoT data transmission path. The Mobile IoT (MIOT) network 2 provides connectivity and services to mobile IoT devices in Low Power Wide Area (LPWA) technology. The LPWA frequency bandwidth used is regularly on the licensed spectrum. The installed LPWA technology may be LTE-M and/or NB-IoT.

Throughout this specification, reference is made to the following references, particularly with regard to standardized specifications of IoT networks:

- GSM Association; Official document CLP.28-NB-IoT Deployment Guide to Basic Feature set Requirements, Version 1.0, August 2, 2017 (White Paper of GSMA);

- Technical Specification 3GPP TS 23.682, V.15.8.0 published on March 15, 2019.

The mobile IoT network to be tested through the test system 1 can also be installed with EC-GSM-IoT (Extended Coverage GSM IoT). As an example of short-range wireless communication, Bluetooth mesh networking (Bluetooth Mesh Networking), Li-Fi (Light-Fidelity), NFC (Near-Field Communication), Wi-Fi, ZigBee or Z-Wave, as an example of medium-range wireless, LTE-Advanced Or LTE-Standard, Lo-RaWan, Sigfox, or Weightless as an example of long-distance wireless communication, or Very Small Aperture Terminal (VSAT), and Ethernet or Power-Line communication as an example of wired communication, for machine-to-machine communication. Other communication technologies may also be used for additional network access.

The test system 1 of FIG. 1 comprises one or more test probes 3 which are components of a local unit 4 of the test system 1 . 1 shows several examples of such a local unit 4 . The local unit 4 may contain from 1 to 4 or even more, for example up to 15 or more test probes 3 . The test probe 3 is connected to the IoT network 2 via a wireless interface 5 . Each interface 5 together with an LTE RAN (Radio Access Network) is schematically shown in FIG. 1 and may be implemented by a plurality of antenna sites.

The central test unit 5a is connected to the test probe 3 via an Internet network 7 , 8 . Such a connection may be, for example, a permanent secure IP connection via a VPN server and LTE/GPRS/EDGE/HSPA modem, or it may be a semi-persistent IP connection established via a VPN server when needed during testing.

In the embodiment of FIG. 1 , the network 7 , which may be a wireless backhaul network or a static IP network, includes the Internet 8 and further includes a component of the Evolved Packet Core (EPC) of the 3GPP LTE communication standard. In general, the components of the network 7 are also components of the IoT network 2 , but this is not required, and some of the components of the network 7 may be independent of the IoT network 2 .

Another part of the test system 1 shown on the left in FIG. 1 is a test client 5b which is also connected to the networks 7 and 8 of the test system 1 .

Figure 1 shows two main test communication paths between a test probe 3 and an application server (AS) 6 serving as an IoT platform. First, the NB-IoT test communication path 9 runs from the attribute local air interface 5 through the MME (Mobile Management Entity), and S-GW (Serving Gateway) and Packet Data Network Gateway (P-GW) and via the network 7 to the AS/IoT platform 6 (so-called direct mode), or via the test path 11 , and via the service Capability Exposure Function (SCEF), Services Capability Server (SCS) and network 7 There are two split alternatives to the AS/IoT platform 6 (the so-called indirect mode).

The additional LTE-M test communication path 10 runs directly from the local air interface 5 to the S-GW, i.e. does not run through the MME, but additionally a Serving Gateway (S-GW) and a Packet Data Network Gateway (P-) GW) and the network 7 through the AS/IoT platform 6 .

All test probes are equipped with a SIM. A SIM multiplexer 12 connected to the Internet 8 virtually dispatches SIM data to individual test probes in a completely secure and reliable manner. A SIM multiplexer as part of the test system 1 is known from DE 10 2005 027 027 B4.

Local unit 4 and local unit 16 are equipped with SIM multiplexer support.

Alternatively, for SIM multiplexer support, the local unit 4 may include support for carrying multiple SIMs, for example up to three SIMs or more.

The local unit 4 is placed in a designated test field and connected to a test system. In practice, a plurality of test probes 3 are arranged in a wide range of locations covering different and in particular large national or international areas. Consequently, the at least one test probe 3 is configured to be deployed in a home IoT network under test for a domestic IoT service test or a visited IoT network under test for an international IoT roaming service test.

The test system 1 is configured to execute a mobile IoT test procedure deploying an end-to-end active test methodology between the at least one test probe 3 and the IoT network 2 under test.

Further, the test system 1 is configured to control the at least one test probe 3 , is configured to automatically run an IoT test procedure, is configured to collect test results, and further includes a test report and/or dashboard is configured to create

The test system 1 is configured to exchange signaling messages and is configured to send IP data and/or non-IP data and/or SMS to/from the IoT network 2 under test.

The test communication path through the internet network 8 between the test probe 3 and the IoT platform 6 is an MQTT/MQTT-SN client where the test probe 3 is an MQTT client and the IoT platform 6 is a server/MQTT broker /Include the server structure. IoT application data stored on the IoT platform can be retrieved, evaluated and verified through the messaging protocol MQTT (Message Queuing Telemetry Transport).

Additional components within the network and/or communication path may serve as Services Capability Server (SCS) and/or Application Server (AS). Regarding the arrangement of this SCS/AS, refer to the technical specification 3GPP TS 23.682, in particular Fig. 4.2-1a.

Further possible interfaces can operate according to the standardized S6a, S8, SGd or T7 roaming interfaces.

Through a test method or test procedure performed by the test system 1 , the availability and quality of the serving IoT network 2 under test can be tested. During the service availability test, in particular the timing of each test event can be monitored and recorded in the test central unit 5a.

The described test method is controlled by the test center unit 5a unless otherwise indicated.

An example of such a test method includes the following steps:

Each test probe 3 is configured through a test client 5b and an Evolved Packet System (EPS) connection is initiated in the serving IoT network 2 under test. After the initiation of EPS connection and completion of the connection procedure, the message received from the IoT network under test by the test probe 3 is confirmed by the test center unit 5a.

All test events during the configuration, initiation and verification phases are monitored and logged. These test steps are repeated according to a given test schedule. In particular, this repetition may be a periodic repetition of the test step. In addition, these multiple test results are aggregated and transmitted to statistical evaluation, and the test results are presented to tester personnel through the test client 5b.

In a specific test method, a test probe is initiated to ping a server installed in the IoT network 2 or IoT network component under test, eg the P-GW.

A “ping” is performed using the respective IP software utility.

After this ping procedure, completion is confirmed and again all test events are monitored and logged, and the test steps are repeated according to the given test schedule.

In another test method, the power saving function managed in the IoT serving network 2 under test may be tested. This power saving function test involves enabling a power saving mode (PSM) in each test probe 3 , and thus setting the values of the extended T3324 active timer and T3412 timer in the test probe 3 of the local unit 4 . set Then, the EPS connection of the test probe 3 in the serving IoT network 2 is initiated and the completion of the connection procedure is confirmed. Also, it is checked whether the timer value is accepted by the service IoT network 2 . This is done by comparing these values with the values requested by each test probe 3 . In addition, it is checked whether the extended periodic tracking area update (TAU) procedure has been completed. Again, all test events during this test method are monitored and logged and the above-mentioned tests are repeated according to a given schedule.

In a further test method, MT data transmission in combination with a power saving function (PSM) to be managed by the IoT serving network 2 under test is tested. To this end, downlink data towards each test probe 3 is transmitted during the time span during which the T3324 active timer runs. It is confirmed that each test probe 3 receives a complete downlink data packet.

With the help of the PSM, it is checked whether each test probe 3 can wake up from the power saving state to the communication state. For example, this wakeup may occur once a week for two minutes. In the EPS access procedure, this wake-up duty cycle is negotiated. During the test method, the wake-up function and in particular the state change between the power saving state and the communication state are tested.

Again, all test events during this test method are monitored and logged and the tests mentioned above are repeated according to the given test schedule.

In a further test method of testing the mobile MT SMS with power saving function managed by the IoT serving network 2 under test, the SMS is sent to the test probe 3 while the T3324 active timer is running.

It is then verified that the SMS has been correctly delivered to the test probe. All test events during these test methods are monitored and logged again, and the above mentioned test methods are repeated according to the given test schedule.

In another test method, the Extended Discontinuous Reception (eDRX) function managed in the IoT serving network 2 under test is tested. In this way, eDRX is enabled to set the eDRX cycle length and paging time window (PTW) values in each test probe 3 of the local unit 4 . Further, the EPS connection of the test probe 3 of the serving IoT network 2 under test is initiated. Completion of this access procedure is confirmed. In addition, it is checked whether the eDRX cycle length and PTW value have been accepted by the service IoT network 2 by comparing them with the values requested by each test probe 3 . All test events of this method are monitored and logged, and the test methods mentioned above are repeated according to the given test schedule.

In a further test method, the MT data transmission combined with the eDRX function to be managed by the IoT serving network 2 under test is tested. Here, downlink data is transmitted toward each test probe 3 within a Paging Time Window (PTW). It is checked whether the test probe 3 receives the complete downlink data packet. All test events of these test methods are monitored and logged, and the test methods mentioned above are repeated according to a given test schedule.

In a further test method, the MT SMS combined with the eDRX function to be managed by the IoT serving network 2 under test is tested. Here, the SMS is transmitted to each test probe 3 in the PTW. It is checked whether the SMS was delivered correctly to the test probe. All test events during these test methods are monitored and logged. The test method mentioned above is repeated according to the given test schedule. In a further test method, the connection-keeping power of the IoT network 2 is tested. Here, it is checked whether each test probe 3 is requested by the service IoT network 2 for separation after EPS connection or after MO or MT data transmission. This verification step is repeated many times. A plurality of test results of these test methods are aggregated. From this aggregation, the default EPS bearer context cutoff ratio is calculated.

In a further method, the IoT MO data transmission provided by the serving IoT network 2 under test is tested. Here, a Transmission Control Protocol (TCP) transmission protocol is disposed. Also, MO IoT data transmission from each test probe 3 is initiated to the application server 6 located in the home network (HPMN). It is checked whether the IoT data has been correctly received from the application server 6 . This verification step is repeated multiple times and multiple test results are aggregated, which represents the default EPS bearer context cutoff ratio. In addition, UDP (User Datagram Protocol) is deployed and the IoT MO data transmission test described above is repeated. In addition, a non-IP data delivery mechanism via NAS (Non-Access Stratum) signaling is deployed. Again, the IoT MO data transmission test is repeated.

In a further test method, the IoT MT data transmission provided by the serving IoT network 2 under test is tested. Here, after deploying the TCP transmission protocol, the application server, that is, the server of the IoT platform 6 located in the home network, is started to transmit IoT data to each test probe 3 . It is checked whether the IoT data has been completely received by each test probe 3 . Additional steps of this test method, including deployment of the UDP transport protocol and deployment of a non-IP data delivery mechanism via NAS signaling, correspond to those described above with respect to the MO data transport test method.

In a further test method, MO SMS transmission via the serving IoT network 2 under test is tested. Here, each test probe 3 is initiated to send an SMS to the partner test probe 3 of the local unit 4 in the home network HPMN. It is then checked whether the SMS has been correctly received by the partner test probe 3 . This test is repeated multiple times and the multiple test results are aggregated for further statistical evaluation.

In a further test method, MT SMS delivery via the serving IoT network 2 under test is tested. Here, the partner test probe 3 of the home network HPMN is initiated to send an SMS to the test probe 3 of the serving IoT network 2 . It is checked whether the SMS submitted by the partner test probe 3' has been correctly delivered to each test probe 3 of the serving IoT network 2 . Again, this test is repeated multiple times and multiple test results are aggregated.

2 , a further embodiment of a test system 15 for a mobile IoT network is described. Elements and functions corresponding to those described above with respect to FIG. 1 are denoted by the same reference numerals and are not discussed in detail again. A central test unit, test client and SIM multiplexer, which may also exist in the test system 15 in addition to the local unit, are not shown in FIG. 2 .

In the test system 15 , the local unit 16 containing the test probe 3 is implemented as an S1 core unit connected to the IoT network 2 via the S1 interface 17 . The communication line 18 over this S1 interface 17 is implemented as an emulated eNodeB (evolved NodeB). Details of the implementation of the S1 interface and protocol can be found in 3GPP TS 36.413 V.15.5.0: "Evolved Universal Terrestrial Access Network (E-UTRAN); S1 Application Protocol (S1AP)" published on March 15, 2019. can

3 shows another embodiment of a test system 20 . Components and functions corresponding to those already described with respect to FIGS. 1 and 2 have the same reference numerals and are not discussed in detail again.

The test system 20 provides a test for connectivity and service to the mobile IoT device in roaming conditions. Here, communication over the lines 9 , 10 , 11 is carried out across the boundary 21 between the Home Public Mobile Network (HPMN) and the Visited Public Mobile Network (VPMN). To this end, an additional interactive SCEF (IWK-SCEF) module is disposed in the VPMN in addition to the SCEF module of the HPMN in the communication line 11 .

This roaming scheme is possible with the wireless interface 5 shown again in FIG. 3 and the S1 interface 17 according to FIG. 2 (not shown in FIG. 3).

Figure 4 shows the components of a further embodiment of a test system for a mobile IoT network including details regarding testing data transmission between different test probes 3, 3', wherein these different test probes ( 3, 3') can be attributed to different, eg home/visit public mobile networks. Elements and functions corresponding to those described above with respect to FIGS. 1 to 3 have the same reference numerals and are not discussed in detail again.

The first of the test probes, the test probe 3 , is connected to the IoT platform 6 through a test communication path 22 , which may include a wireless interface 5 or an S1 interface 17 . The test probe 3 includes an MQTT/MQTT-SN client 23 communicating via a communication line 22 with an MQTT/MQTT-SN server/broker 24 of the IoT platform 6 under test.

Another test probe, the test probe 3 ′, communicates with the IoT platform 6 under test via another test communication path 25 , which may include the air interface 5 or the S1 interface 17 in FIG. 4 . To this end, the additional test probe 3' also comprises an MQTT/MQTT-SN client 23'.

Alternatively or in addition to MQTT/MQTT-SN, at least one of the following additional protocols and/or one of the following device specific interfaces may be used: oneM2M, Hypercat, CoAP, RTSP, JSON, XML.

The use of a particular protocol/interface depends on each IoT device and/or each application. For example, CoAP is suitable for limited networks with low bandwidth and low power.

The test probes 3 , 3 ′ may be part of a mobile device, ie part of a vehicle such as a bicycle or automobile. In this case, the test device may initiate a tracking area update whenever each test probe 3 enters a new tracking area within the MIoT network 2 . After this tracking area update, data assigned to the PSM and/or assigned to the eDRX function may be renegotiated and/or overridden by initiation of the test system.

Using particularly one of the test methods described above, the relevant IoT data transmitted by the test probe 3 and stored in the platform under test 6 can be retrieved by the test probe 3 ′. The retrieved data is compared with the transmitted original data. A corresponding test result may be assigned.

The test probes 3 and 3' may be disposed in the same home network. Alternatively and as indicated in FIG. 4 , the test probes 3 , 3 ′ may be located in a separate network. For example, as shown in FIG. 4 , the test probe 3 may be located in the visited public network VPMN and the additional test probe 3 ′ may be located in the home public mobile network HPMN. Through such a configuration, the IoT application platform test under IoT device roaming as described above may be performed worldwide.

Claims (15)

An active test system (1; 15; 20) for a mobile IoT network (2) providing connectivity and services to mobile IoT (MIOT) devices of low power wide area (LPWA) technology, the active test system (1; 15; 20) comprising:
- the test system is designed to test the MIoT service quality of the serving MIoT network under test and to test the MIoT service availability;
- The test system is
-- at least one test probe (3; 3, 3') connected to the MIoT network (2) via the LTE-Uu interface (5) and/or
-- having at least one test probe (3; 3, 3') connected to the MIoT network (2) via the S1 interface (17);
- a central test unit (5a) connected (8) to at least one test probe (3; 3, 3') via a wireless backhaul network or a static IP network (7);
- a SIM multiplexer (12) for transmitting SIM data in the test field to at least one test probe (3; 3, 3');
- The test system configures and initiates a test probe for the EPS connection in the serving MIoT network under test, confirms the completion of the test procedure, monitors and records all test events, and repeats the test steps described above according to the test schedule A test system designed to The method of claim 1,
A test system, configured to exchange signaling messages and send IP data, non-IP data or SMS to/from the MIoT network (2) under test. 3. The method according to claim 1 or 2,
The at least one test probe (3; 3, 3') is a serving network, that is, a home IoT network (2, HPMN) under test for a domestic MIoT service test or a visited MIoT network (2) under test for an international MIoT roaming service test , a test system configured to be deployed to a VPMN). 4. The method of claim 3,
Different test connections across different MIoT network (2) components via MME, S-GW, P-GW, SCEF, IWK-SCEF, SCS, AS, as well as across roaming interfaces S6a, S8, SGd, T7 and a test system configured to test the MIoT serving network under test for the communication path. 5. The method according to any one of claims 1 to 4,
It communicates with the MIoT platform 6 under test via MQTT/MQTT-SN messages, and the availability and connectivity of the MIoT platform 6 through the underlying MIoT network, and end-to-end between the MIoT platform 6 and mobile IoT devices. end-to-end) a test system, configured to verify data transmission and data integrity. A test method using the test system according to any one of claims 1 to 5 for testing the MIoT service quality of the serving MIoT network under test. 7. The method of claim 6,
Test MIoT service availability and follow these steps:
- configuring and initiating a test probe for EPS connectivity in the serving MIoT network under test;
- confirming the completion of the completion of the access procedure;
- monitoring and logging all test events;
- repeating the test steps described above according to the test schedule
including, a test method. 8. The method according to claim 6 to 7,
Test IoT network connectivity and follow these steps:
- initiating a test probe to ping a server in the serving MIoT network under test;
- confirming the completion of the ping procedure;
- monitoring and logging all test events;
- repeating the test steps described above according to the test schedule
including, a test method. 9. The method according to any one of claims 6 to 8,
Test the power saving function to be managed by the MIoT serving network under test and follow these steps:
- setting the values of the extended T3324 active timer and T3412 timer in the test probe by enabling PSM (sleep mode);
- initiating EPS connection of the test probe in the serving MIoT network;
- confirming the completion of the access procedure;
- checking whether the service MIoT network accepts the timer values and comparing these values with the values requested by the test probe;
- checking whether the extended periodic Tracking Area Update (TAU) procedure is accepted;
- monitoring and logging all test events;
- repeating the aforementioned test steps according to the test schedule
including, a test method. 10. The method according to any one of claims 6 to 9,
Test the eDRX functionality to be managed by the IoT serving network under test and follow these steps:
- setting values of eDRX cycle length and PTW (paging time window) in the test probe by enabling Extended Discontinuous Reception (eDRX);
- initiating the EPS connection of the test probe in the serving IoT network under test;
- confirming the completion of the access procedure;
- checking whether the service IoT network accepts the eDRX cycle length and PTW values and comparing these values with the values requested by the test probe;
- monitoring and logging all test events;
- repeating the test steps described above according to the test schedule
including, a test method. 11. The method according to any one of claims 6 to 10,
Test the connectivity of your IoT network and follow these steps:
- Checking whether the test probe is requested by the serving IoT network for separation after EPS access or after mobile origination (MO) or mobile termination (MT) data transmission;
- repeating the verification step multiple times;
- Aggregating multiple test results indicating a default EPS bearer context cut-off ratio
including, a test method. 12. The method according to any one of claims 6 to 11,
Testing the IoT MO data transmission provided by the serving IoT network under test consists of the following steps:
- deploying the TCP transport protocol;
- initiating mobile outgoing IoT data transmission from the test probe to the application server located in the home network (HPMN);
- Checking whether IoT data was received correctly from the application server;
- repeating the verification step multiple times;
- aggregating multiple test results representing the default EPS bearer context cutoff ratio;
- deploying the UDP transport protocol;
- repeat the IoT MO data transmission test;
- deploying a non-IP data delivery mechanism via NAS signaling;
- Steps to repeat IoT MO data transmission test
including, a test method. 13. The method according to any one of claims 6 to 12,
Test the IoT MT data transmission provided by the serving IoT network under test and follow these steps:
- deploying the TCP transport protocol;
- starting an application server located in the home network (HPMN) to send IoT data to the test probe;
- checking whether IoT data has been completely received from the test probe;
- repeating the verification step multiple times;
- aggregating multiple test results representing the default EPS bearer context cutoff ratio;
- deploying the UDP transport protocol;
- Repeat the IoT MT data transmission test;
- deploying a non-IP data delivery mechanism via NAS signaling;
- Repeat the IoT MT data transmission test
including, a test method. 14. The method according to any one of claims 6 to 13,
Test sending MO SMS over the serving IoT network under test and follow these steps:
- initiating the test probe to send an SMS to the partner test probe in the home network (HPMN);
- checking whether the SMS has been correctly delivered to the partner test probe;
- multiple iterations of the test;
- Aggregating multiple test results
including, a test method. 15. The method according to claim 6 to 14,
Test MT SMS delivery through the IoT network under test and follow these steps:
- initiating the partner test probe of the home network to send an SMS to the test probe of the serving IoT network;
- checking whether the SMS submitted by the partner test probe has been correctly delivered to the test probe of the serving IoT network;
- multiple iterations of the test;
- Aggregating multiple test results
including, a test method.

Images