Patent Description:
The current disclosure relates to testing and simulation systems / devices used for testing base stations and other radio equipment used in cellular networks. Often in these test cases, a plurality of communication operations are simulated amongst the various software/hardware components of the base station to ensure that these components are compatible with each other.

In this regard, testing device for testing a base station with radio units and a baseband unit is known. These testing devices often include a configuration module to generate various test case configurations in relation to various test scenarios in relation to the radio units and the baseband unit.

These test configurations include a plurality of parameters used by the testing devices for simulation of the test cases. These parameters are associated with the type of packets to be simulated in the test case, payload of the packets, frequency of the packets, protocol stack associated with the packet, etc. The parameters associated with the protocol stack define the various protocols of the protocol stack which are layered one other to process packets according to the protocol specifications. Examples of such protocols include IP protocol (on a network layer), UDP protocol (on a transport layer), TCP protocol (on a transport layer), etc..

This configuration of packet and protocol parameters is done by user or test personnel and is often time consuming; requiring considerable manual effort. Since these test cases often cover a multiplicity of conditions, often a multitude of packet parameters are to be configured by the user. Accordingly, the possibility of errors made by the users also increases considerably.

In one approach to address this issue, a plurality of packets of a similar type are logically organized at higher level abstraction known as streams. Instead of defining communication parameters of each packet, streams allow users to define the communication parameters of a set of packets belonging to a single stream in a single declaration. For example, for a particular stream (i.e. stream <NUM>), one or more parameters associated with a protocol stack of the packets belonging to stream <NUM> may be defined or declared using a stream level protocol parameter.

However, such configuration or definition of parameters still time consuming and require effort. Moreover, a plurality of parameters associated with the testing device may have proprietary names and accordingly may lead to some confusion amongst the test personnel. Accordingly, there is a need for a device and method for testing of base stations which addresses the aspects mentioned above.

The above mentioned problems are addressed by a device according to claim <NUM>, a method according to claim <NUM> and a non-transitory storage medium according to claim.

Advantageous embodiments are subject of the dependent claims. Accordingly, the current disclosure proposes a device for testing a base station. The base station comprises one or more radio units and a baseband unit connectable to the one or more radio units. The device comprises a configuration module configured to generate a first test case configuration associated with the radio units and the baseband unit. The first test case configuration includes a first protocol stack comprising a first protocol associated with a first layer and a second protocol associated with a second layer. The device is characterized in that a first set of protocol parameters associated with the first protocol is in a first namespace and a second set of protocol parameters associated with the second protocol is in a second namespace wherein the second namespace distinct from the first name space.

Accordingly, by incorporating namespaces in the first test case configuration, naming of protocol parameters is simplified as two parameters can have the same name while belonging to two separate namespaces (associated with two corresponding protocols). Accordingly, this helps users in utilizing the parameters easily. Additionally, the users can easily search for parameters due to the simplified namespace. This helps in improving the efficacy of the testing device. Moreover, since protocol parameters of each protocol are in a separate namespace, making modification to a specific protocol parameter does not require the user to check protocol parameters of other protocols for consistency.

By introducing distinct namespaces in test configurations, it is now possible to easily add, remove, or change layers of the protocol stack without having to edit all the parameters in the test configuration. Additionally, it is simpler to relate parameters to standards/specifications, and accordingly, the user knows which document to look at for information or the parameter and doesn't have to deduce it from the parameter name alone.

Furthermore, at least one parameter from the first set of protocol parameters associated with the first protocol includes a value indicative of the second protocol. In an example, the second protocol immediately succeeds the first protocol in the first protocol stack. This helps in checking if the namespace as specified by the user for the second protocol is inline with the value as specified in the first protocol.

In an example, a name of each parameter from the first set of protocol parameters is based on the first protocol and a name of each parameter from the second set of protocol parameters is based on the second protocol. This helps in easily identifying which protocol, the corresponding parameter is related to. Accordingly, there is less need for proprietary parameter names and helps in improving the usability of the testing device.

