CN114830711B - Apparatus for testing base station - Google Patents

Abstract

The present invention describes a device for testing a base station, the base station comprising one or more radio frequency units and a baseband unit connectable to the one or more radio frequency units. The device comprises a configuration module, the configuration module being configured to generate a first test case configuration associated with the one or more radio frequency units and the baseband unit. The first test case configuration comprises a first protocol stack, the 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 located in a first namespace, a second set of protocol parameters associated with the second protocol is located in a second namespace, and the second namespace is different from the first namespace.

Description

Equipment for testing base stations

Background Art

The present invention relates to testing and simulation equipment, and more particularly, to testing equipment for testing base stations and other wireless devices associated with cellular networks. Current testing systems for testing pre-transmission networks are usually software-based testing systems that use software to create and analyze test cases, etc. Therefore, it is necessary to rely on multiple parameter lists to configure test cases.

Summary of the invention

The present invention relates to testing and simulation systems/devices for testing base stations and other wireless devices used in cellular networks. In these test cases, typically, multiple communication operations are simulated between various software/hardware components of the base station to ensure that these components are compatible with each other.

In this regard, test equipment for testing a base station having a radio frequency unit and a baseband unit is known. These test equipments usually include a configuration module for generating various test case configurations associated with various test scenarios related to the radio frequency unit and the baseband unit.

These test configurations include test equipment for simulating multiple parameters of the test case. These parameters are related to the type of data packets to be simulated in the test case, the payload of the data packets, the frequency of the data packets, the protocol stack associated with the data packets, etc. The parameters associated with the protocol stack define the various protocols of the protocol stack, which are layered on top of each other for processing data packets according to the protocol specifications. Examples of such protocols include Internetworking Protocol (IP) protocol (on the network layer), User Datagram Protocol (UDP) (on the transport layer), Transmission Control Protocol (TCP) (on the transport layer), etc.

This configuration of data packets and protocol parameters is done by the user or tester and is usually time-consuming and labor-intensive. Because these test cases usually cover a variety of conditions, users usually need to configure many data packet parameters. Therefore, the possibility of user errors is also greatly increased.

In one approach to solving this problem, multiple packets of similar types are logically organized at a higher level of abstraction, called a data stream. A data stream enables a user to define communication parameters for a group of packets belonging to a single data stream in a single declaration, rather than defining communication parameters for each packet. For example, for a particular data stream 1 (i.e., stream 1), one or more parameters associated with the protocol stack for packets belonging to data stream 1 can be defined or declared using data stream level protocol parameters.

However, the configuration or definition of such parameters is still time-consuming and laborious. In addition, multiple parameters associated with the test equipment can have proprietary names, which can lead to some confusion among testers. Therefore, a device and method for testing a base station is needed to address the above aspects.

The above mentioned problem is solved by an apparatus according to the invention, a method according to the invention, a test case configuration repository according to the invention and a non-transitory storage medium according to the invention. Advantageous embodiments are subject matter of the dependent claims.

Therefore, the present invention proposes a device for testing a base station. The base station includes one or more radio frequency units and a baseband unit that can be connected to the one or more radio frequency units. The device includes a configuration module, which is configured to generate a first test case configuration associated with the radio frequency unit and the baseband unit. The first test case configuration includes a first protocol stack, which includes 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 located in a first namespace, and a second set of protocol parameters associated with the second protocol is located in a second namespace, wherein the second namespace is different from the first namespace.

Thus, by merging the namespaces in the first test case configuration, the naming of the protocol parameters is simplified to two parameters that can have the same name, while belonging to two separate namespaces (associated with two respective protocols). Thus, this helps the user to easily utilize the parameters. Furthermore, due to the simplified namespaces, the user can easily search for parameters. This helps to improve the efficiency of the test equipment. Additionally, since the protocol parameters of each protocol are in separate namespaces, the user can modify specific protocol parameters without having to check the consistency of the protocol parameters of other protocols.

By introducing different namespaces in the test configuration, it is now possible to easily add, remove or change layers of the protocol stack without editing all the parameters in the test configuration. In addition, the parameters are simply associated with the standard/specification, so the user does not have to infer from the parameter name alone to know which document to look at for information or parameters.

In one example, at least one parameter from a first set of protocol parameters associated with a first protocol includes a value indicative of a second protocol. In one example, the second protocol immediately follows the first protocol in the first protocol stack. This helps to check whether a user-specified namespace for the second protocol is inline with a value specified in the first protocol.

