Patent Application
20250008355
During or after construction of a cell site, a general contractor, or others including the field operator, installer, vendor, etc. is typically dispatched to test the newly constructed cell site installations in the field to ensure proper functionality of the cell site radio operations.
Prior to the actual commissioning of the cell site, a set of validation tests is typically used to validate transmits in the cell sector covered by the cell sites in advance of the actual commissioning of the cell site to forecast or to prevent any obstacles that may occur in advance of the actual commissioning of the cell site. This can give the general contractor added assurances about the expected reliability to put into operation a particular cell site.
It can be difficult, however, to perform a set of validations and tests of radio operations associated with a post constructed cell site at about the time of the post-construction for use by the general contractor and others to generate data and assess in advance the reliability of the constructed cell site and to ensure appropriate standards and operability are or will be met.
A computing platform is configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the computing platform to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions. One general aspect includes the computing platform configured as a distributed unit (DU) emulator to perform one or more tests during or after construction of a cell site. The tests may include but are not limited to voltage standing wave ratio (VSWR) tests, passive inter modulation (PIM) tests, cable tests, RU tests, CSR tests, small form-factor pluggable (SFP) tests, physical cell identifier (PCI) tests, and the like.
In some embodiments, the DU emulator is configured to establish a connection with a cell site router (CSR) of the cell site. In those embodiments, the DU emulator configures the CSR for the one or more tests. A connection with a Radio Unit (RU) through the CSR is then established. The the DU emulator also establishes, through the RU, a connection with an antenna connected to the RU. The DU emulator may determine information about connections, RUs, and/or other components using the connection to the CSR.
In some configurations, the the DU emulator performs tests to determine whether the RU and connected antennas function correctly, whether connections are properly made, and the like. According to some examples, the DU emulator generates a test result regarding the different tests that are performed. The test results can be used to address detected problems and/or view information about components involved in the tests.
A further understanding of the nature and advantages of various embodiments may be realized by reference to the following figures. In the appended figures, similar components or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.
The following detailed description is intended to provide several examples that will illustrate the broader concepts that are set forth herein, but it is not intended to limit the invention or the application and uses of the invention. Furthermore, there is no intention to be bound by any theory presented in the preceding background or the following detailed description.
Wireless mobile communication technology uses various standards and protocols to transmit data between a base transceiver station (BTS) and a wireless mobile device. The deployment of many small cells presents a need to validate radio operations at the post construction of the cell site to forecast obstacles and ensure reliability by the general contractor prior to commissioning the cell site.
In 3GPP radio access networks (RANs) in LTE systems, the BTS can be a combination of evolved Node Bs (also commonly denoted as enhanced Node Bs, eNodeBs, or eNBs) and Radio Network Controllers (RNCs) in a Universal Terrestrial Radio Access Network (UTRAN), which communicates with the wireless mobile device, known as user equipment (UE). A downlink (DL) transmission can be a communication from the BTS (or eNodeB) to the wireless mobile device (or UE), and an uplink (UL) transmission can be a communication from the wireless mobile device to the BTS.
During and/or after installation of a cell site, various tests are typically performed to ensure physical components in the cell site are properly installed, and connectivity is provided by the cell site as intended. Installation of a cell site typically involves setting up new radios, antenna, connecting various types of cables, connecting power to the cell site, and/or any other events.
Challenges typically arise during cell site testing when the testing is not performed efficiently, or correct testing procedures are not followed. It thus is desired to have cell site testing procedure standardized via software tools such that a set of validation tests are performed in a preset sequence to ensure the cell site is properly tested. Described herein are techniques to use a DU emulator to perform cell site testing.
UE 110 can represent various types of end-user devices, such as smartphones, cellular modems, cellular-enabled computerized devices, sensor devices, gaming devices, access points (APs), any computerized device capable of communicating via a cellular network, etc. Depending on the location of individual UEs, UE 110 may use RF to communicate with various base stations of cellular network 120. As illustrated, two base stations 115 (BS 115-1, 115-2) are illustrated. Real-world implementations of system 100 can include many (e.g., thousands) of base stations, RUs, DUs, and CUs. BS 115 can include one or more antennas that allow RUs 125 to communicate wirelessly with UEs 110. RUs 125 can represent an edge of cellular network 120 where data is transitioned to wireless communication. The radio access technology (RAT) used by RU 125 may be 5G New Radio (NR), or some other RAT. The remainder of cellular network 120 may be based on an exclusive 5G architecture, a hybrid 4G/5G architecture, a 4G architecture, or some other cellular network architecture. Base station equipment 121, may include an RU (e.g., RU 125-1) and a DU (e.g., DU 222).
One or more RUs, such as RU 125-1, may communicate with DU 222. As an example, at a possible cell site, three RUs may be present, each connected with the same DU. Different RUs may be present for different portions of the spectrum. For instance, a first RU may operate on the spectrum in the citizens broadcast radio service (CBRS) band while a second RU may operate on a separate portion of spectrum, such as, for example, band 71. One or more DUs, such as DU 222, may communicate with CU 129. Collectively, RUs, DUs, and CUs create a gNodeB, which serves as the radio access network (RAN) of cellular network 120. CU 129 can communicate with 5G core 139. The specific architecture of cellular network 120 can vary by embodiment. Edge cloud server systems outside of cellular network 120 may communicate, either directly, via the Internet, or via some other network, with components of cellular network 120. For example, DU 222 may be able to communicate with an edge cloud server system without routing data through CU 129 or 5G core 139. Other DUs may or may not have this capability.
Further detail regarding 5G Core 139 is provided in relation to
Network resource management components 150 can include: Network Repository Function (NRF) 152 and Network Slice Selection Function (NSSF) 154. NRF 152 can allow 5G network functions (NFs) to register and discover each other via a standards-based application programming interface (API). NSSF 154 can be used by AMF 182 to assist with the selection of a network slice that will serve a particular UE.
Policy management components 160 can include: Charging Function (CHF) 162 and Policy Control Function (PCF) 164. CHF 162 allows charging services to be offered to authorized network functions. A converged online and offline charging can be supported. PCF 164 allows for policy control functions and the related 5G signaling interfaces to be supported.
Subscriber management components 170 can include: Unified Data Management (UDM) 172 and Authentication Server Function (AUSF) 174. UDM 172 can allow for generation of authentication vectors, user identification handling, NF registration management, and retrieval of UE individual subscription data for slice selection. AUSF 174 performs authentication with UE.
Packet control components 180 can include: Access and Mobility Management Function (AMF) 182 and Session Management Function (SMF) 184. AMF 182 can receive connection and session related information from UE and is responsible for handling connection and mobility management tasks. SMF 184 is responsible for interacting with the decoupled data plane, creating updating and removing Protocol Data Unit (PDU) sessions, and managing session context with the User Plane Function (UPF).
User plane function (UPF) 190 can be responsible for packet routing and forwarding, packet inspection, QoS handling, and external PDU sessions for interconnecting with a Data Network (DN) 195 (e.g., the Internet) or various access networks 197. Access networks 197 can include the RAN of cellular network 120 of
While
In a possible O-RAN implementation, DUs 127, CU 129, 5G core 139, orchestrator 138, can be implemented virtually as software being executed by general-purpose computing equipment, such as in a data center. Therefore, depending on needs, the functionality of a DU, CU, and/or 5G core may be implemented locally to each other and/or specific functions of any given component can be performed by physically separated server systems (e.g., at different server farms). For example, some functions of a CU may be located at a same server facility as where the DU is executed, while other functions are executed at a separate server system. In the illustrated embodiment of system 100, cloud-based cellular network components 128 include CU 129, 5G core 139, and orchestrator 138. In some embodiments, DUs 127 may be partially or fully added to cloud-based cellular network components 128. Such cloud-based cellular network components 128 may be executed as specialized software executed by underlying general-purpose computer servers. Cloud-based cellular network components 128 may be executed on a third-party cloud-based computing platform. For instance, a separate entity that provides a cloud-based computing platform may have the ability to devote additional hardware resources to cloud-based cellular network components 128 or implement additional instances of such components when requested.
Kubernetes, or some other container orchestration platform, can be used to create and destroy the logical DU, CU, 5G core units and subunits as needed for the cellular network 120 to function properly. Kubernetes allows for container deployment, scaling, and management. As an example, if cellular traffic increases substantially in a region, an additional logical DU or components of a DU may be deployed in a data center near where the traffic is occurring without any new hardware being deployed. (Rather, processing and storage capabilities of the data center would be devoted to the needed functions.) When the need for the logical DU or subcomponents of the DU is no longer needed, Kubernetes can allow for removal of the logical DU. Kubernetes can also be used to control the flow of data (e.g., messages) and inject a flow of data to various components. This arrangement can allow for the modification of nominal behavior of various layers.
The deployment, scaling, and management of such virtualized components can be managed by orchestrator 138. Orchestrator 138 can represent various software processes executed by underlying computer hardware. Orchestrator 138 can monitor cellular network 120 and determine the amount and location at which cellular network functions should be deployed to meet or attempt to meet service level agreements (SLAs) across slices of the cellular network.
Orchestrator 138 can allow for the instantiation of new cloud-based components of cellular network 120, including components of terminating service provider system 230 detailed in relation to
A network slice functions as a virtual network operating on cellular network 120. Cellular network 120 is shared with some number of other network slices, such as hundreds or thousands of network slices. Communication bandwidth and computing resources of the underlying physical network can be reserved for individual network slices, thus allowing the individual network slices to reliably meet particular SLA levels and parameters. By controlling the location and amount of computing and communication resources allocated to a network slice, the SLA attributes for UE on the network slice can be varied on different slices. A network slice can be configured to provide sufficient resources for a particular application to be properly executed and delivered (e.g., gaming services, video services, voice services, location services, sensor reporting services, data services, etc.). However, resources are not infinite, so allocation of an excess of resources to a particular UE group and/or application may be desired to be avoided. Further, a cost may be attached to cellular slices: the greater the amount of resources dedicated, the greater the cost to the user; thus optimization between performance and cost is desirable.
Particular network slices may only be reserved in particular geographic regions. For instance, a first set of network slices may be present at RU 125-1 and DU 222, a second set of network slices, which may only partially overlap or may be wholly different than the first set, may be reserved at RU 125-2 and DU 127-2.
Further, particular cellular network slices may include some number of defined layers. Each layer within a network slice may be used to define QoS parameters and other network configurations for particular types of data. For instance, high-priority data sent by a UE may be mapped to a layer having relatively higher QoS parameters and network configurations than lower-priority data sent by the UE that is mapped to a second layer having relatively less stringent QoS parameters and different network configurations.
Components such as DUs 127, CU 129, orchestrator 138, and 5G core 139 may include various software components that are required to communicate with each other, handle large volumes of data traffic, and be able to properly respond to changes in the network. In order to ensure not only the functionality and interoperability of such components, but also the ability to respond to changing network conditions and the ability to meet or perform above vendor specifications, significant testing must be performed.
The methods, systems, and devices discussed above are examples. Various configurations may omit, substitute, or add various procedures or components as appropriate. For instance, in alternative configurations, the methods may be performed in an order different from that described, and/or various stages may be added, omitted, and/or combined. Also, features described with respect to certain configurations may be combined in various other configurations. Different aspects and elements of the configurations may be combined in a similar manner. Also, technology evolves and, thus, many of the elements are examples and do not limit the scope of the disclosure or claims.
Specific details are given in the description to provide a thorough understanding of example configurations (including implementations). However, configurations may be practiced without these specific details. For example, well-known circuits, processes, algorithms, structures, and techniques have been shown without unnecessary detail in order to avoid obscuring the configurations. This description provides example configurations only, and does not limit the scope, applicability, or configurations of the claims. Rather, the preceding description of the configurations will provide those skilled in the art with an enabling description for implementing described techniques. Various changes may be made in the function and arrangement of elements without departing from the spirit or scope of the disclosure.
Also, configurations may be described as a process which is depicted as a flow diagram or block diagram. Although each may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be rearranged. A process may have additional steps not included in the figure. Furthermore, examples of the methods may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments to perform the necessary tasks may be stored in a non-transitory computer-readable medium such as a storage medium. Processors may perform the described tasks.
Having described several example configurations, various modifications, alternative constructions, and equivalents may be used without departing from the spirit of the disclosure. For example, the above elements may be components of a larger system, wherein other rules may take precedence over or otherwise modify the application of the invention. Also, a number of steps may be undertaken before, during, or after the above elements are considered.
When base stations are being added to a cellular network, a significant amount of installation work needs to be performed on-site. A structure may need to be erected, possibly upon a cement pad poured to support the structure. One or more directional antennas may need to be installed upon the structure. The directional antennas may then need to be connected to corresponding RUs. These RUs may need to be powered and connected to a routing system. The routing system may need to be properly connected with a computing system housed at the base station. Further, the routing system may need to be connected with a network transport connection, which allows other components of the cellular network (e.g., the core, a CU) to communicate with the routing system and connected components.
During installation, the network transport connection may oftentimes be made last. In some situations, days, weeks, or even months may pass between when the other components of the base station are installed and when the network transport connection is activated. Common problems at new cellular installations include connections between RUs and a routing system or connections between antennas and an RU are made incorrectly or are reversed. Such testing as detailed herein can allow for such misconnections to be quickly identified. Therefore, if testing of the base station is to be performed via the network transport connection, such testing may be significantly delayed since the network transport connection may not be established for months after the installation of the antennas and the RUs.
This delay may cause substantial problems if changes are needed to correct problems at the cell site. For instance, the installation crew may no longer be nearby to implement such changes. Requiring the installation crew to return to the cell site may need to be scheduled many days or weeks later, further delaying activation of the base station. In order to enable testing prior to the network transport connection 240 being activated, a DU emulator, such as DU emulator 250, can be used. In some examples, the DU emulator is configured to perform operations associated with a DU before a DU is installed and connected to a CU at the core network.
In some embodiments, a given cabinet structure 235 is built to elevate one or more antennas, such as directional antennas 232. In other embodiments, an existing structure may be used, such as a building, radio tower, bridge, etc. Whether purpose-built or existing, multiple pairs of RUs and directional antennas may be attached with the given cabinet structure 235. Each directional antenna may need to be aimed and connected with a corresponding RU.
The RUs may be connected with routing system 210. The term “routing system” and “cell site router (CSR)” may be used interchangeably herein. Routing system 210 can serve to route data between network transport 240, on-site computing platform 220; and the installed RUs, such as RU 125-1. Network transport 240 is not yet activated and, therefore, communication between the cellular network and routing system 210 is not yet possible. At some point in the future, network transport 240 is activated, thus connecting routing system 210 with the cellular network.
On-site computing platform 220 can represent general-purpose computing hardware. At some point in the future, such as following network transport 240 being activated, specialized software that is executed by on-site computing platform 220 and functions as DU 222 may be loaded and executed. However, at the time of testing, such specialized software may not be available, such as because network transport 240 is not yet available.
Therefore, at a time of testing, cabinet structure 235 may be built, RUs may be installed and connected with directional antennas 232 and routing system 210, and routing system 210 may be connected with on-site computing platforms 220, but DU software 222 is not yet installed on on-site computing platform 222A.
DU emulator 250 can represent specialized software installed on general purpose hardware, such as on-site computing platform 220B, that can be temporarily physically connected directly with routing system 210. For example, DU emulator 250 may be plugged via cable into routing system 210. In other embodiments, a direct wireless communication connection can be established between DU emulator 250 and routing system 210.
DU emulator 250 installed on on-site computing platform 220B can emulate functions of DU 222 to allow for the directional antennas, RUs, routing system 210, cabling, and aspects of on-site computing platform 220 to be tested. DU emulator 250 can test communication via each directional antenna with a UE. Since each RU transmits a different physical cell identifier (PCI), communication between a UE and DU emulator 250 via routing system 210, an RU, and a directional antenna can be used to test parameters such as: voltage standing wave ratio (VSWR); passive intermodulation (PIM); receiver sensitivity; antenna down tilt; and fiber signal strength with each RU. More details are provided below with regard to other figures, such as
While the software for DU 222 may not yet be installed, DU emulator 250 can ensure that communication with on-site computing platform 220 is available and can occur at an acceptable speed with less than a maximum amount of error. Such testing can at least ensure that on-site computing platform 220 is physically connected properly with routing system 210 and is powered.
DU emulator 250 may generate a report or certificate that indicates test results and/or whether all tests have been passed. If a failure is present, DU emulator 250 outputs an indication of the failed test and the components involved in the failed test, thus allowing the failure to be diagnosed. Once testing is complete, DU emulator 250 may be disconnected and used to test other base station installations that have yet to be connected with network transport 240. When testing is complete, the network transport can be expected to still not have been activated yet.
In the illustrated embodiment of system 200, the cellular network is a 5G New Radio (NR) cellular network; however, in other embodiments, the cellular network may be some other generation or type of cellular network (e.g., 4G Long Term Evolution (LTE), 6G, etc.). As shown in this example, there can be multiple cabinet structures 235 in the cell site 200.
In some embodiments, a given cabinet structure 235 is built to elevate one or more antennas, such as directional antenna(s) 232. In other embodiments, an existing structure may be used, such as a building, radio tower, bridge, etc. Whether purpose-built or existing, multiple pairs of RUs and directional antennas may be attached with the given cabinet structure 235. Each directional antenna may need to be aimed and connected with a corresponding RU.
The RUs 125 may be connected with routing system 210. Routing system 210 can serve to route data between network transport 240, on-site computing platform 220B that includes DU emulator 250; and the installed RUs, such as RU 125-1-RU 125-N. In some examples, network transport 240 is not yet activated and, therefore, communication between the cellular network and routing system 210 is not yet possible. At some point in the future, network transport 240 is activated, thus connecting routing system 210 with the cellular network. In some configurations, on-site computing platform 220B can represent general-purpose computing hardware.
In some examples, at a time of testing, cabinet structure 235 may be built, RUs may be installed and connected with directional antennas 232 and routing system 210, and routing system 210 may be connected with on-site computing platform 220B.
As briefly discussed above, DU emulator 250 can represent specialized software installed on general purpose hardware, such as on-site computing platform 220B, that can be temporarily physically connected directly with routing system 210. For example, DU emulator 250 may be plugged via cable into routing system 210. In other embodiments, a direct wireless communication connection can be established between DU emulator 250 and routing system 210.
DU emulator 250 installed on on-site computing platform 220B can emulate functions of DU 222 to allow for the directional antennas, RUs, routing system 210, and aspects of on-site computing platform 220 to be tested. In some examples, DU emulator 250 includes a testing manager 260 that can be configured to cause one or more tests to be performed by network connectivity is established using network transport connection 240. According to some configurations, the testing manager is configured to perform voltage standing wave ratio (VSWR) tests, passive inter modulation (PIM) tests, cable tests, RU tests, CSR tests, small form-factor pluggable (SFP) tests, physical cell identifier (PCI) tests, and the like.
In the case of voltage standing wave ratio (VSWR) tests, in some examples, the testing manager 260 of the DU emulator 250 can perform VSWR tests for different connections between the RUs and the antennas 232. To help ensure high transmission of radiation between a source and a downstream device over the air, VSWR tests are performed to determine efficiency of the antennas 232. Generally, a VSWR test is performed by the DU emulator 250 to determine an efficiency of an antenna to radiate power and can be used to indicate whether connections are properly torqued.
In some examples, the testing manager 260 determines a value of the VSWR for each of the different connections between an RU 125 and antennas 232 installed at the cell site. For example, the testing manager 260 may perform a VSWR test for each connection from an RU 125 to an antenna 232. Different cell sites can have a different number of connections to test (e.g., 1, 3, 4, 8, 32, 64, . . . ). In some cases, the ratio of the VSWR test can be used to determine whether the connection is properly torqued. As an example, if the value of the VSWR for a connection is between a first threshold and a second threshold then the connection is determined to be proper.
In some examples, the testing manager 260 may determine that a connection is acceptable (e.g., pass) if the value of the VSWR is between 1.0 and 1.5. A value of one (1) would indicate that the connection between the RU and the antenna is perfectly matched. In other examples, the values can change based on the specifications of the RUs and the antennas (e.g., 1.0 to 1.2, 1.0 to 1.3, 1.0 to 1.4, 1.0 to 1.6, and the like). If the VSWR exceeds a specified limit, the RU may be damaged (e.g., due to the reflected power) and/or shutdown before damage is caused. In some configurations, the DU emulator 250 generates a report that indicates the VSWR values for each of the connections and indicates whether a connection needs to be fixed.
In the case of physical cell identifier (PCI) tests. Generally, a PCI test can be used to determine that an antenna is associated with the correct PCI. A PCI is a physical layer cell identifier that indicates the physical identity of a cell. During a PCI test, the DU emulator 250 can test whether an RU is connected with the correct directional antenna 232. More specifically, the DU emulator 250 causes an RU to transmit using a directional antenna that is associated with a specific PCI value that is associated with a particular direction/sector.
As a signal is transmitted by the antenna being tested, the DU emulator 250 or some other device (e.g., a UE) can determine if the expected PCI value is being transmitted. The expected PIC for the antenna can readily be determined since PCIs are specified by the cell site operator, or some other authorized user. When the expected PCI value is transmitted, the PCI test for that antenna passes, and the DU emulator 250 can move to testing the next antenna. In cases when the expected PCI value is not transmitted, the DU emulator 250 can generate a ticket, an alarm, and/or some other indication that the incorrect antenna is connected to the RU. According to some configurations, the DU emulator 250 generates a report that includes information about the testing (e.g., pass/fail for each test, parameter associated with the testing, and the like).
In the case of passive intermodulation (PIM) tests, in some examples, the testing manager 260 of the DU emulator 250 can perform PIM tests to determine the linearity and construction quality of components associated with the transmission of a radio signal (e.g., antennas, antenna feed lines, RUs, . . . ). Generally, PIM comes from two more strong signals (e.g., radio frequency (RF)) mixing in a nonlinear device or junction. These nonlinear devices, or junctions, can occur be associated with connectors (e.g., improperly torqued, damaged, corroded), in antennas (e.g., damaged, rusted, mounts and bolts, . . . ), structures close to the cell site, contaminants, and the like. PIM can degrade the performance of the cell site (e.g., increase error rate, reduce the reception area, . . . ). As the signal amplitude increases, the effects of PIM becomes more noticeable, and causes more distortion.
In the case of cable tests, in some examples, the testing manager 260 of the DU emulator 250 can perform one or more cable tests to determine whether a cable is properly connected. In some examples, the DU emulator 250 communicates with the component/device attached to the connection being tested to determine if the expected component is connected to the port of the CSR. In some configurations, the DU emulator 250 can also perform some additional testing to determine whether the RU, or some other component, is operating properly. For example, in the case of an RU, the DU emulator 250 can determine if the RU has generated any alarms and/or is experiencing an error condition.
Different techniques can be used to test for PIM. In some examples, the DU emulator 250, and/or some other device (e.g., a PIM tester (not shown)) injects two test signals into the antenna feed and monitors a third order product to determine if the test signals encounter a nonlinear junction that causes PIM frequencies to be generated. If PIM frequencies exceed a specified threshold, the PIM test for that device (e.g., antenna) are failed by the DU emulator 250.
While the software for DU 222 may not yet be installed, DU emulator 250 can ensure that communication with on-site computing platform 220 is available and can occur at an acceptable speed with less than a maximum amount of error. Such testing can at least ensure that on-site computing platform 220 is physically connected properly with routing system 210 and is powered. In some examples, the DU emulator 250 can check each connection on the CSR to determine whether the connection is to the expected component. For example, the DU emulator 250 can perform a test to determine if a first RU is connected to the specified connection, a second RU is connected to a different specified connection, and the like.
DU emulator 250 may generate a report or certificate that indicates test results and/or whether all tests have been passed. If a failure is present, DU emulator 250 outputs an indication of the failed test and the components involved in the failed test, thus allowing the failure to be diagnosed. Once testing is complete, DU emulator 250 may be disconnected and used to test other base station installations that have yet to be connected with network transport 240. When testing is complete, the network transport can be expected to still not have been activated yet.
Building a next-generation cellular network generally requires multiple aspects of the cellular network to be developed simultaneously. For a 5G cellular network, the RAN may be built out at the same time the 5G core is being built. Significant testing of the 5G core may need to be performed to ensure when the cellular network is activated for customers, and calls and messages can be routed correctly. Therefore, a RAN may need to be simulated in order to test functionality of the 5G core.
A primary test performed by RAN validation system 310 may be to attempt to complete local phone calls and send local text messages. By emulating a portion of the RAN (e.g., a CU), RAN validation system 310 may attempt to complete a local phone call through 5G core 139. The local phone call can be expected to be routed back to the same CU. Therefore, if 5G core 139 is functioning properly, 5G core 139 will send data to RAN validation system 510 that attempts to connect the call with UE that communicates via the same CU. Similarly, RAN validation system 310 may send SMS or MMS text messages to another local (emulated) UE. If 5G core 139 is functioning properly, the message should be routed back to RAN validation system 310 for delivery (assuming the message is eligible for delivery, such as the account of the transmitting emulated UE being permitted to send MMS and/or SMS messages).
Various test parameters 314 may be stored and accessed by test engine 512. For instance, texts and calls from eligible and ineligible emulated UE may be sent to 5G core 139 to test whether 5G core 139 either correctly completes or blocks the calls and texts from being completed. RAN validation system 310 may create a log of passed and failed tests for review by developers.
Example cell site validation tests for validating connectivity in a cell site during or after installation of the cell site are provided. In various embodiments, after network transport connection 240 is made, the example validation tests can implemented by the DU 222 in the on-site computing platform 220 shown in
In some embodiments, method 400 may be implemented by a device including one or more of the processor, such as the on-site computing platforms 220 shown in
In some embodiments, method 400 is implemented by an on-site computing platform such as 220 shown in
As also shown, the routing systems 210, the RUs and antennas, and the communication towers are interconnected through one or more types of cables such as fiber, coaxial or any other types of cables. During construction of the cell site 502, it may be desired to run method 400 at certain stage or stages, for example after some or all of the cabinet structures 235 are set up. This can help detect if there are certain issues, such as faulty wiring, component(s), and/or installation are introduced during the construction of the cell site 502.
As shown in
At 402, pre-test configuration and connection are performed. In some embodiments, this may involve connecting the laptop 504 to one or more routing systems 210, detecting a version of the routing systems 210, configuring the routing systems with one or more configuration for running the test(s), and/or any other steps. One example of 402 is described and illustrated in
At 404, one or more RU tests are performed. In some embodiments, this may involve instructing, from the laptop 504, the RU(s) to run various functionality tests to test connections with the antenna and/or the communication tower. In some embodiments, this may involve mechanically testing one or more antennas connected to a particular RU. In some embodiments, 404 is performed only after 402 has a pass result.
At 406, a user (e.g., the field technician) is instructed to perform various tests to test downlink connections between UE and one or more RUs. This may involve instructing the user to go to various sectors in the cell site 502 to run downlink tests and take readings from the downlink tests. This may involve determining whether the readings indicate pass or fail, and generating test reports accordingly.
At 408, post test actions are performed. This may involve sending test data and/or results to the server 506.
In some embodiments, method 600 may be implemented by a device including one or more of the processor, such as the on-site computing platforms 220 shown in
At 602, a cell site router system (CSR) is connected to the device, such as the on-site computing platform 220 shown in
Typically, a given RU, such as the RU 125-1, in cabinet structure 235 is connected to one or more antennas of different configurations. The different configurations of the antenna connections to the given RU can facilitate different communication coverage (for example, in terms of distance and/or frequency) enabled by the given RU. One or more of such antenna connections to the given RU is to be tested/validated as will be described below. For instance, a given antenna may be configured to tilt at certain degree so not to interfere with another antenna's communication path. The configurations of these antennas should be tested to ensure their communication paths indeed do not interfere with each other.
In some embodiments, 602 is performed by a field technician dispatched to the cell site. For instance, in one embodiment, the field technician has the knowledge of which port on the CSR his/her laptop having the testing software should be plugged into. However, this is not intended to be limiting. It is contemplated that the connection to the CSR at 602 can be performed automatically and remotely without a technician's intervention in the field site. In that embodiment, after the CSR is connected to the laptop, the testing software on the field technician's laptop obtains CSR information regarding various parameters of the CSR-for example, on which ports of the CSR, particular RUs are connected, one or more IP addresses used by the CSR, an identification of the CSR indicating a type of the CSR, and/or any other parameters.
At 604, one or more testing configurations for the CSR are pushed to the CSR based on the information obtained at 602. For example, a database may be implemented on the laptop of the field technician, storing various configurations for different CSRs across multiple cell sites. Based on the particular CSR information obtained at 602, the testing software on the field technician's software can push a matching configuration to the CSR connected at 602. In one embodiment, the matching configuration pushed to the CSR at 602 provides reachability to RUs connected the CSR and to one or more m/c-plane ports.
At 606, one or more RUs connected to the CSR are detected. For instance, after the configuration pushed at 604 to the CSR, the CSR provides a list of RUs connected to the CSR and their corresponding ports on the CSR. Based on this list, in that instance, the testing software on the technician's laptop can obtain RU information regarding the RUs on the list.
At 608, RUs detected at 606 are enabled for communication. For instance, IP addressing service is provided to the RUs such that each of the RUs is assigned an IP address. With the IP address, a given one of the RUs is then enabled to communicate, using IP protocol, with, for example, the DU emulator 250, the testing software on the field technician's laptop, the CSR, UE (user equipment) and/or any other components. In one embodiment, a list of fixed IP addresses are predetermined for assignment to the RUs at 608.
At 610, hardware information of RUs is recorded. For example, after a given one of the RUs is assigned an IP address, the given RU is reachable through IP communication. The IP communication includes hardware information regarding the given RU, such as the MAC address of the given RU. The hardware information of the given RU is then recorded, for example, by the testing software on the field technician's laptop. The hardware information, such as the MAC address, can be used to report testing results for a particular RU as identification information of the particular RU.
At 612, precision time protocol (PTP) time and GPS location of the cell site is obtained from the CSR. In one embodiment, the testing software on the field technician's laptop is configured to obtain the PTP time and the GPS location from the CSR to ensure that the CSR is properly running with a synchronized PTP time and a correct GPS location. In various embodiments, one or more steps outlined in method 600 may be performed again if those steps do not provide intended result. For example, 606 may be performed more than once until a list of RUs known to be connected to the CSR is obtained. If one or more of such RUs are missing from the list, 606 may be performed more than once to ensure all known RUs that are supposed to be connected to the CSR are detected.
In some embodiments, method 700 may be implemented by a device including one or more of the processor, such as the on-site computing platform 220B shown in
At 702, M-plane (management plane) connections to the RUs under test are established. In ORAN, the O-RU management functions to set parameters are done over the M-Plane. The management functions include O-RU software management, fault management, and/or any other management functions. In one embodiment, the connections at 702 are established by the testing software on the field technician's laptop.
At 704, the RUs are queried to gather various RU information. For example, the RU information gathered at 704 includes information indicating make, model, serial number, RU-ID, current software version, memory usage, and other types of RU information for the individual ones of the RUs.
At 706, software version of the RUs is checked to ensure the RUs are installed with the current version of the RU software. It is important to perform this step before commencing other tasks because if the RU is not installed with the current RU software, tests through the RU can be erroneous or not run properly. In the event that a given RU is detected not have the current RU software, the current RU software is pushed to the given RU, for example from the testing software on the field technician's laptop or a server, and the RU is restarted to ensure the current RU software is installed and run on the given RU.
At 708, individual RUs are queried for their alarm status. The query at 708 can yield one or more alarms being reported back from the individual RUs. The alarms can then be logged, for example in a database by testing software on the field technician's laptop. Some examples of the alarms reported by the individual RUs include various issue indicators showing the RUs are not running properly. Such an issue can happen due to malfunction of the RU introduced during the manufacturing of the RU and/or during installation of the RU. An alarm indicating the RU is not properly running can be critical. Depending on the severity of the alarm, one or more tests can be adjusted. For example, a test of the RU may be delayed until the critical alarm is cleared.
At 710, SFPs (small form-factor pluggable) on the CSR and the individual RUs are queried for light levels. The SFPs return values of light levels passing through them. This can check whether fiber cables connecting the CSR and the individual RUs are clean.
At 712, ports of AISG (Antenna Interface Standards Group) connection on the RUs are discovered. These serial ports are used for the RUs to connect antennas. Through these serial ports, tests can be run to test antennas connected to the RUs.
At 714, S/N (serial numbers) of individual antenna connected to the RUs are retrieved. A S/N of a given antenna can be used as identification information of the given antenna to indicate one or more test results associated with the given antenna. In one embodiment, two RUs (for example, a low band RU and mid-band RU) are connected to an antenna, which has two connection modes. In that embodiment, the testing software on the field technician's laptop is configured to detect how the two RUs are connected (e.g., daisy chained or parallelly connected to the antenna) and determine which antenna test is to be run based on the connection configuration of the two RUs to antenna.
At 716, RET (Remote Electrical Tilt) settings of the individual antennas are obtained. An RET setting of a given antenna indicates whether the given antenna is currently tilted as intended. In one embodiment, the RET setting of the given antenna obtained at 716 should be 0 degree.
At 718, for a given antenna, a target e-tilt setting is set to test the given antenna's functionality at that target e-tilt setting. For example, the target e-tilt setting may be 10.0 e-tilt, and once the 10.0 e-tilt setting is set to the given antenna, the AISG port through which the given antenna is connected to the RU is monitored and/or queried from time to time to obtain signal receiving progress reported back from the given antenna, alarms and/or any other information from the given antenna. In one embodiment, a 10.0 e-tilt and a 0.0 e-tilt are each set to the given antenna to test the given antenna's functionality under those e-tilt setting during a preset period. For example, the given antenna is tested that it can be tilted all the way to 10.0 e-tilt and brought back to 0.0 e-tilt. In that embodiment, the e-tilt tests at 718 are executed by the testing software on the field technician's laptop.
At 720, the individual RUs are configured to transmit a set of signals. In one embodiment, the following tables indicate sequential commands with specified RF signals are sent to individual RUs for transmission at 720. In some embodiments, 720 is performed by the testing software on the field technician's laptop.
At 722, individual RUs are queried to confirm their settings, including data sent, after 720 is performed. In the embodiment shown above, the RF parameter of data sent as reported back by the RU, should match the RF signals listed in the above tables.
At 724, individual RUs are queried for alarms. During the transmission of the RF signals alarms may be reported by the individual RUs to indicate one or more issues during the transmission. Such an alarm should be obtained at 724 and logged.
At 726, individual RUs are queried for values of VSWR (Voltage Standing Wave Ratio). This is to check if there is any undue load or balance on the individual RUs, which can be caused during the installation the individual RUs in the cabinet structure 235. For example, if a cable is wrongly plugged into a given RU, 726 can be used to detect the returned value of VSWR by the given RU does not match the expected VSWR value for the given RU, and thus catch the issue of wrong plugged-in cable.
In some embodiments, method 800 may be implemented by a device including one or more of the processor, such as the on-site computing platform 220 shown in
In some embodiments, method 800 is performed after methods 600 and 700 are performed with an indication that one or more RUs are up and running properly. Method 800 focuses on testing a link between UE and a particular one of the one or more RUs.
At 802, an instruction is provided to instruct a user (e.g., a field technician) to link UE (e.g., his/her mobile phone) with on-site computing platform (e.g., his/her laptop). In some embodiments, 802 is performed by providing such an instruction in a user interface of the testing software on the field technician's laptop.
At 804, a connection is established with the UE in the cell site. In one embodiment, 804 is performed by testing software on the field technician's laptop. In that embodiment, once a request to link the UE to the on-site computing platform is initiated by the field technician on the UE, the UE starts an app in the UE, which enables a Wi-Fi connection, such as a Bluetooth connection, with the field technician's laptop. Then, the UE starts connecting the field technician's laptop via the Wi-Fi connection. In some embodiments, 804 is performed at a request of the field technician through the user interface of the testing software on the field technician's laptop. In some embodiments, 804 is performed automatically after the UE is linked with the on-site computing platform at 802.
At 806, cell site specific data is sent to the UE via the connection established at 804 for UE to conduct various tests in the cell site. Examples of the cell site specific data sent at 806 include one or more tests for the cell site, one or more test patterns, geolocation information of the cell site, signal radiation patterns of the cell site, base station location information of the cell site, and/or any other information. The one or more test for the cell site can be designed based on a type of the cell site or a configuration of the cell site. Different test suites for the UE to run in different types or configurations of the cell sites can be developed. Once the field technician is at a particular cell site, the site specific test suite for that cell site can be sent to the UE for testing that cell site. Similarly, test patterns can also be made cell site specific such that two different cell sites may have different test patterns for the UE to run. Geolocation information of the cell site, signal radiation patterns of the cell site, and base station location information can inform the UE where to run the cell site specific test suite and/or one or more test patterns.
At 808, the user (e.g., the field technician) is instructed to go to a specific location to run one or more tests and collect sector reading using the UE. For instance, such an instruction is provided through an user interface on the UE by the testing software on the field technician's laptop. The instruction can include information as to which one(s) of the tests is to be run and where in the cell site it should be run, information indicating that how the user should collect sector reading using the UE after the test(s) is completed, and/or any other information.
At 810, geographical information regarding where to stand for sector test is provided after the user is instructed to perform the sector test at 808. For example, a map overlaid with base station locations can be presented to the user on the UE to show where the sector test should be performed by the technician.
At 812, the user is instructed to remain still (or relatively still) while taking the readings of the sector test once he/she is in the target area for the sector test. In some embodiments, 812 involves receiving location information of the UE and determine that the user is indeed in the target area. In some embodiments, 812 involves the user confirms that he/she is in the target area through the user interface on the UE. In one embodiment, UE progress of reading (e.g., a counter or a slide bar) is provided on the user interface on the UE to inform the user of a progress of the sector test. In one embodiment, all TEST PCIs received are and respective RSRP, RSRQ, SINR are logged by the UE.
At 814, an instruction is provided to the user to go to the next sector in the cell site for another sector test. As can be seen, similar to the sector test steps mentioned above, after 814, the process in method 800 can loop back to 810. This can repeat for however many sector tests are to be performed in the cell site.
At 816, after the final sector test is performed, an instruction is provided on the UE to instruct the user to go back to a proximity of the on-site computing platform. This may involve determining all sector tests for the cell site have been performed by the UE and readings for the sector tests are recorded on the UE.
At 818, once the UE is within the proximity of the on-site computing platform (e.g., the field technician's laptop), the UE is connected to the on-site computing platform. This may involve detecting that the UE is indeed within the proximity of the field technician's laptop. In some embodiments, the user confirms on the laptop that he/she has returned to the laptop and the UE is ready to be connected to the laptop. In one embodiment, the UE is connected to the laptop via Bluetooth.
At 820, test data from the sector test(s) is uploaded from the UE to the on-site computing platform. In some embodiments, a confirmation is provided in the user interface on the on-site computing platform such as the technician's laptop that the test data has been successfully uploaded to the laptop.
At 822, calculations are made based on the test data received at 820 by the on-site computing platform. In one embodiment, 822 involves evaluating downlink signal strength and/or quality collected by the UE at various sectors of the cell site to determine if the RUs are transmitting signals as intended. If the downlink signal strength and/or quality for a particular sector do not meet expected threshold values, this can be used as an indication that faulty installation and/or wiring of the RUs may have occurred during construction of the cell site. For example, this can be caused by mis-wiring between RU and corresponding antenna.
At 824, based on the calculations made at 822, one or more pass or fail results are indicated. In some embodiments, the results at 824 are indicated in the user interface in the testing software on the field technician's laptop. In one embodiment, for a FAIL result, the laptop indicates areas that failed and has suggested fixes; instructs the user to re-run tests once repairs have been made. In that embodiment, for the fail result, the user interface of testing software on the field technician's laptop has a “Retest” button which restarts the testing software for the field to re-run methods 600, 700, and/or 800. For PASS results, the laptop logs all data shown as passing, and instructs user to connect to internet to send Pass Report.
At 826, the CSR is reconfigured back to Day-0 “listening” mode. In some embodiments, 826 is performed by testing software on the field technician's laptop. The Day-0 listening mode is a mode in which the CSR listens for instruction message for configuration. In various embodiments, even if the test is failed, the CSR is still desired to be reconfigured back to this mode while issues are being addressed and fixed.
In some embodiments, method 900 may be implemented by a device including one or more of the processor, such as the on-site computing platform 220 shown in
At 902, internet connection is detected, and server (e.g., server 506 shown
In some embodiments, method 1000 may be implemented by a device including one or more processors, such as the on-site computing platform 220B shown in
At 1002, a connection between the DU emulator 250 and the routing system 210 (e.g., a CSR) is established. As discussed above, in some examples, the DU emulator 250 is connected to the CSR before the network transport connection 240 is established, or a DU is installed at the site. In some examples, the DU emulator 250 can obtain, from the CSR, the list of RUs 125 connected to the routing system 210 and the ports that each of the CSRs are connected to on the CSR.
At 1004, one or more tests to perform using the DU emulator 250 is determined. In some examples, a user may indicate the tests to perform using a user interface (not shown). As discussed above, in some examples, the tests may include but are not limited to voltage standing wave ratio (VSWR) tests, passive inter modulation (PIM) tests, cable tests, RU tests, CSR tests, small form-factor pluggable (SFP) tests, physical cell identifier (PCI) tests, and the like.
At 1006, the test(s) are performed by the DU emulator 250. As discussed above, the VSWR tests can be used to determine whether the connections between the antennas and one or more RUs is within specified limits (e.g., is the connection torqued properly). See
At 1108, a determination is made as to whether the test passed. When the test passes (e.g., based on the type of test being performed), the process moves to 1112. When the test fails, the process moves to 1110.
At 1010, data associated with the failing test is stored. In some examples, if a test fails, a ticket can be generated by the DU emulator 250 and provided to a user/team designated to address the problem. In other examples, the data can be used to generate a report as illustrated in 1114.
At 1012, data associated with the passing test for the connection is stored. In some examples, the data can be used to generate a report as illustrated in 1114.
At 1014, information relating to the test is generated and provided. As discussed above, the information can include results of each of the tests, as well as information about correcting any detected problems.
In some embodiments, method 1100 may be implemented by a device including one or more processors, such as the on-site computing platform 220B shown in
At 1102, a connection between the DU emulator 250 and the routing system 210 (e.g., a CSR) is established. As discussed above, in some examples, the DU emulator 250 is connected to the CSR before the network transport connection 240 is established, or a DU is installed at the site.
At 1104, the connections to test are determined. In some examples, the DU emulator 250 can obtain, from the CSR, the list of RUs 125 connected to the routing system 210 and the ports that each of the CSRs are connected to on the CSR.
At 1106, the values of voltage standing wave ratio (VSWR) associated with a connection are determined. As discussed above, the VSWR for a connection can be used to determine whether a connection between an antenna and an RU is within specified limits (e.g., is the connection torqued properly). For example, during installation one or more of the connections may be improperly torqued causing the VSWR to be higher than a specified threshold. As another example, if a cable is wrongly plugged into a given RU, and the value of VSWR by the RU does not match the expected VSWR value, the DU emulator 250 can determine that the cable is plugged into a wrong port of the CSR.
At 1108, a determination is made as to whether the connection being tested passed. When the connection passes (e.g., the connection is properly torqued and/or plugged into the correct port), the process moves to 1112. When the connection fails (e.g., the connection is improperly torqued and/or not plugged into the correct port), the process moves to 1110.
At 1110, data associated with the failing test for the connection is stored. In some examples, if a connection fails the VSWR test, a ticket can be generated by the DU emulator 250 and provided to a user designated to fix the connection. In other examples, the data can be used to generate a report as illustrated in 1116.
At 1112, data associated with the passing test for the connection is stored. In some examples, if a connection passes the VSWR test, the data can be used to generate a report as illustrated in 1116.
At 1114, a determination is made as to whether there is another connection to test. As discussed above there may a large number of connections to test at a cell site (e.g., 12, 48, . . . ). When there is another connection to test, the process returns to 1106. When there is not another connection to test, the process moves to 1116.
At 1116, information relating to the VSWR testing is generated and provided. As discussed above, the information can include results of each of the VSWR tests for the different connections, as well as information about correcting any detected problems.
In some embodiments, method 1200 may be implemented by a device including one or more processors, such as the on-site computing platform 220B shown in
At 1202, a connection between the DU emulator 250 and the routing system 210 (e.g., a CSR) is established. As discussed above, in some examples, the DU emulator 250 is connected to the CSR before the network transport connection 240 is established, or a DU is installed at the site.
At 1204, the antennas and RUs connected are determined. In some examples, the DU emulator 250 can obtain, from the CSR, the list of RUs 125 connected to the routing system 210 and the ports that each of the CSRs are connected to on the CSR.
At 1206, the physical cell ID (PCI) and/or the cell identifier (CID) for a base station (e.g., cell tower) being tested is determined. According to some examples, a mobile device, such as a UE, can be used to obtain the PCI/CID information. As discussed above, a PCI identifies the physical identity of an RU/cell during a cell selection procedure. The CID identifies the base station and/or the sector of a base station. In some examples, PCI values are assigned by the network operator and can be used to ensure that mobile devices (e.g., UEs) using the cellular network can differentiate neighboring cells. Other values, such as CID can also be used to determine if the correct base station and/or antenna is transmitting.
At 1208, a determination is made as to whether the correct base station and/or antenna is identified. When the correct base station and/or antenna is being used, the process moves to 1112. When the correct base station and/or antenna is being used, the process moves to 1110.
At 1210, data associated with the failing test for the correct base station and/or antenna is stored. In some examples, a ticket can be generated by the DU emulator 250 and provided to a user designated to address the problem. In other examples, the data can be used to generate a report as illustrated in 1216.
At 1212, data associated with the passing test for correct base station and/or antenna is stored. In some examples, the data can be used to generate a report as illustrated in 1216.
At 1214, a determination is made as to whether there is another antenna/sector to test. As discussed above there may many different antennas/sectors to test at a cell site. When there is another test to perform, the process returns to 1206. When there is not another connection to test, the process moves to 1216.
At 1216, information relating to the PCI testing is generated and provided. As discussed above, the information can include results of each of the PCI tests for the different connections, as well as information about correcting any detected problems.
In some embodiments, method 1300 may be implemented by a device including one or more processors, such as the on-site computing platform 220B shown in
At 1302, a connection between the DU emulator 250 and the routing system 210 (e.g., a CSR) is established. As discussed above, in some examples, the DU emulator 250 is connected to the CSR before the network transport connection 240 is established, or a DU is installed at the site.
At 1304, the antennas and RUs connected are determined. In some examples, the DU emulator 250 can obtain, from the CSR, the list of RUs 125 connected to the routing system 210 and the ports that each of the CSRs are connected to on the CSR.
At 1306, the PIM data for an antenna being tested is determined. According to some examples, one or more devices (not shown) can be used to obtain the PIM information. As discussed above, a PIM test generally determines whether equipment mounted on the tower 115-1 is causing interference. PIM can be caused by a variety of different factors, such as loose connectors, corrosion, damaged antennas, and the like.
At 1308, a determination is made as to whether there is PIM that is interfering with the transmission of the antenna being tested. When there is PIM that is beyond a specified threshold, the process moves to 1310. When the PIM is below the specified threshold, the process moves to 1312.
At 1310, data associated with the failing PIM test is stored. In some examples, a ticket can be generated by the DU emulator 250 and provided to a user designated to address the problem. In other examples, the data can be used to generate a report as illustrated in 1316.
At 1312, data associated with the passing test is stored. In some examples, the data can be used to generate a report as illustrated in 1316.
At 1314, a determination is made as to whether there is another antenna to test. As discussed above there may many different antennas to test at a cell site. When there is another test to perform, the process returns to 1306. When there is not another connection to test, the process moves to 1316.
At 1316, information relating to the PIM testing is generated and provided. As discussed above, the information can include results of each of the PCI tests for the different connections, as well as information about correcting any detected problems.
In some embodiments, method 1400 may be implemented by a device including one or more processors, such as the on-site computing platform 220B shown in
At 1402, a connection between the DU emulator 250 and the routing system 210 (e.g., a CSR) is established. As discussed above, in some examples, the DU emulator 250 is connected to the CSR before the network transport connection 240 is established, or a DU is installed at the site.
At 1404, the connections to test are determined. In some examples, the DU emulator 250 can obtain, from the CSR, the list of RUs 125 and/or other components connected to the ports of the CSR 210.
At 1406, a connection is tested. As discussed above, the DU emulator 250 can communicate with the component/device attached to the connection being tested to determine if the expected component is connected to the port of the CSR. For example, the DU emulator 250, when testing a connection to a specific RU, can request identifying information from the RU to determine whether the correct RU is connected to that port. The DU emulator 250 can also perform some additional testing to determine whether the RU, or some other component, is operating properly. For example, in the case of an RU, the DU emulator 250 can determine if the RU has generated any alarms and/or is experiencing an error condition.
At 1408, a determination is made as to whether the connection being tested has passed (e.g., is connected to the expected component and, in some cases, whether the connected component is operating as expected). When the connection passes, the process moves to 1412. When the correct base station and/or antenna is being used, the process moves to 1410.
At 1410, data associated with the failing test is stored. In some examples, a ticket can be generated by the DU emulator 250 and provided to a user designated to address the problem. In other examples, the data can be used to generate a report as illustrated in 1416.
At 1412, data associated with the passing test is stored. In some examples, the data can be used to generate a report as illustrated in 1416.
At 1414, a determination is made as to whether there is another connection to test. As discussed above there may many different connections to test at a cell site. When there is another test to perform, the process returns to 1406. When there is not another connection to test, the process moves to 1416.
At 1416, information relating to the connection testing is generated and provided. As discussed above, the information can include results of each of the different connections tested, as well as information about correcting any detected problems.
Any of the embodiments mentioned herein may be implemented by or utilize any suitable number of subsystems. Examples of such subsystems are shown in
The subsystems shown in
A computer system can include a plurality of the same components or subsystems, e.g., connected together by external interface 81 or by an internal interface. In some embodiments, computer systems, subsystem, or apparatuses can communicate over a network. In such instances, one computer can be considered a client and another computer a server, where each can be part of a same computer system. A client and a server can each include multiple systems, subsystems, or components.
It should be understood that any of the embodiments of the present invention can be implemented in the form of control logic using hardware (e.g. an application specific integrated circuit or field programmable gate array) and/or using computer software with a generally programmable processor in a modular or integrated manner. As used herein, a processor includes a single-core processor, multi-core processor on a same integrated chip, or multiple processing units on a single circuit board or networked. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement embodiments of the present invention using hardware and a combination of hardware and software.
Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and/or transmission, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices.
Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and/or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g. a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.
Any of the methods described herein may be totally or partially performed with a computer system including one or more processors, which can be configured to perform the steps. Thus, embodiments can be directed to computer systems configured to perform the steps of any of the methods described herein, potentially with different components performing respective steps or a respective group of steps. Although presented as numbered steps, steps of methods herein can be performed at a same time or in a different order. Additionally, portions of these steps may be used with portions of other steps from other methods. Also, all or portions of a step may be optional. Additionally, any of the steps of any of the methods can be performed with modules, circuits, or other means for performing these steps.
The specific details of particular embodiments may be combined in any suitable manner without departing from the spirit and scope of embodiments of the invention. However, other embodiments of the invention may be directed to specific embodiments relating to each individual aspect, or specific combinations of these individual aspects.
The above description of exemplary embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form described, and many modifications and variations are possible in light of the teaching above. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications to thereby enable others skilled in the art to best utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated.
A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary. The use of “or” is intended to mean an “inclusive or,” and not an “exclusive or” unless specifically indicated to the contrary.
All patents, patent applications, publications, and descriptions mentioned herein are incorporated by reference in their entirety for all purposes. None is admitted to be prior art.
Having described several embodiments, it will be recognized by those of skill in the art that various modifications, alternative constructions, and equivalents may be used without departing from the spirit of the invention. For example, the above elements may merely be a component of a larger system, wherein other rules may take precedence over or otherwise modify the application of the invention. Also, a number of steps may be undertaken before, during, or after the above elements are considered. Accordingly, the above description should not be taken as limiting the scope of the invention.
This application is a continuation-in-part of U.S. Non-Provisional patent application Ser. No. 17/929,685, entitled “Validation Tests During or After Construction of a Cell Site”, filed on Sep. 3, 2022, which claims priority to U.S. Provisional Patent Application No. 63/240,571, entitled “Advanced Cellular Network Communication Platform”, filed on Sep. 3, 2021, the disclosures of which are incorporated by reference in their entirety for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 63240571 | Sep 2021 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17929685 | Sep 2022 | US |
| Child | 18884586 | US |