In an example, the device for testing the base station, further comprises a simulation module to simulate one or more operations between the one or more radio units and the baseband unit in accordance with the first test case configuration. This allows for testing of software aspects of the base station without requiring expensive equipment. In an example, the first protocol stack is associated with a first stream, and the simulation module is configured to generate a plurality of packets based on the first stream, such that each packet from the plurality of packets includes a packet header based on the first protocol stack.

In an example, the first test case configuration includes a second protocol stack comprising a third protocol associated with the first layer and a fourth protocol associated with the second layer. In an example, the second protocol stack is associated with a second stream. Accordingly, two or more streams may be configured according to the invention for simulation of multiple types of packets.

#In an example, the configuration module includes a graphical user interface (GUI) for receiving a plurality of values associated with the first and second set of protocol parameters associated with the first and second protocols of the first protocol stack. The GUI allows for easy configuration of the protocol parameters.

In another example, name of each parameter from the first set of protocol parameters includes a namespace token associated with the first protocol. This allows for easy identification of protocol associated with the corresponding parameter by the user and by the simulation module.

In another aspect, the current invention discloses a method for testing a base station. The method comprises generating a first test case configuration associated with the one or more radio units and the baseband unit and simulating one or more operations between the one or more radio units and the baseband unit. Simulating the one or more operations comprising generating one or more packets based on the first test case configuration, each packet from the one or more packets comprising a packet header based on the first protocol stack. The first set of protocol parameters associated with the first protocol are in a first namespace and the second set of protocol parameters associated with the second protocol are in a second namespace, the second namespace distinct from the first name space.

In an example, generating the first test case configuration comprises receiving a plurality of values associated with the first and second set of protocol parameters associated with the first and second protocols using a graphical user interface (GUI).

In another aspect, the current invention discloses a test case configuration repository one or more test case configurations including the first test case configuration.

In another aspect, the current invention discloses a non-transitory storage medium for testing a base station. The non-transitory storage medium has a plurality of machine-readable instructions stored therein, which when executed by one or more processors, cause the one or more processors to generate a first test case configuration associated with the one or more radio units and the baseband unit, wherein the first test case configuration includes a first protocol stack comprising a first protocol associated with a first layer and a second protocol associated with a second layer; and simulate one or more operations between the one or more radio units and the baseband unit, wherein simulating the one or more operations comprising generating one or more packets based on the first test case configuration, each packet from the one or more packets comprising a packet header based on the first protocol stack; wherein a first set of protocol parameters associated with the first protocol are in a first namespace and wherein a second set of protocol parameters associated with the second protocol are in a second namespace, the second namespace distinct from the first name space. Advantages of the device claims and corresponding embodiments also apply to the corresponding method claims and the corresponding non-transitory storage medium claims. These aspects are further described in relation <FIG>.

<FIG> illustrates an example system <NUM> for testing a base station <NUM>. The base station <NUM> may be connected to a cellular network (not shown in <FIG>) comprising of other base stations and the network core. The base station <NUM> comprises a central unit <NUM>, one or more distributed units (shown in <FIG> as distributed unit <NUM>), and one or more radio units (shown in <FIG> as radio units <NUM>, <NUM>). The central unit <NUM> and the distributed unit <NUM> is jointly referred to as baseband unit <NUM>. The central unit <NUM> processes non-real time protocols and services, and the distributed unit <NUM> processes physical level protocols and latency-critical real time services. The radio units carry out link layer and physical layer signal processing when transmitting and receiving radio signals. The connections between the various radio units (<NUM>, <NUM>) and the distributed unit <NUM> are based ethernet based protocol stacks and focus on various aspects in relation to the radio units such as antenna data, beamforming control, management, and synchronization. Examples of such protocol stacks include O-RAN with eCPRI or IEEE1914. <NUM> (RoE) as antenna data transport layer and optional UDP over IPv4 or IPv6 as the routable transport layer, etc..