In one example, the name of each parameter from the first set of protocol parameters is based on the first protocol and the name of each parameter from the second set of protocol parameters is based on the second protocol. This facilitates easy identification of the protocol associated with the corresponding parameter. Thus, the need for proprietary parameter names is reduced, which helps improve the usability of test equipment.

In one example, the device for testing the base station further includes a simulation module for simulating one or more operations between one or more radio frequency units and a baseband unit according to a first test case configuration. This enables the software performance of the base station to be tested without the need for expensive equipment. In one example, the first protocol stack is associated with the first data stream, and the simulation module is configured to generate a plurality of data packets based on the first data stream, so that each data packet from the plurality of data packets includes a data packet header based on the first protocol stack.

In one example, the first test case configuration includes a second protocol stack, which includes a third protocol associated with the first layer and a fourth protocol associated with the second layer. In one example, the second protocol stack is associated with the second data stream. Therefore, two data streams or multiple data streams can be configured according to the present invention to simulate multiple types of data packets.

In one example, the configuration module includes a graphical user interface (GUI) for receiving a plurality of values related to a first set of protocol parameters and a second set of protocol parameters associated with a first protocol and a second protocol of a first protocol stack. The graphical user interface (GUI) makes it easy to configure the protocol parameters.

In another example, the name of each parameter from the first set of protocol parameters includes a namespace token associated with the first protocol. This enables users and simulation modules to easily identify the protocol associated with the corresponding parameter.

In another aspect, the present invention discloses a method for testing a base station. The method includes generating a first test case configuration associated with one or more radio frequency units and baseband units, and simulating one or more operations between the one or more radio frequency units and the baseband units. The simulation of the one or more operations includes generating one or more data packets based on the first test case configuration, each of the one or more data packets including a data packet header based on a first protocol stack. A first set of protocol parameters associated with the first protocol is located in a first namespace, and a second set of protocol parameters associated with the second protocol is located in a second namespace, and the second namespace is different from the first namespace.

In one example, generating a first test case configuration includes receiving, using a graphical user interface (GUI), a plurality of values related to a first set of protocol parameters and a second set of protocol parameters associated with a first protocol and a second protocol.

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

On the other hand, the present 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, and when executed by one or more processors, the instructions cause the one or more processors to generate a first test case configuration associated with one or more radio frequency units and a baseband unit, wherein the first test case configuration includes a first protocol stack, the first protocol stack consisting of 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 frequency units and the baseband unit, wherein simulating the one or more operations includes generating one or more data packets based on the first test case configuration, each data packet from the one or more data packets includes a data packet header based on the first protocol stack; wherein a first set of protocol parameters associated with the first protocol is located in a first namespace, and a second set of protocol parameters associated with the second protocol is located in a second namespace, and the second namespace is different from the first namespace. The advantages of the device claims and the corresponding embodiments are also applicable to the corresponding method claims and the corresponding non-transitory storage medium claims. Figures 1-6 further describe these features.

BRIEF DESCRIPTION OF THE DRAWINGS

The following detailed description refers to the accompanying drawings, in which:

FIG1 illustrates an exemplary system including a test device for testing a base station;

FIG2 illustrates an exemplary test case configuration for testing a base station;

FIG3 illustrates an exemplary protocol stack for testing a base station;

FIG4 illustrates an exemplary header of a data packet generated according to an exemplary protocol stack;

FIG5 illustrates an exemplary method for testing a base station; and

FIG. 6 shows an exemplary test device for testing a base station.

DETAILED DESCRIPTION

FIG. 1 is an exemplary system 100 for testing a base station 120. The base station 120 is capable of connecting to a cellular network including other base stations and a network core (the network is not shown in FIG. 1). The base station 120 includes a central unit 130, one or more distributed units (such as the distributed unit 140 shown in FIG. 1), and one or more radio frequency units (such as the radio frequency units 155, 165 shown in FIG. 1). The central unit 130 and the distributed unit 140 are collectively referred to as a baseband unit 125. The central unit 130 processes non-real-time protocols and services, and the distributed unit 140 processes physical layer protocols and delay-critical real-time services. The radio frequency unit performs link layer and physical layer signal processing when sending and receiving wireless signals. The connection between the various radio frequency units (155, 165) and the distributed unit 140 is based on a protocol stack based on Ethernet, and focuses on various aspects related to the radio frequency unit, such as antenna data, beamforming control, management, and synchronization. Examples of such protocol stacks include Open Radio Access Network (O-RAN) using enhanced Common Public Radio Interface (eCPRI) or IEEE1914.3 (IEEE: Institute of Electrical and Electronics Engineers) (Wireless Communication over Ethernet (RoE)) as the antenna data transport layer, and using optional User Datagram Protocol (UDP) over IPv4 or IPv6 as a routable transport layer, etc.

In one example, the base station 120 can be part of a radio access network of a wireless communication system (e.g., a cellular communication system). The wireless communication system can operate according to the specific requirements of a general mobile communication system or any of its evolutionary versions, such as Long Term Evolution (LTE) or Long Term Evolution-Advanced (TLE-Advanced), a second generation mobile communication system (e.g., Global System for Mobile Communications), or a system operating strictly on an unlicensed frequency band. An example of a system operating on an unlicensed frequency band is IEEE 802.11 (IEEE: Institute of Electrical and Electronics Engineers) (Wi-Fi), and therefore, a base station can be broadly viewed as an access point that provides wireless access to other networks such as the Internet to terminal devices.

The system 100 includes a test device 110 for testing and simulating various operations between components of a base station 120. The test device 110 is connected to one or more interfaces of the base station 120 to test one or more features or performances of the base station 120. Examples of interfaces include an interface between a baseband unit 125 and a radio frequency unit (155, 165), an interface between the baseband unit 125 and a core network, etc. The base station 120 can include a physical connector to which the test device 110 can be connected to test the operation and performance of the base station. Such physical connectors can include a Neil-Conseman bayonet (BNC) connector, an optical connector such as a fiber optic connector (LC), an SMA connector, an RJ45 connector, a miniaturized (SFP or SFP+) connector, a quad SFP(+) connector, etc.

In one example, the test equipment 110 can include a network interface that connects the test equipment 110 to a communication network (not shown in FIG. 1 ). The communication network can include a local area network (LAN), a wide area network (WAN), and/or the Internet. The network interface can enable remote control of the test equipment, connection to a remote database storing test programs and/or test results, and/or mutual communication between two or more remote test equipment. A user interface device such as a personal computer or a notebook computer can be connected to the communication network and configured to control the test of the base station.

The test device 110 is configured to generate a plurality of data packets to be transmitted between various components of the base station 120. To generate the data packets, the test device 110 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, and the simulation module of the test device 110 generates the data packets according to these parameters. In one example, the configuration module includes a graphical user interface for receiving a plurality of values of the plurality of parameters of the test case configuration. These aspects related to the test case configuration are further explained using the exemplary test case configuration shown in FIG.

FIG. 2 is a test case configuration 200 (also referred to as a first test case configuration 200) for testing the base station 120. In one example, the first test case configuration 200 is generated by a configuration module based on one or more user inputs. The first test case configuration 200 includes a first protocol stack associated with a first data stream (also referred to as data stream 1 in FIG. 2). The simulation module uses the first protocol stack defined in the configuration 200 to generate a data packet associated with the first data stream. For example, a header of a data packet belonging to the first data stream is generated according to the first protocol stack associated with the first data stream.

The first protocol stack includes multiple concurrently running protocols for processing protocol data units (e.g., datagrams, data frames, data packets, etc.) according to the specifications of each protocol of the protocol stack. Each protocol in the protocol stack is associated with a layer of an interconnection suite (similar to the layers of the Open Systems Interconnection Communication Reference Model (OSI) or the Transmission Control Protocol/Internet Protocol (TCP/IP) interconnection model). Each protocol is stacked on top of the previous protocol in the protocol stack. This means that the received data unit is first processed by the previous protocol and then by the subsequent protocol. Similarly, the data unit to be transmitted is first processed by the subsequent protocol and then by the previous protocol. An example of the first protocol stack is shown in Figure 3.

FIG3 is a first protocol stack 300 (shown in the figure). The first protocol stack 300 includes six protocols stacked on each other to form the protocol stack 300. The first layer of the protocol stack 300 is based on the Ethernet protocol (as shown in protocol block 370). The second layer of the protocol stack 300 is based on the Ethernet protocol (as shown in protocol block 360). The third layer of the protocol stack 300 is based on the Internet Protocol (IP) (as shown in protocol block 350). The fourth layer of the protocol stack 300 is based on the User Datagram Protocol (UDP) (as shown in protocol block 340). The fifth layer of the protocol stack 300 is based on the Enhanced Common Public Radio Interface (eCPRI) (shown as protocol block 325) and the Open Radio Access Network Control Plane/User Plane (O-RAN C/U plane) specification (shown as protocol block 335). Finally, the sixth layer of the first protocol stack 300 is based on the fifth generation mobile communication technology (5G) new air interface specification (as shown in protocol block 310).