In an example, base station <NUM> may be a part of a radio access network of a wireless communication system, e.g. a cellular communication system. The wireless communication system may operate according to specifications of Universal Mobile Telecommunication System or any one of its evolution versions, e.g. Long-Term Evolution (LTE) or LTE-Advanced, a second-generation mobile telecommunication system such as Global System for Mobile Communications, or a system operating strictly on unlicensed frequency bands. An example of a system operating on the unlicensed bands is IEEE <NUM> (Wi-Fi) and, as a consequence, the base station may be considered broadly as an access point providing a terminal device with wireless access to other networks such as the Internet.

The system <NUM> comprises a testing device <NUM> for testing and simulation of various operations amongst the components of the base station <NUM>. The testing device <NUM> is be connected to one or more interfaces of the base station <NUM> so as to test one or more features or performance of the base station <NUM>. Examples of the interfaces include an interface between the baseband unit <NUM> and the radio units (<NUM>, <NUM>), the interface between the base band unit <NUM> and the core network, etc. The base station <NUM> may comprise physical connectors to which the testing device <NUM> may be connected in order to test the operation and performance of the base station. Such physical connectors may include BNC connectors, optical connectors such as LC, SMA connectors, RJ45 connectors, small form-factor (SFP or SFP+) connectors, quad SFP(+) connectors etc..

In an example, the testing device <NUM> may comprise a network interface connecting the testing the device <NUM> to a communication network (not shown in <FIG>). The communication network may comprise a local area network (LAN), a wide area network (WAN), and/or the Internet. The network interface may enable remote controlling of the testing device, connection with a remote database storing test programs and/or test results, and/or communication between two or more mutually remote testing devices. A user interface device such as a personal computer or a laptop computer may be connected to the communication network and configured to control the testing of the base station.

The testing device <NUM> is configured to generate a plurality of packets to be transmitted between the various components of the base station <NUM>. For generating the packets, the testing device <NUM> includes a configuration module which is configured to generate one or more test case configurations. Each test case configuration from the one or more test case configurations, includes a plurality of parameters in accordance to which the packets are generated by a simulation module of the testing device <NUM>. In an example, the configuration module includes a graphical user interface for receiving a plurality of values for the plurality of parameters of the test case configurations. These aspects in relation to the test case configurations is further explained using an example test case configuration as illustrated in <FIG>.

<FIG> illustrates a test case configuration <NUM> (also referred to as first test case configuration <NUM>) for testing the base station <NUM>. In an example, the first test case configuration <NUM> is generated by the configuration module based one or more user inputs. The first test case configuration <NUM> includes a first protocol stack associated with a first stream (also referred to as stream <NUM> in <FIG>). The first protocol stack as defined in the configuration <NUM> is used by the simulation module for generating packets associated with the first stream. For example, the packet headers of the packets belonging to the first stream are generated in accordance with the first protocol stack associated with the first stream.

The first protocol stack comprises a plurality of protocols running concurrently for processing protocol data units (such as datagrams, data frames, packets, etc.) in accordance with the specifications of each protocol of the protocol stack. Each protocol from the protocol stack is associated with a layer of an interconnection suite (similar to the layers of OSI interconnection model or TCP/IP interconnection model). Each protocol is stacked on top of a preceding protocol in the protocol stack. This means that a data unit received is first processed by the preceding protocol and then by the succeeding protocol. Similarly, a data unit to be transmitted is first processed by the succeeding protocol and then by the preceding protocol. An example first protocol stack is illustrated in <FIG>.

<FIG> illustrates (a diagrammatic representation) of the first protocol stack <NUM>. The first protocol stack <NUM> comprises six protocols stacked on each other to form the protocol stack <NUM>. The first layer of the protocol stack <NUM> is based on ethernet protocol (shown as protocol block <NUM>). The second layer of the protocol stack <NUM> is based on ethernet protocol (shown as protocol block <NUM>). The third layer of the protocol stack <NUM> is based on internet protocol (IP) (shown as protocol block <NUM>). The fourth layer of the protocol stack <NUM> is based on user datagram protocol (UDP) (shown as protocol block <NUM>). The fifth layer of the protocol stack <NUM> is based on eCPRI (shown as protocol block <NUM>) and O-RAN C/U plane specifications (shown as protocol block <NUM>). Finally, the sixth layer of the first protocol stack <NUM> is based on the <NUM> New Radio specifications (shown as protocol block <NUM>).