The protocols and related protocol parameters of the first protocol stack 300 are defined by the test case configuration 200. Specifically, each set of protocol parameters associated with the corresponding protocol is located in a separate namespace that is different from other protocol parameter groups (protocol parameter groups associated with other protocols of the protocol stack 300). The namespace here refers to a logical area that accommodates multiple parameter names, so that two parameters with the same parameter name can coexist in two separate namespaces without conflict. In other words, each namespace provides a logical environment in which these parameters can exist in a form that does not overwrite parameters in other namespaces. In one instance, each namespace associated with the corresponding protocol is specified as a token in the parameter name of each protocol parameter associated with the corresponding protocol.

For example, as shown in FIG2 , parameters associated with the IP protocol on layer 3 (i.e., protocol block 350) are defined in code segment 220 of test case configuration 200. Protocol parameters associated with the IP protocol (e.g., source IP address, destination IP address, etc.) are located in a first namespace associated with the IP protocol (IPv4 in the current example). Therefore, each protocol parameter name contains an "IPv4" token in its name to indicate the first namespace associated with the IPv4 protocol.

Similarly, parameters associated with the User Datagram Protocol (UDP) on Layer 4 (i.e., protocol block 340) are defined in code segment 230 of the test case configuration 200. Protocol parameters associated with the User Datagram Protocol (UDP), such as source User Datagram Protocol (UDP) port, destination User Datagram Protocol (UDP) port, etc., are located in a second namespace associated with the User Datagram Protocol (UDP). Therefore, each protocol parameter name contains a "User Datagram Protocol (UDP)" token in its name to indicate the second namespace associated with the User Datagram Protocol (UDP).

Therefore, this allows two parameters with the same name to exist in two independent namespaces without conflict. For example, a parameter indicating the version of the IP protocol can have the parameter name "version" at the same time as a parameter indicating the version of the User Datagram Protocol (UDP) without any conflict. This is possible because the parameter name of the parameter indicating the version of the IP protocol includes the namespace token "IPv4" (i.e., stream1.IPv4.version), and similarly, the parameter name of the parameter indicating the version of the User Datagram Protocol (UDP) includes the namespace token "User Datagram Protocol (UDP)" (i.e., stream1.UDP.version).

Similarly, parameters associated with the enhanced common public radio interface (eCPRI) protocol on layer 5 (i.e., protocol block 325) are defined in code segment 240 of the test case configuration 200. Protocol parameters associated with the enhanced common public radio interface (eCPRI) protocol (e.g., type, real-time clock ID (RTC_ID), etc.) are located in a third namespace associated with the enhanced common public radio interface (eCPRI) protocol. Therefore, each protocol parameter name includes an "enhanced common public radio interface (eCPRI)" token in its name to indicate the third namespace associated with the enhanced common public radio interface (eCPRI) protocol. Similarly, parameters associated with the open radio access network new air interface (O-RAN NR) protocol on layer 6 (i.e., protocol block 310) are defined in code segment 250 of the test case configuration 200. Protocol parameters associated with the Open Radio Access Network New Air (O-RAN NR) protocol, such as data direction, payload version, etc., are located in a fourth namespace associated with the Open Radio Access Network New Air (O-RAN NR) protocol. Therefore, each protocol parameter name includes an "Open Radio Access Network (ORAN)" token in its name to indicate the fourth namespace associated with the Open Radio Access Network New Air (O-RAN NR) protocol. Similarly, parameters associated with the Ethernet protocol on layer 2 (i.e., protocol block 360) are defined in code segment 210 of the test case configuration 200. Protocol parameters associated with the Ethernet protocol, such as type, source address, etc., are located in a fourth namespace associated with the Ethernet protocol.

In addition, in one example, at least one parameter from the first set of protocol parameters associated with the first protocol includes a value indicating a second protocol. In one example, the second protocol is a layer in the first protocol stack that follows the first protocol. For example, as shown in FIG. 2 , the Ethernet protocol (protocol block 360) includes a parameter “Ethertype”, as shown in line 215, which includes a value indicating a next protocol “IPv4”. Similarly, the IP protocol (protocol block 350) includes a parameter “Protocol”, as shown in line 225, which includes a value indicating a next protocol “User Datagram Protocol (UDP)”. Similarly, the User Datagram Protocol (UDP) (protocol block 340) includes a parameter “Next Header”, as shown in line 235, which includes a value indicating a next protocol “Enhanced Common Public Radio Interface (eCPRI)”. By referencing a subsequent protocol in a parameter set of the first protocol, the configuration module is configured to set a subsequent namespace of the subsequent protocol.

The simulation module of the test device 110 simulates one or more operations between the radio frequency unit (155, 165) and the baseband unit (125) using the first test case configuration 200. In one example, the one or more operations include simulating the transmission and reception of data packets relative to the base station 120. In this regard, the simulation module generates a plurality of data packets according to the first data flow defined in the first test case configuration 200. A plurality of data flow attributes can be defined relative to the first data flow in the first test case configuration 200. Some examples of data flow attributes include data flow direction (indicating whether the data packet flow is in the uplink direction, i.e., from the user terminal (UE) upward to the core network, or in the downlink direction, i.e., from the core network downward to the user terminal (UE)), data flow type, data flow priority, data packet type, etc. Examples of data flow types include control plane downlink (CP_DL), control plane uplink (CP_UL), user plane data language (UP_DL), and user plane uplink (UP_UL) flows for transmitting antenna data between an open distributed unit (O-DU) and an open radio access network radio unit (O-RU).

Accordingly, the packet type, format and header are based on the first protocol stack 300. For example, as shown in FIG4, according to the protocol stack 300, each packet of the first data stream has a packet header format 400. Therefore, the packet header format 400 includes an Ethernet header, and the Ethernet header includes multiple parts (e.g., a destination address part 410, a source address part 420, and an Ethernet type part 430). The Ethernet header is associated with the Ethernet protocol (i.e., the protocol block 360). Similarly, the packet header format 400 includes an Internet Protocol-User Datagram Protocol (IP-UDP) header (shown as IP-UDP parts 440-450). The Internet Protocol-User Datagram Protocol (IP-UDP) header is associated with the Internet Protocol (IP) and the User Datagram Protocol (UDP) of the first protocol stack 300 (i.e., protocol blocks 350 and 340). Similarly, the packet header format 400 includes an enhanced common public radio interface (eCPRI) header (as shown in part 460). The enhanced common public radio interface (eCPRI) header is associated with the enhanced common public radio interface (eCPRI) protocol of the first protocol stack 300 (i.e., protocol block 325). Similarly, the data packet header format 400 includes an open radio access network (O-RAN) header (as shown in portion 470). The open radio access network (O-RAN) header is associated with the open radio access network fifth generation mobile communication technology new air interface (O-RAN 5G NR) protocol of the first protocol stack 300 (i.e., protocol block 310).

Although the first test case configuration 200 is explained using the first protocol stack 300 associated with the first data stream, in one example, the first test case configuration 200 includes multiple data streams and multiple corresponding protocol stacks. Accordingly, the first test case configuration 200 can include a second data stream and a second protocol stack. The second protocol stack can include the same number of layers as the first protocol stack, while having a different protocol from the first protocol stack 300. For example, the second protocol stack can include the Transmission Control Protocol (TCP) (also referred to as the third protocol) in the fourth layer to replace the User Datagram Protocol (UDP) in the fourth layer. Similarly, the second protocol stack can include IPv6 (also referred to as the fourth protocol) in the third layer to replace the IPv4 protocol in the third layer.

FIG5 is a method 500 for testing a base station 110. The method 500 is implemented by a test device 110. The method 500 includes generating (as shown in FIG5 as step 510) performed by a configuration module of the device 110, and a first test case configuration 200 associated with one or more radio frequency units (155, 165) and a baseband unit 125. As previously described, the first test case configuration 200 includes a first protocol stack 300. The first protocol stack 300 includes two or more protocols, including a first protocol associated with a first layer (e.g., protocol block 325) and a second protocol associated with a second layer (e.g., protocol block 310). In one example, the configuration module includes a graphical user interface (GUI) for receiving a plurality of values related to a first set of protocol parameters and a second set of protocol parameters, the first set of protocol parameters and the second set of protocol parameters being associated with the first protocol and the second protocol.