The protocols of the first protocol stack <NUM> and associated protocol parameters are defined in the test case configuration <NUM>. Particularly, each set of protocol parameters associated with a corresponding protocol is in a separate and distinct namespace from other sets of protocol parameters associated with the other protocols of the protocol stack <NUM>. Namespace herein refers to a logical area accommodating a plurality of parameter names such that two parameters having the same parameter name can co-exist in two separate namespaces without conflict. In other words, each namespace provides a logical context in which those parameters may exist without overlapping with parameters in other namespaces. In an example, each namespace associated with the corresponding protocol is specified as a token in parameter name of each protocol parameter associated with the corresponding protocol.

For example, as shown in <FIG>, parameters associated with the IP protocol on layer <NUM> (i.e. protocol block <NUM>) are defined in code segment <NUM> of the test case configuration <NUM>. The protocol parameters associated with IP protocol (such as source IP address, destination IP address, etc.,) are in a first namespace associated with the IP protocol (IPv4 in the current example). Accordingly, each protocol parameter name includes a 'IPv4' token in its name to indicate the first namespace associated with the IPv4 protocol.

Similarly, parameters associated with the UDP protocol on layer <NUM> (i.e. protocol block <NUM>) are defined in code segment <NUM> of the test case configuration <NUM>. The protocol parameters associated with UDP protocol (such as source UDP port, destination UDP port, etc.,) are in a second namespace associated with the UDP protocol. Accordingly, each protocol parameter name includes a 'UDP' token in its name to indicate the second namespace associated with the UDP protocol.