Then, in step 520, the simulation module of the device 110 simulates one or more operations between the one or more radio frequency units and the baseband unit. To simulate the one or more operations, the simulation module generates one or more data packets based on the first test case configuration. In one example, each of the one or more data packets of the first data stream includes a data packet header based on the first protocol stack 300. In addition, as previously described, the first set of protocol parameters associated with the first protocol 325 is located in the first namespace 240, and similarly, the second set of protocol parameters associated with the second protocol 310 is located in the second namespace 250, and the second namespace 250 is different from the first namespace 240.

The present invention can take the form of a computer program product, which includes program modules that can be accessed from a computer-usable or computer-readable medium storing program code for use by or in conjunction with one or more computers, processing units, or instruction execution systems. For example, a configuration module can be implemented across one or more devices.

Accordingly, the present invention describes an exemplary test device 600. The test device 600 includes an input/output (I/O) module 640, one or more processors 630, and a non-transitory storage medium 670. The non-transitory storage medium 670 contains a plurality of instructions 660 for testing a base station 120. In one example, the configuration module 610 and the simulation module 620 are implemented by the one or more processors 630. When executing the instructions 660, the one or more processors generate a first test case configuration associated with one or more radio frequency units and a baseband unit, wherein the first test case configuration includes a first protocol stack, the first protocol stack including 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 frequency units and the baseband unit, wherein simulating the one or more operations includes generating one or more data packets based on the first test case configuration, each data packet from the one or more data packets including a data packet header based on the first protocol stack; wherein a first set of protocol parameters associated with the first protocol is located in a first namespace, and wherein a second set of protocol parameters associated with the second protocol is located in a second namespace, the second namespace being different from the first namespace.

Although the present invention describes the test device 600 as a standalone component or device, the test device 600 can be a software component and can be implemented within the base station 120 or any other management device in the network. Similarly, in one example, one or more components of the base station 120 can be actual physical components or logical simulations simulated using the test device 110 or any other test/simulation device connected to the test device 110. For example, one or more radio frequency units (155, 165) can be simulated on another test device connected to the baseband unit 125 and the test device 110.

In one example, the non-transitory storage medium 670 includes a configuration repository 650. The configuration repository 670 (also referred to as a test case configuration repository 650) includes one or more test case configurations generated by the configuration module 610. The one or more test case configurations include the first test case configuration 200. A tester can use the simulation module 620 to select a test case configuration from the test case configurations to be tested to test the base station 120.

For purposes of this description, a computer-usable or computer-readable non-transitory storage medium can be any device that can contain, store, communicate, propagate, or transmit a program for use by or in association with an instruction execution system, device, or apparatus. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or device or apparatus), or a propagation medium that itself acts as a signal carrier, which propagation medium is not included in the definition of physical computer-readable media, which includes semiconductor or solid-state memory, magnetic tape, removable computer diskette, random access memory (RAM), read-only memory (ROM), hard disk, and optical disks, such as compact disk read-only memory (CD-ROM), compact disk read/write, and digital versatile disk (DVD). As known to those skilled in the art, the processing units and program codes used to implement each feature of the technology can be centralized or decentralized (or a combination of both).

In view of the present invention, as described herein, many modifications and variations will be made by those skilled in the art without departing from the scope of the various embodiments of the present invention. Therefore, the scope of the present invention is indicated by the claims rather than the foregoing description. All changes, modifications and variations within the equivalent meaning and range of the claims should be considered within their scope. All advantageous embodiments claimed in the method claims can also be applied to the device/non-transitory storage medium claims.

Claims (11)

1. A device (110) for testing a base station, the base station comprising one or more radio frequency units (155, 165) and a baseband unit (125) connectable to the one or more radio frequency units (155, 165), the device (110) comprising: a. a configuration module (610), the configuration module being configured to generate a first test case configuration (200) associated with the one or more radio frequency units (155, 165) and the baseband unit (125), wherein the first test case configuration (200) comprises a first protocol stack (300), the first protocol stack comprising a first protocol (325) associated with a first layer and a second protocol (310) associated with a second layer; The device (110) is characterized in that a first set of protocol parameters associated with the first protocol (325) is located in a first namespace (240), and wherein a second set of protocol parameters associated with the second protocol (310) is located in a second namespace (250), the second namespace (250) being different from the first namespace (240), wherein at least one parameter (245) of the first set of protocol parameters associated with the first protocol (325) comprises a value indicative of the second protocol (310) and wherein the second protocol (310) succeeds the first protocol (325) in the first protocol stack (300). 2. The device (110) of claim 1, wherein the name of each parameter from the first set of protocol parameters is based on the first protocol (325) and the name of each parameter from the second set of protocol parameters is based on the second protocol (310). 3. The device (110) according to claim 1, wherein the device (110) further comprises a simulation module (620), wherein the simulation module is used to simulate one or more operations between the one or more radio frequency units (155, 165) and the baseband unit (125) according to the first test case configuration (200). 4. The apparatus (110) of claim 1, wherein the first test case configuration (200) comprises a second protocol stack associated with a second data flow, the second protocol stack comprising a third protocol associated with the first layer and a fourth protocol associated with the second layer. 5. The device (110) of claim 1, wherein the configuration module (610) comprises a graphical user interface (GUI) for receiving a plurality of values associated with the first set of protocol parameters and the second set of protocol parameters, the first set of protocol parameters and the second set of protocol parameters being associated with the first protocol and the second protocol (325, 310). 6. The device (110) of claim 1, wherein the name of each parameter from the first set of protocol parameters includes a namespace token associated with the first protocol (325). 7. The device (110) of claim 3, wherein the first protocol stack (300) is associated with a first data flow, wherein the simulation module (620) is configured to generate a plurality of data packets based on the first data flow, each data packet from the plurality of data packets including a data packet header (400) based on the first protocol stack (300). 8. A method (500) for testing a base station, the base station comprising one or more radio frequency units (155, 165) and a baseband unit (125) connectable to the one or more radio frequency units (155, 165), the method (500) comprising: a. generating (510) a first test case configuration (200) associated with the one or more radio frequency units (155, 165) and the baseband unit (125), wherein the first test case configuration (200) comprises a first protocol stack (300), the first protocol stack comprising a first protocol (325) associated with a first layer and a second protocol (310) associated with a second layer; and b. simulating (520) one or more operations between the one or more radio frequency units (155, 165) and the baseband unit (125), wherein simulating the one or more operations comprises generating one or more data packets based on the first test case configuration (200), each data packet from the one or more data packets comprising a data packet header (400) based on the first protocol stack (300); wherein a first set of protocol parameters associated with the first protocol (325) is located in a first namespace (240), and wherein a second set of protocol parameters associated with the second protocol (310) is located in a second namespace (250), the second namespace (250) being different from the first namespace (240), at least one parameter (245) of the first set of protocol parameters associated with the first protocol (325) comprising a value indicative of the second protocol (310) and wherein the second protocol (310) succeeds the first protocol (325) in the first protocol stack (300). 9. The method (500) of claim 8, wherein generating (510) the first test case configuration (200) comprises receiving, using a graphical user interface (GUI), a plurality of values associated with the first set of protocol parameters and a second set of protocol parameters, the first set of protocol parameters and the second set of protocol parameters being associated with the first protocol and the second protocol. 10. A test case configuration repository (650) according to any one of the preceding claims, the test case configuration repository (650) comprising one or more test case configurations, the one or more test case configurations including the first test case configuration (200). 11. A non-transitory storage medium (670) for testing a base station, the base station comprising one or more radio frequency units (155, 165) and a baseband unit (125) connectable to the one or more radio frequency units (155, 165), the non-transitory storage medium (670) storing machine-readable instructions (660), which, when executed by one or more processors (630), cause the one or more processors (630): a. generating a first test case configuration (200) associated with the one or more radio frequency units (155, 165) and the baseband unit (125), wherein the first test case configuration (200) comprises a first protocol stack (300), the first protocol stack comprising a first protocol (325) associated with a first layer and a second protocol (310) associated with a second layer; and b. simulating one or more operations between the one or more radio frequency units (155, 165) and the baseband unit (125), wherein simulating the one or more operations comprises generating one or more data packets based on the first test case configuration (200), each data packet from the one or more data packets comprising a data packet header based on the first protocol stack (300); wherein a first set of protocol parameters associated with the first protocol (325) is located in a first namespace (240), and wherein a second set of protocol parameters associated with the second protocol (310) is located in a second namespace (250), the second namespace (250) being different from the first namespace (240), at least one parameter (245) of the first set of protocol parameters associated with the first protocol (325) comprising a value indicative of the second protocol (310) and wherein the second protocol (310) succeeds the first protocol (325) in the first protocol stack (300).