Accordingly, this allows for two parameters having the same name to exist in two separate namespaces without conflict. For example, a parameter indicative of version of the IP protocol can have the parameter name `version' along with the parameter indicative of the version of the UDP protocol without any conflict. This is possible as the parameter name of the parameter indicative of version of the IP protocol includes the namespace token 'IPv4' (i.e. stream1. version) and similarly, the parameter name of the parameter indicative of version of the UDP protocol includes the namespace token 'UDP' (i.e. stream1.

Similarly, parameters associated with the eCRPI protocol on layer <NUM> (i.e. protocol block <NUM>) are defined in code segment <NUM> of the test case configuration <NUM>. The protocol parameters associated with eCPRI protocol (such as type, RTC_ID, etc.,) are in a third namespace associated with the eCPRI protocol. Accordingly, each protocol parameter name includes a 'eCPRI' token in its name to indicate the third namespace associated with the eCPRI protocol. Similarly, parameters associated with the O-RAN NR protocol on layer <NUM> (i.e. protocol block <NUM>) are defined in code segment <NUM> of the test case configuration <NUM>. The protocol parameters associated with O-RAN NR protocol (such as data direction, payload version, etc.,) are in a fourth namespace associated with the O-RAN NR protocol. Accordingly, each protocol parameter name includes a 'ORAN' token in its name to indicate the fourth namespace associated with the O-RAN NR protocol. Similarly, parameters associated with the ethernet protocol on layer <NUM> (i.e. protocol block <NUM>) are defined in code segment <NUM> of the test case configuration <NUM>. The protocol parameters associated with ethernet protocol (such as type, source address, etc.,) are in a fourth namespace associated with the ethernet protocol.

Additionally, in an example, at least one parameter from the first set of protocol parameters associated with the first protocol includes a value indicative of the second protocol. In an example, the second protocol is a layer immediately succeeding the first protocol in the first protocol stack. For example, as shown in <FIG>, the ethernet protocol (protocol block <NUM>) includes a parameter 'ethertype' which includes a value indicative of the next protocol 'IPv4' as shown on line <NUM>. Similarly, the IP protocol (protocol block <NUM>) includes a parameter 'protocol' which includes a value indicative of the next protocol 'UDP' as shown on line <NUM>. Similarly, the UDP protocol (protocol block <NUM>) includes a parameter 'NextHeader' which includes a value indicative of the next protocol 'eCPRI' as shown on line <NUM>. By including a reference of the succeeding protocol in the parameter set of the first protocol, the configuration module is configured to set the following namespace of the succeeding protocol.

The first test case configuration <NUM> is used by the simulation module of the testing device <NUM> to simulate the one or more operations between the radio units (<NUM>, <NUM>) and the baseband unit (<NUM>). In an example, the one or more operations include simulation of transmission and reception of packets in relation to the base station <NUM>. In this regard, the simulation module generates a plurality of packets in accordance with the first stream as defined in the first test case configuration <NUM>. A plurality of stream properties may be defined in relation to first stream in the first test case configuration <NUM>. Some examples of the stream properties include stream direction (indicative of whether a stream of packets is in the Uplink direction i.e. up from the UE towards core network, or Downlink direction i.e. down from the core network towards the UE), stream type, stream priority, packet type, etc. Examples of stream types include Control Plane Downlink (CP_DL), Control Plane Uplink (CP_UL), User Plane DL (UP_DL), and User Plane Uplink (UP_UL) streams for carrying antenna data between O-DU and O-RU.

Accordingly, the packet types, formats and the headers are based on the first protocol stack <NUM>. For example, as shown in <FIG>, each packet of the first stream has a packet header format <NUM> in accordance to the protocol stack <NUM>. Accordingly, the packet header format <NUM> includes ethernet header comprising a plurality of sections (for example destination address section <NUM>, source address section <NUM>, ethertype section <NUM>). The ethernet header is associated with the ethernet protocol (i.e. protocol block <NUM>). Similarly, the packet header format <NUM> includes an IP-UDP header (shown as IP-UDP sections <NUM>-<NUM>). The IP-UDP header is associated with the IP and UDP protocols of the first protocol stack <NUM> (i.e. protocol blocks <NUM> and <NUM>). Similarly, the packet header format <NUM> includes an eCPRI header (shown as section <NUM>). The eCPRI header is associated with the eCPRI protocol of the first protocol stack <NUM> (i.e. protocol block <NUM>). Similarly, the packet header format <NUM> includes an O-RAN header (shown as section <NUM>). The O-RAN header is associated with the O-RAN <NUM> NR protocols of the first protocol stack <NUM> (i.e. protocol blocks <NUM>).

While the first test case configuration <NUM> is explained using a first protocol stack <NUM> associated with the first stream, in an example, the first test case configuration <NUM> includes a plurality of streams and a plurality of corresponding protocol stacks. Accordingly, the first test case configuration <NUM> may include a second stream and a second protocol stack. The second protocol stack may include the same number of layers as the first protocol stack while having different protocols from the first protocol stack <NUM>. For example, instead of UDP protocol in the fourth layer, the second protocol stack may include TCP protocol (also known as third protocol) in the fourth layer. Similarly, instead of IPv4 protocol in the third layer, the second protocol stack may include IPv6 (also known as fourth protocol) in the third layer.

<FIG> illustrates a method <NUM> for testing a base station <NUM>. The method <NUM> is realized by the testing device <NUM>. The method <NUM> comprises generating (shown in <FIG> as step <NUM>) by the configuration module of the device <NUM>, the first test case configuration <NUM> associated with the one or more radio units (<NUM>, <NUM>) and the baseband unit <NUM>. As mentioned previously, the first test case configuration <NUM> includes the first protocol stack <NUM>. The first protocol stack <NUM> comprises two or more protocols including a first protocol (for example protocol block <NUM>) associated with a first layer and a second protocol (for example protocol block <NUM>) associated with a second layer. In an example, the configuration module includes a graphical user interface (GUI) for receiving a plurality of values associated with first and second set of protocol parameters associated with the first and second protocols.

Then at step <NUM>, the simulation module of the device <NUM> simulates one or more operations between the one or more radio units and the baseband unit. For simulating the one or more operations, the simulation module generates one or more packets based on the first test case configuration. In an example, each packet of one or more packets of the first stream comprise a packet header based on the first protocol stack <NUM>. Additionally, as mentioned previously, the first set of protocol parameters associated with the first protocol <NUM> are in a first namespace <NUM> and similarly, the second set of protocol parameters associated with the second protocol <NUM> are in the second namespace <NUM>, the second namespace <NUM> being distinct from the first name space <NUM>.

The present disclosure can take a form of a computer program product comprising program modules accessible from computer-usable or computer-readable medium storing program code for use by or in connection with one or more computers, processing units, or instruction execution system. For example, the configuration module may be realized across one or more devices.

Accordingly, the current disclosure as describes an example testing device <NUM>. The testing device <NUM> includes an Input/Output (I/O) module <NUM>, one or more processors <NUM> and a non-transitory storage medium <NUM>. The non-transitory storage medium <NUM> contains a plurality of instructions <NUM> for testing the base station <NUM>. In an example, the configuration module <NUM> and the simulation module <NUM> are realized by the one or more processors <NUM>. Upon execution of the instructions <NUM>, the one or more processors to generate a first test case configuration associated with the one or more radio units and the baseband unit, wherein the first test case configuration includes a first protocol stack comprising a first protocol associated with a first layer and a second protocol associated with a second layer; and simulate one or more operations between the one or more radio units and the baseband unit, wherein simulating the one or more operations comprising generating one or more packets based on the first test case configuration, each packet from the one or more packets comprising a packet header based on the first protocol stack; wherein a first set of protocol parameters associated with the first protocol are in a first namespace and wherein a second set of protocol parameters associated with the second protocol are in a second namespace, the second namespace distinct from the first name space.

While the current disclosure describes the testing device <NUM> as an independent component or device, the testing device <NUM> may be a software component and may be realized within the base station <NUM> or any other management device in the network. Similarly, in an example, one or more components of the base station <NUM> may be actual physical components or logical simulations simulated with the testing device <NUM> or any other testing/simulation device connected to the testing device <NUM>. For example, the one or more radio units (<NUM>, <NUM>) may be simulated on another testing device connected to the baseband unit <NUM> and the testing device <NUM>.

In an example, the non-transitory storage medium <NUM> includes configuration repository <NUM>. The configuration repository <NUM> (also referred to as test case configuration repository <NUM>) includes one or more test case configurations generated by the configuration module <NUM>. The one or more test case configurations includes the first test case configuration <NUM>. A test personnel can select a test case configuration from the test case configurations to be tested using the simulation module <NUM> for testing the base station <NUM>.

For the purpose of this description, a computer-usable or computer-readable non-transitory storage medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation mediums in and of themselves as signal carriers are not included in the definition of physical computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, random access memory (RAM), a read only memory (ROM), a rigid magnetic disk and optical disk such as compact disk read-only memory (CD-ROM), compact disk read/write, and DVD. Both processing units and program code for implementing each aspect of the technology can be centralized or distributed (or a combination thereof) as known to those skilled in the art.

Claim 1:
A device (<NUM>) for testing a base station (<NUM>) comprising one or more radio units (<NUM>, <NUM>) and a baseband unit (<NUM>) connectable to the one or more radio units (<NUM>, <NUM>), the device (<NUM>) comprising:
a. a configuration module (<NUM>) configured to generate a first test case configuration (<NUM>) associated with the one or more radio units (<NUM>, <NUM>) and the baseband unit (<NUM>), wherein the first test case configuration (<NUM>) includes a first protocol stack (<NUM>) comprising a first protocol (<NUM>) associated with a first layer and a second protocol (<NUM>) associated with a second layer;
the device (<NUM>) characterized in that a first set of protocol parameters associated with the first protocol (<NUM>) is in a first namespace (<NUM>) and wherein a second set of protocol parameters associated with the second protocol (<NUM>) is in a second namespace (<NUM>), the second namespace (<NUM>) distinct from the first name space (<NUM>),
wherein at least one parameter (<NUM>) from the first set of protocol parameters associated with the first protocol (<NUM>) includes a value indicative of the second protocol (<NUM>) and wherein the second protocol (<NUM>) is stacked on top of the first protocol (<NUM>) in the first protocol stack (<NUM>).