IMPLEMENTING A LIVE DISTRIBUTED ANTENNA SYSTEM (DAS) CONFIGURATION FROM A VIRTUAL DAS DESIGN USING AN ORIGINAL EQUIPMENT MANUFACTURER (OEM) SPECIFIC SOFTWARE SYSTEM IN A DAS
Implementing a live distributed antenna system (DAS) configuration from a virtual DAS design using an original equipment manufacturer (OEM) specific software system in a real DAS is disclosed herein. In exemplary aspects disclosed herein, the OEM specific software system enables a designer to create, save, import, modify and/or preconfigure a virtual DAS in a virtual DAS configuration file(s) using OEM specific software tools resident in the real DAS. The OEM specific software tools could include functionality such as the ability to incorporate and enforce OEM design constraints of the real DAS. The configuration file(s) can then be subsequently implemented to modify and/or configure live equipment of a real DAS. The OEM specific software tools and local execution of the virtual DAS facilitates, improves, and optimizes DAS design and execution, and ensures that the real DAS substantially matches the DAS design.
This application claims the benefit of priority under 35 U.S.C. §119 of U.S. Provisional Application No. 62/329,592, filed on Apr. 29, 2016, the content of which is relied upon and incorporated herein by reference in its entirety.
BACKGROUNDThe disclosure relates to implementing distributed antenna systems (DAS), and more particularly to implementing a live DAS configuration from a virtual DAS design using an original equipment manufacturer (OEM) specific software system in a DAS.
Wireless customers are increasingly demanding wireless communications services, such as cellular communications services and Wi-Fi services. Thus, small cells, and more recently Wi-Fi services, are being deployed indoors. At the same time, some wireless customers use their wireless communication devices in areas that are poorly serviced by conventional cellular networks, such as inside certain buildings or areas where there is little cellular coverage. One response to the intersection of these two concerns has been the use of distributed antenna systems (DASs). A DAS usually includes a head-end unit (HEU) connected to remote equipment (e.g., remote access units (RAU), remote hub units (RHU), etc.) thereby creating antenna coverage areas for establishing communications with wireless client devices located therein. In particular, the RAUs are configured to receive and transmit communications signals to client devices within the antenna range of the RAUs. DASs can be particularly useful when deployed inside buildings or other indoor environments where the wireless communication devices may not otherwise be able to effectively receive radio frequency (RF) signals from a source.
In this regard,
With continuing reference to
Designers of DAS systems use third party software to create RF designs that provide recommended configurations for placement and settings of remote equipment (e.g., RAUs or RHUs). These RF designs are used by installers to perform initial installations of equipment for a DAS. This remote equipment include remote units, including remote access units that contains electronics (e.g., fiber transceivers, filters, power amplifiers, built in antenna(s) or port(s)) to connect the remote equipment to external antenna(s) that propagate RF signals. Among other things, the RF designs provide predicted output power per Wireless Operator (e.g., Wireless Carrier), and predicted individual channel powers for various Wireless Operator protocols or technologies (e.g., LTE, UMTS, CDMA, EVDo, GSM, etc.) at each remote device.
Once the RF design is complete, the DAS system installer and/or commissioner (e.g., who commission and/or optimize the DAS system) attempts to construct and/or commission the DAS system to closely match the RF design. The installer connects the remote equipment at or near the locations indicated in the design. The commissioner can calibrate settings for the DAS system components (e.g., remote equipment) per the manufacturer specific instructions. Placement and settings can be varied from the RF design according to the environment and experience of the commissioner. The commissioner integrates (e.g., connects) the equipment to distribute live signals (provided from wireless operator signal source equipment (and/or other equipment)) into DAS head-end components (e.g., the Radio Interface Module(s) (RIM), power conditioner(s), etc.). The commissioner also optimizes output power of the remote equipment (e.g., RAUs or RHUs) per the wireless operator technology and/or protocol.
The third party RF design software may allow designers to complete system designs that violate DAS manufacturer specific software and hardware configuration requirements. Such RF design errors can lead to unplanned delays and/or unplanned systems costs from an inability to implement the system as originally designed. For example, the installer and/or commissioner may be required to obtain additional components to complete DAS installation and/or commissioning. Further, the layout and location of the HEU and other components within the equipment racks and modules within the cassis are left to the discretion of the installer. The installer may mount and install system components in a way that is different than the intended design (whether or not properly documented by the designer). As a result, it may be required to re-rack equipment or reposition modules within the cassis, which could invalidate commissioning of the system. Further, the DAS system design may not include information regarding how to configure DAS manufacturer specific system components through DAS manufacturer specific software interfaces (e.g., web-accessible graphical user interface (GUI), local GUI, etc.). Thus, the commissioner may configure the DAS equipment settings in a suboptimal manner (e.g., signal(s) does not reach the intended remote location(s), RF propagated at unintended power levels, etc.).
SUMMARYEmbodiments of the disclosure are directed to implementing a live distributed antenna system (DAS) configuration from a virtual DAS design using an original equipment manufacturer (OEM) specific software system in a real DAS. The OEM specific software can be resident software in the DAS or accessible by the DAS. In exemplary aspects disclosed herein, the OEM specific software system enables a designer to create, save, import, modify and/or preconfigure a virtual DAS in a virtual DAS configuration file(s) using OEM specific software tools resident in the real DAS. The OEM specific software tools could include functionality such as the ability to incorporate and enforce data, information, specifications, and/or limitations of the real DAS (e.g., OEM design constraints) for example, to facilitate design and optimization of the virtual DAS for improved and optimized performance of the real DAS. The configuration file(s) can then be subsequently implemented to modify and/or configure live equipment of a real DAS (e.g., to automatically calibrate the live equipment). Additionally, the configuration file(s) could guide a user through installation of the real DAS equipment to ensure proper installation thereof. The OEM specific software tools and local execution of the virtual DAS facilitates, improves, and optimizes DAS design and execution, and ensures that the real DAS substantially matches the DAS design. Thus, errors associated with design, installation, commissioning, and/or optimization may be reduced, and performance improved and optimized.
One embodiment is a system for implementing a live DAS configuration from a virtual DAS design using an OEM specific software system in a real DAS. The system comprises a real DAS comprising signal distribution equipment and an OEM specific software system. The signal distribution equipment includes a head-end unit that comprises a processor, a memory coupled to the processor, and a display device coupled to the processor. The OEM specific software system is electronically stored in the memory of the real DAS, and is configured to execute processing steps. The processor is configured to configure at least one virtual DAS setting for a virtual DAS. The processor is also configured to enforce upon the at least one virtual DAS setting OEM, design constraints of at least one real setting of signal distribution equipment in the real DAS. The processor is further configured to generate at least one virtual DAS configuration file comprising the at least one virtual DAS setting for the virtual DAS. The processor is further configured to store the at least one virtual DAS configuration file in the memory at the real DAS. The processor is further configured to modify the at least one real setting of the signal distribution equipment in the real DAS based on the at least one virtual DAS setting in the at least one virtual DAS configuration file.
An additional embodiment of the disclosure relates to a method for implementing a live DAS configuration from a virtual DAS design using an OEM specific software system in a real DAS. The method comprises configuring, by an OEM specific software system in a real DAS, at least one virtual DAS setting for a virtual DAS, and enforcing, by the OEM specific software system, upon the at least one virtual DAS setting OEM design constraints of at least one real setting of signal distribution equipment in the real DAS. The method further comprises generating, by the OEM specific software system, at least one virtual DAS configuration file comprising the at least one virtual DAS setting for the virtual DAS, and storing, by the OEM specific software system, the at least one virtual DAS configuration file in memory at the real DAS. The method further comprises modifying, by the OEM specific software system, the at least one real setting of the signal distribution equipment in the real DAS based on the at least one virtual DAS setting in the at least one virtual DAS configuration file.
An additional embodiment of the disclosure relates to a non-transitory computer readable medium comprising program instructions for implementing a live DAS configuration from a virtual DAS design using an OEM specific software system in a real DAS. The program instructions, when executed, comprise the processing steps of configuring, by an OEM specific software system in a real DAS, at least one virtual DAS setting for a virtual DAS, and enforcing, by the OEM specific software system, upon the at least one virtual DAS setting OEM design constraints of at least one real setting of signal distribution equipment in the real DAS. The program instructions, when executed, further comprise the processing steps of generating, by the OEM specific software system, at least one virtual DAS configuration file comprising the at least one virtual DAS setting for the virtual DAS, and storing, by the OEM specific software system, the at least one virtual DAS configuration file in memory at the real DAS. The program instructions, when executed, further comprise the processing steps of modifying, by the OEM specific software system, the at least one real setting of the signal distribution equipment in the real DAS based on the at least one virtual DAS setting in the at least one virtual DAS configuration file.
Additional features and advantages will be set forth in the detailed description which follows, and in part will be readily apparent to those skilled in the art from that description or recognized by practicing the embodiments as described herein, including the detailed description which follows, the claims, as well as the appended drawings.
It is to be understood that both the foregoing general description and the following detailed description are merely exemplary, and are intended to provide an overview or framework to understanding the nature and character of the claims. The accompanying drawings are included to provide a further understanding, and are incorporated in and constitute a part of this specification. The drawings illustrate one or more embodiments, and together with the description serve to explain principles and operation of the various embodiments.
Reference will now be made in detail to the present preferred embodiments, examples of which are illustrated in the accompanying drawings. Whenever possible, the same reference numerals will be used throughout the drawings to refer to the same or like parts. One embodiment of an original equipment manufacturer (OEM) specific software system is shown in
Embodiments of the disclosure are directed to implementing a live distributed antenna system (DAS) configuration from a virtual DAS design using an OEM specific software system in a real DAS. The OEM specific software can be resident software in the DAS or accessible by the DAS. In exemplary aspects disclosed herein, the OEM specific software system enables a designer to create, save, import, modify and/or preconfigure a virtual DAS in a virtual DAS configuration file(s) using OEM specific software tools resident in the real DAS. The OEM specific software tools could include functionality such as the ability to incorporate and enforce data, information, specifications, and/or limitations of the real DAS (e.g., OEM design constraints) for example, to facilitate design and optimization of the virtual DAS for improved and optimized performance of the real DAS. The configuration file(s) can then be subsequently implemented to modify and/or configure live equipment of a real DAS (e.g., to automatically calibrate the live equipment). Additionally, the configuration file(s) could guide a user through installation of the real DAS equipment to ensure proper installation thereof. The OEM specific software tools and local execution of the virtual DAS facilitates, improves, and optimizes DAS design and execution, and ensures that the real DAS substantially matches the DAS design. Thus, errors associated with design, installation, commissioning, and/or optimization may be reduced, and performance improved and optimized.
In aspects disclosed herein, the OEM specific software system (e.g., DAS manufacturer OEM specific software system) enables a DAS designer to create a virtual DAS (e.g., which could be referred to as a “Profile”) and/or upload or import an existing real DAS to create a virtual DAS. The DAS designer can then modify the virtual DAS (e.g., adding or removing buildings or DAS components, reconfiguring user definable settings for the virtual DAS or DAS components, etc.). The user definable settings of the virtual DAS include equipment layout and physical connectivity between (1) system components and/or (2) modules within rooms, racks, or chassis. The virtual DAS can include components being physically located in multiple buildings or structures as well as outdoor locations. The OEM specific software system may further enable pre-configuration of some or all user definable settings in the virtual DAS in advance of the virtual DAS being activated on a real DAS (e.g., live DAS, active DAS, etc.), or prior to the real DAS being otherwise deployed.
The virtual design profile within the DAS OEM specific software can be created at one location or on one system, and can be loaded onto another system at the same or different location either locally at a DAS system site(s) or through internet connections. A bill of materials of system components may be generated automatically or manually for the virtual components within the virtual DAS, or from modifications to the virtual DAS (e.g., of an existing system), such as if a virtual component moves, is added, or otherwise changes. This can simplify procurement of equipment (e.g., signal distribution equipment, real equipment, etc.) for the real DAS.
The OEM specific software system may further enable a user (e.g., designer) to create virtual placeholders for equipment (e.g., Radio Interface Module(s) (RIMs), Optical Interface Module(s) (OIMs), Remote Access Units, which may be Remote Antenna Units (RAUs) for example or other remote equipment, fiber connectivity module(s) (FCMs), etc.) to reserve and preconfigure settings for future planned equipment to be added later to the real DAS. For example, if only one wireless operator joins the system after the initial commissioning, but another wireless operator is expected to join the system at a later date, having virtual placeholders for equipment (e.g., gear) would allow additional equipment to be seamlessly added to the real DAS at a later date without the need for a change to most, if not all, of the system configuration settings.
The OEM specific software system enables a user to adjust or preset any of the user definable virtual settings in a virtual placeholder component (e.g., like equipment). The virtual settings for equipment (e.g., RAU, FCM link, other remote equipment, etc.) would be automatically uploaded (e.g., applied, activated, etc.) to equipment once connected or otherwise put in communication with the OEM specific software system (e.g., positioned inside of a slot(s) in a chassis, connected by optical fiber(s), upon manual activation of the component, etc.). Virtual placeholders for future equipment could be configured to not generate or mask associated system monitoring alarms, such as those for missing active equipment. The OEM specific software system may also automatically calculate and/or modify (e.g., compensate or adjust) attenuator or gain settings within placeholder and existing components to automatically compensate for anticipated gains or losses in equipment for reasons such as amplifier sharing in advance of placeholder components being replaced by equipment, or if placeholder or existing components are removed from the system.
Once completed, the virtual DAS can be uploaded onto and activated into the memory of the real DAS (e.g., real DAS manufacturer specific system controller hardware, new or existing equipment, etc.), whether on a new or existing system. In certain embodiments, the virtual DAS (e.g., profile, virtual design profile, etc.) has no impact on active or live system settings until the user “activates” or uploads the virtual settings into the live or active system hardware. The OEM specific system user interface or graphical user interface (GUI) could guide the installer(s) through the installation process of the DAS components so that the real DAS (e.g., active DAS, live DAS, etc.) matches that of the virtual DAS, such as by guiding an installer through connection of equipment (e.g., DAS components, DAS modules, etc.), their physical location(s) (e.g., placement of components within an equipment rack, placement of equipment modules within a chassis or chassis slot, etc.), etc. The OEM specific software system could also guide an installer as to RF, optical, and communication cable connections between multiple chassis and head-end to remote location or multi-building connections, where to physically place remote equipment on a map or building floor plan diagram, etc.
In particular, the OEM specific software system could provide feedback (e.g., confirmation messages, error messages, successful installation messages, unsuccessful installation messages, etc.) if the installer correctly or incorrectly installs or connects equipment (e.g., whether the equipment or module(s) are in the proper physical location, chassis, or chassis slot). Monitoring of installation by the OEM specific software system could be from electrical or optical connections between components, from location based service detection (e.g., Bluetooth transceivers, RFID, GPS), etc. Such feedback could include visual indicators such as text, symbols, color coded indicators, or audible indicators. The OEM specific software system could also provide guidance on installation of individual components, or multiple components simultaneously. For example, the installation instruction or guidance from the user interface could show a diagram of all modules that are to be installed inside of a chassis simultaneously. As the user slides modules individually inside of the chassis, the user could receive feedback that the installation of those modules was successful or unsuccessful.
The commissioning process (e.g., integration and/or optimization of live signals or protocols) for the real DAS could be simplified and completed more efficiently. For example, user definable downlink (DL) maximum expected input power settings or attenuator settings at the point of interface equipment could be commissioned through the OEM specific software system. DAS manufacturer specific settings can include single or multiple RF path configurations, power amplifier settings, attenuator settings, and expected maximum and idle RF input power settings at point of interface modules, such as RIM(s) or conditioners that connect with incoming signals provided by Wireless Operator equipment (e.g., Base Station(s), Small Cell(s), BBU(s), Remote Radio Head(s) (RRH) or Metro Cell(s), etc.). The RF path configuration settings can open and close switches within the electronics at the head-end, directing digital, RF, or optical signals within head-end components to remote equipment.
In this regard,
The real DAS 200 (e.g., optical fiber-based) has an antenna coverage area 220 that can be substantially centered about the RAU 206. The antenna coverage area 220 of the RAU 206 forms an RF coverage area 222. The HEU 208 is adapted to perform or to facilitate any one of a number of wireless applications, including but not limited to Radio-over-Fiber (RoF), radio frequency identification (RFID), wireless local-area network (WLAN) communication, public safety, cellular, telemetry, and other mobile or fixed services. Shown within the antenna coverage area 220 is a client device 226 in the form of a mobile device as an example, which may be a cellular telephone as an example. The client device 226 can be any device that is capable of receiving RF communication signals. The client device 226 includes an antenna 228 (e.g., a wireless card) adapted to receive and/or send electromagnetic RF communications signals.
With continuing reference to
Similarly, the antenna 234 is also configured to receive wireless RF communications from the client devices 226 in the antenna coverage area 220. In this regard, the antenna 234 receives wireless RF communications from the client devices 226 and communicates electrical RF communications signals representing the wireless RF communications to an E/O converter 236 in the RAU 206. The E/O converter 236 converts the electrical RF communications signals into uplink optical RF communications signals 224U to be communicated over the uplink optical fiber 212U. An 0/E converter 240 provided in the HEU 208 converts the uplink optical RF communications signals 224U into uplink electrical RF communications signals, which can then be communicated as uplink electrical RF communications signals 218U back to a network or other source. The HEU 208 in this embodiment is not able to distinguish the location of the client devices 226. The client device 226 could be in the range of any antenna coverage area 220 formed by an RAU 206.
With continuing reference to
With continuing reference to
With continuing reference to
In accordance with an exemplary embodiment, the service unit 242 in the HEU 208 can include an RF communications signal conditioner unit 240 for conditioning the downlink electrical RF communications signals 218D and the uplink electrical RF communications signals 218U, respectively. The service unit 242 can include a digital signal processing unit (“digital signal processor”) 246 for providing to the RF communications signal conditioner unit 244 an electrical signal that is modulated onto an RF carrier to generate a desired downlink electrical RF communications signal 218D. The digital signal processor 246 is also configured to process a demodulation signal provided by the demodulation of the uplink electrical RF communications signal 218U by the RF communications signal conditioner unit 244. The service unit 242 in the HEU 208 can also include an optional central processing unit (CPU) 248 for processing data and otherwise performing logic and computing operations, and a memory unit 250 for storing data, such as data to be transmitted over a WLAN or other network for example. The HEU 208 also includes the OEM specific software system 252, which could be stored in the memory unit 250 and accessed and processed by the CPU 248.
With continuing reference to
With continuing reference to
The first OIU 314 and second OIU 218 are connected via a fiber optic cable(s) to a first ICU 320 at remote site A 302. The ICU 320 is configured to provide power for powering the RAUs 206. The ICU 320 may be configured to provide the power in a composite cable along with the optical fibers carry signals from the HEU 208 to the RAUs 206. The first ICU 320 is connected to one or more RAUs 206 that transmit downlink electrical RF communications signals 258D (each RAU 206 may include RF expansion (remote expansion unit (RxU))). The second OIU 218 is also connected to an integrated head-end unit (IHU) 322 (with ACM) at remote site B 304 via an FMM-to-FRM fiber optic link. The IHU 322 (with ACM) is connected to an ICU 324 at remote subsite B 306 by a fiber optic cable(s). The ICU 324 is connected via a fiber optic cable(s) to one or more RAUs 206 that transmit downlink electrical RF communications signals 258D (each RAU 206 may include RF expansion (RxU)). The ICU 324 could also be connected via a fiber optic cable to a mid-power remote unit (MRU) 326 which then transmits downlink electrical RF communications signals 258D.
For example, in one embodiment, the RF paths for up to three service groups (e.g., service specific RIMs and/or OIMs) are configured. In this example, the service groups are configured both at the main head-end 300 (e.g., main head-end site) and at the remote location (e.g., site 1 504) so that the services from the RIMs at the main head-end 300 are extended to OIMs at the remote location and distributed by their connected RAU remotes.
In this example, as shown (similar to that of
The HEU 208 comprises a second service group 402, which includes RIM #1 module 408 and RIM #2 module 410, which are configured to transmit corresponding Services A,B to FMM 502 of OIU 500 of the main head-end 300. The OIU FMM 502 then transmits the supported services A,B to a FRM 508 of the HEU 506 of site 1 504. The site 1 HEU FRM 508 then transmits service A to OIM #5 module 424 of OIU 420. The OIM #5 module 424 then transmits the supported Services A,B to RAUs 206B at site 1 504, which then transmit Services A,B 258B to one or more client devices 226 (not shown).
The main head-end HEU 208 comprises a third service group 404, which includes RIM #1 module 412, RIM #2 module 414, RIM #3 module 416, and RIM #4 module 418, which are configured to transmit corresponding services A, B, C, D to FMM 502 of OIU 500 of the main head-end 300. The OIU FMM 502 then transmits the supported services A,B to a FRM 508 of the HEU 506 of site 1 504. The site 1 HEU FRM 508 then transmits service A to OIM #6 module 426 of OIU 420. The OIM #6 module 426 then transmits the supported Services A, B, C, D to RAUs 206C at site 1 504, which then transmit Services A, B, C, D 258C to one or more client devices 226 (not shown).
In certain embodiments, the HCM module 602 interface comprises a console port 604, one or more internal ports (e.g., first internal port 606A, second internal port 606B, third internal port 606C, fourth internal port 606D, etc.), a LAN port 608, and/or a local port 610. The console port (e.g., RJ45, serial port) could be used for local configurations. The internal ports 606A-606D (e.g., RJ45, 100 Mb Ethernet ports) are used for management of connected ACMs installed in OIU chassis, HEU chassis, and/or IHU chassis. The ACM module interface would have corresponding similar internal ports for connecting to the HCM module interface 602. The LAN port 608 (e.g., RJ45, 1 Gb Ethernet port) connects to corporate LAN for remote management. The local port 610 (e.g., RJ45, 1 Gb Ethernet port) could be used for local configuration and management.
The real DAS 200 discussed above can be configured using the OEM specific software system 252 also discussed above. More specifically, the OEM specific software system 252 in the real DAS 200 can be used to implement a live DAS configuration from a virtual DAS design. In this regard,
As discussed above, the virtual DAS is used to configure equipment of the real DAS 200.
To configure a new profile (via a GUI) using the OEM specific software system, a user first selects the profiles tab 1010, which then displays profile options area 1018 and a profiles list 1028. A profile is a profile configuration of a virtual DAS created for, linked with, and/or derived from a real DAS. In other words, a profile is a virtual DAS. In particular, the profile may include virtual DAS equipment and settings pertaining to physical installation, connection requirements, and/or commissioning, etc. The profiles tab 1010 electronically provides a GUI for a user to manage, create, delete, copy, and/or export a profile. Upon completing the profile configuration of the virtual DAS, the virtual DAS can then be activated, and the OEM specific software system 252 may guide an installer with step-by-step instructions on how to setup the real DAS, and may apply the profile configuration on the real DAS. After the profile has been successfully activated, the system can be adjusted via the configuration tab 1006.
The profile options area 1018 electronically displays to the user several options for interactive selection, such as creating a new profile 1020, creating a new profile from baseline 1022, creating a new profile from third party platform 1024, and/or importing a profile 1026. Creating a new profile 1020 enables the user to create a completely new profile. Creating a new profile from baseline 1022 enables a user to create a new profile based on the configuration of the existing online system in use. In other words, creating a new profile from baseline 1022 enables a user to quickly create a profile which can be subsequently edited according to site requirements. Creating a new profile from third party platform 1024 enables a user to load an electronic third party platform design (e.g., third party platform file), which could include antenna locations and/or antenna deployment. More specifically, the third party platform design could include floor layouts and/or setup design, and could be used as is or as a baseline configuration (to be further modified). Importing a profile 1026 enables a user to import a profile previously created and exported using the OEM specific software system 252.
The profiles list 1028 lists any profiles accessible to the user (e.g., by previous creation, by access rights, etc.), and may also display related information. For example, as illustrated in profile management page 1000 of
The OEM specific software system 252 also provides a profile administration subtab 1104 and a design subtab 1106. Under the profile administration subtab 1104 is a profile options area 1108 providing a GUI for the user to save a profile 1110, exit without saving 1112, and/or import a third party platform file 1114 containing location maps used to graphically display the geographical location of the site (e.g., building) and the layout of each floor. The maps are utilized and displayed in the “Location” main menu screen, where remotes (e.g., RAU, MRU) can be assigned and placed on the maps, representing their actual physical location in the floor plan.
The remotes information section 1212 enables a user to input the number of FMMs (e.g., 0-8) and/or the number of FRMs (e.g., 0-8), as well as select any additional add-ons, such as input the number of RAU5 units (e.g., 0-144), enable (or disable) the RAUX option if installed, enable (or disable) the RXU option if installed, etc. The remotes information section 1212 may also enable the user to input the number of MRUs (0-144) and/or select the bands supported by the one or more MRUs (e.g., PCS, AWS, AWS3, 700, WCS, Cell/ESMR, etc.).
In this regard,
More specifically, in step 2002, the OEM specific software system 252 electronically receives modifications to the site configuration settings of a virtual DAS. The step may include several substeps. In certain embodiments, in substep 2004, the OEM specific software system 252 electronically receives modifications to module owner settings of the virtual DAS. In substep 2006, the OEM specific software system 252 electronically receives modifications to (multiple-input multiple-output) (MIMO) setup settings of the virtual DAS. In substep 2008, the OEM specific software system 252 electronically receives modifications to RF path settings of the virtual DAS. In substep 2010, the OEM specific software system 252 electronically receives modifications to max input settings of the virtual DAS.
Continuing to step 2012, the OEM specific software system 252 electronically receives modifications to amplifier sharing settings of the virtual DAS. In step 2014, the OEM specific software system 252 electronically receives modifications to antenna settings of the virtual DAS. In step 2016, the OEM specific software system 252 electronically receives modifications to run-time settings of the virtual DAS. In step 2018, the OEM specific software system 252 electronically receives modifications to zone information settings of the virtual DAS. In step 2020, the OEM specific software system 252 electronically receives modifications to adjustment settings of the virtual DAS, and the process 2000 ends.
The configuration phase 2102 enables a user to configure site specific parameters. The amplifier sharing phase 2104 enables the user to allocate different percentages of amplification for same band RIMs. The antenna configuration phase 2106 enables a user to select the antenna source type (e.g., internal, external) for each of the installed modules (e.g., RAU/RAU5 units). The run-time options phase 2108 enables a user to expand and/or replace modules. The zone information phase 2110 enables a user to label each unit in the system to help classify and locate the different units (e.g., Building 1; Floor 1; Room 1). The adjustment phase 2112 enables a user to perform the adjustment procedure for uplink and downlink gains of the RIMs and OIMs, as well as to adjust the target output power of the services transmitted by the remote-end units.
In certain embodiments, the status indicator indicates to a user whether a particular phase is currently being configured (e.g., red as shown in the site configuration phase 2102), is completed (e.g., green as shown in the amplifier sharing phase 2104), or has not yet been performed (e.g., transparent as shown in the antenna configuration phase 2106, the run-time options phase 2108, the zone information phase 2110, and the adjustment phase 2112).
The site configuration page 2100 further includes a select service group drop down menu 2114 enabling a user to select a particular service group (as discussed in
The site configuration page 2200 could also include a first HEU chassis 2214 (with one or more modules 2220A-2220D), a second HEU chassis 2216 (with one or more modules 2222A-2222D), and/or a third HEU chassis 2218 (with one or more modules 2224A-2224C). Further, the site configuration page provides a carrier selection drop down menu 2226 requesting a user to select from one of a plurality of carriers (e.g., all, carrier 1, carrier 2, carrier 3, carrier 4, etc.). This enables a user to assign service specific RIM modules to one or more groups (e.g., corresponding to operators). The module owner subphase displays all connected HEUs and/or IHUs in a device view area. Unconfigured and unassigned RIM modules appear gray. All modules could be assigned to all groups or to specific groups (where groups include operators, carriers, etc.). Blue checkmarks could be applied to modules to indicate which modules are configured.
As shown in
A user can select a first module (e.g., RIM-M module 2306E) in the first chassis 2302, and a second module (e.g., RIM module 2308E) in the second chassis 2304, and then indicate whether the two modules should be disconnected (e.g., by clicking a UPAIR button 2310) or connected (e.g., by clicking a PAIR button 2312). In this way, for example, the user can connect pairs of RIM-M and RIM modules supporting the same band (e.g., AWS) which will then be extended to the corresponding remote unit (e.g., via the OIM). The OEM specific software system 252 can guide a user through connecting modules. For example, modules that are available for pairing can be identified to a user. When the RIM-M module 2306E in the first chassis 2302 is selected, the compatible RIM modules in the second chassis 2304 will appear gray (e.g., RIM module 2308E), and incompatible or unavailable modules will appear transparent (e.g., RIM modules 2308A-2308D).
This arrangement could be used where different combinations of services are distributed at various locations on the same floor of a building according to coverage requirements. The RF path configuration setup subphase determines the services distributed at the remote site. Note that each RIM can be configured for all service groups, and each RIM can be assigned to each OIM in a service group. The OEM specific software system 252 could be configured such that selecting a RIM-M module automatically selects the connected RIM module as well, and configures the RIM module for the same service group.
The site management page 2800 comprises a network topology tree 2802 which hierarchically displays the connected and available system devices and their status. The network topology tree 2802 could include status colors to indicate the status of each detected element (e.g., green represents OK, yellow represents a minor error, red represents a major error, gray represents no communication to a device set in base line, etc.). The DAS elements could comprise head-end units (e.g., HEU, OIU, IHU, etc.) and other elements (e.g., ACMs, RIMs, OIMs, RAUs, etc.) per site. In certain embodiments, the OEM specific software system 252 enables a user to specify the type of site (e.g., airport, high building, stadium, hospital, resident building, mall, campus, parking, hotel, etc.).
The site management page 2800 further comprises a campus view 2804 graphically displaying the sites (e.g., represented by icons indicating the overall status of each). The site management page 2800 further comprises a select service group drop down menu 2806, a device alarms section 2808, and a module info tab 2810, and a comment tab 2812. More specifically, the device alarms section 2808 comprises information corresponding to fault sourcing and provides alarm masking options (e.g., HW failure, adjustment failure, installation failure, SW release mismatch, connectivity, etc.). The module info tab 2810 provides device specific information, such as configurable parameters (e.g., service control, RF parameters) and/or general information (e.g., device name, firmware version, reset option, etc.). The comment tab 2812 enables a user to provide additional comments for a particular component selected.
The site management page 3100 includes an alarms history section 3120 (e.g., inconsistent version, over temperature, service 700, service CELL/ESMR, service AWS, service PCS, service WCS, adjustment fault, hw failure, overall status, etc.). The site management page further includes a module info tab 3122 (provides device version and identification definitions), a PAM alarms tab 3124 (displays specific alarms for each supported device), an alarms tab 3126 (displays device alarms, such as module specific alarms for fault sourcing), an RF parameters tab 3128 (includes configurable RF parameters (e.g., RIM gain, RAU output power, etc.) relevant to the selected device, and a comments tab 3130 (for entering additional information relevant to the selected device). The content of the alarms history section 3120, module info tab 3122, PAM alarms tab 3124, alarms tab 3126, RF parameters tab 3128, and comments tab 3130 varies depending on the DAS element selected (e.g., OIU, HEU, RAU, etc.). The alarms ensure that the real DAS is performing as the virtual DAS intended. If a problem is identified, the OEM specific software system identifies the source of the potential problem and guides a user through fixing the problem.
For an HCM module, the OEM specific software system 252 can alert a user (and help troubleshoot) as to the following device alarms: HW failure (indicates HCM faulty hardware), adjustment failure (indicates unsuccessful adjustment procedure), installation failure (indicates faulty physical connection between chassis), SW release mismatch (indicates that a module(s) in the system does not have the defined active release), connectivity (indicates faulty connectivity state in one of the (baseline) system modules), and overall status (indicates overall status of enabled (unmasked) alarms), etc.
For a site, the system can alert a user (and help troubleshoot) as to the following device alarms: adjustment failure (indicates unsuccessful adjustment procedure for a module(s) in the selected site), SW release mismatch (indicates module(s) in the selected site have been detected with mismatched software versions), connectivity (indicates disconnected modules have been detected in the site), and overall status (indicates overall status of enabled (unmasked) alarms), etc.
For an ACM, the OEM specific software system 252 can alert a user (and help troubleshoot) as to the following device alarms: inconsistent version (indicates that the module does not have the defined active release), over temperature (indicates ambient temperature inside the ACM is greater than a predefined threshold temperature (e.g., >75° C.)), HW failure (indicates faulty HW upon initialization or during operation), adjustment fault (indicates unsuccessful adjustment procedure for the selected module), power failure (indicates a power failure or overheating in one or more of the PSM (power supply module)), fan failure (indicates a fault in at least one of the fans in the fan module), Ext1/Ext2 Clock Failed (indicates failure in master reference clock in HEU and/or IHU units), pilot clock failed (indicates failure in reference in the pilot clock in the OIX expander for IHU and/or OIU), and Overall Status (indicates overall status of enabled (unmasked) alarms), etc.
For an ACM, the OEM specific software system 252 can also alert a user (and help troubleshoot) as to the following power alarms: temperature (indicates that the temperature of one or more of the PSM modules is greater than a predefined threshold (e.g., >+70° C.)), output under voltage (indicates that the ACM has detected an input voltage value less than a predefined threshold (e.g., <10.8V DC) from one or more of the PSM modules), and input under voltage (indicates that the ACM has detected an input voltage value below a predefined threshold (e.g., <60V AC) from one or more of the PSM modules), etc.
For a RIM, the OEM specific software system 252 can alert a user (and help troubleshoot) as to the following device alarms: inconsistent versions (indicates that the module does not have the defined active release), DL input power low (indicates that the BTS RF power input to the RIM is below a predefined threshold (e.g., at least 15 dB lower than the configured max expected power)), DL power overload (indicates that the BTS RF power input to the RIM is over a predefined threshold (e.g., at least 3 dB higher than the value measured during the adjustment procedure)), service OFF (indicates that service has been disabled), output power, over temperature (indicates ambient temperature inside the RIM is above a predefined threshold (e.g., >75° C.)), adjustment fault (unsuccessful adjustment procedure for the selected module), HW failure (indicates hardware problem during startup or during normal operation), overall clock alarms (indicates that at least one of the RIM-M clock alarms is set), and overall status (indicates overall status of enabled (unmasked) alarms), etc.
For a RIM, the OEM specific software system 252 can also alert a user (and help troubleshoot) as to the following clock alarms: UL synthesizer unlocked (indicates unlocked state of UL synthesizer), DL synthesizer unlocked (indicates unlocked state of DL synthesizer), and reference clock unlocked (indicates unlocked state of reference clock), etc.
For an OIM, the OEM specific software system 252 can alert a user (and help troubleshoot) as to the following device alarms: inconsistent version (indicates that the module does not have the defined active release), optical power low (indicates optical link power (PDI) is <0 dBm), over temperature (indicates that the ambient temperature in the OIM is over a predefined threshold (e.g., ≧75° C.)), adjustment fault (indicates unsuccessful adjustment procedure for the selected module), HW failure (indicates hardware problem during startup or during normal operation), and overall status (indicates overall status of enabled (unmasked) alarms), etc.
For a FMM/FRM, the OEM specific software system 252 can alert a user (and help troubleshoot) as to the following device alarms: inconsistent version (indicates that the module does not have the defined active release), optical power low (indicates that the optical power is below a predefined threshold (e.g., <−10.5 dBm)) MNG optical power low (indicates that the SFP Rx power is below a predefined threshold (e.g., <−34 dBm)), over temperature (indicates that the ambient temperature in the FMM/FRM is above a predefined threshold (e.g., >75° C.)), adjustment fault (indicates unsuccessful adjustment procedure for the selected module), HW failure (indicates HW problem during startup or during normal operation), and overall status (indicates overall status of enabled (unmasked) alarms), etc.
For a RAU, the OEM specific software system 252 can alert a user (and help troubleshoot) as to the following device alarms: inconsistent version (indicates that the module does not have the defined active release), over temperature (indicates that the ambient temperature in the RAU is above a predefined threshold (e.g., >75° C.)), service (indicates that service (e.g. LTE, CELL, etc.) has been disabled by user), adjustment fault (indicates unsuccessful adjustment procedure for the selected module), HW failure (indicates hardware problem during startup or during normal operation), and overall status (indicates overall status of enabled (unmasked) alarms), etc.
For RAU, the OEM specific software system 252 can also alert a user (and help troubleshoot) as to the following service alarms: DL out pwr low (indicates that the RF signal power is below a predefined threshold (e.g., ≦15 dB below the configured power level), UL in pwr high (indicates that the RF signal power is greater than required maximum expected power), and service off (indicates that service has been disabled by user), etc.
For a RXU, the OEM specific software system 252 can alert a user (and help troubleshoot) as to the following device alarms: inconsistent version (indicates that the module does not have the defined active release), over temperature (indicates that the ambient temperature in the RXU is above a predefined threshold (e.g., ≧75° C.)), Service LTE_MIMO/AWS_MIMO (indicates service disabled by user), adjustment fault (indicates unsuccessful adjustment procedure for the selected module), HW failure (indicates hardware problem during startup or during normal operation), synthesizer clock (indicates unlocked synthesizer clock), and overall status (indicates overall status of enabled (unmasked) alarms), etc.
For a RXU, the OEM specific software system 252 can also alert a user (and help troubleshoot) as to the following service alarms: DL out pwr low (indicates that the RF signal power is below a predefined threshold (e.g., ≦15 dB below the configured power level)), UL in pwr high (indicates that the RF signal power is greater than required maximum expected power), service off (indicates that service has been disabled by user), synthesizer DL (indicates that DL synthesizer state is detected as “unlocked”), and synthesizer UL (indicates that UL synthesizer state is detected as “unlocked”), etc.
For a MRU, the OEM specific software system 252 can alert a user (and help troubleshoot) as to the following MRU alarms: inconsistent version (indicates that the device does not have the defined active release), over temperature (indicates that the ambient temperature in the MRU is above a predetermined threshold (e.g., >65° C.)), service (indicates that service (e.g., 700, CELL, etc.) has been disabled by user), adjustment fault (indicates unsuccessful adjustment procedure for the selected module), HW failure (indicates a hardware component problem (including FAMs) during startup or during normal operation), and overall status (indicates overall status of enabled (unmasked) alarms), etc.
For a MRU, the OEM specific software system 252 can also alert a user as to the following PAM alarms: DL out pwr low (indicates that the RF signal power is less than a predefined threshold (e.g., ≦15 dB below the configured power level)), UL in pwr high (indicates that the RF signal power is greater than expected UL power and cannot be limited due to limiter reaching full capacity), service off (indicates that service has been disabled by user), VSWR (indicates that the PAM has reported a VSWR problem), shut down (indicates power amplifier module shut down), permanent shut down (indicates that 10 shut downs have occurred during the last 100 minutes), over temperature (indicates that the ambient temperature of the power amplifier modules is above a predetermined threshold (e.g., >65° C.)), out of slot (indicates that the PAM has been extracted from the slot), and over power (indicates that PA output power has exceeded maximum threshold (thresholds depends on band)), etc.
For a MRU, the OEM specific software system 252 could also alert a user as to the following additional alarms: door open (indicates that the MRU chassis door is open), fan velocity (indicates that the fan velocity is below the minimum threshold determined by the controller), over temperature when door open (indicates that the door has been open (e.g., for over 5 seconds) and that one of the PA modules is below the shut down limit temperature (e.g., 4° C. below the shut down limit)), power supply problem (indicates detected problem in power supply), low optical power (indicates that the detected optical power is lower than the configured threshold), OPTM-S over temperature alarm, cabinet door alarm (indicates that the door of the outdoor enclosure is open), and heat exchanger failure (indicates failure in the heat exchange unit of the outdoor enclosure), etc.
More specifically,
With continuing reference to
The RIMs 3602(1)-3602(T) may be provided in the central unit 3604 that support any frequencies desired, including but not limited to licensed US FCC and Industry Canada frequencies (824-849 MHz on uplink and 869-894 MHz on downlink), US FCC and Industry Canada frequencies (1850-1915 MHz on uplink and 1930-1995 MHz on downlink), US FCC and Industry Canada frequencies (1710-1755 MHz on uplink and 2110-2155 MHz on downlink), US FCC frequencies (698-716 MHz and 776-787 MHz on uplink and 728-746 MHz on downlink), EU R & TTE frequencies (880-915 MHz on uplink and 925-960 MHz on downlink), EU R & TTE frequencies (1710-1785 MHz on uplink and 1805-1880 MHz on downlink), EU R & TTE frequencies (1920-1980 MHz on uplink and 2110-2170 MHz on downlink), US FCC frequencies (806-824 MHz on uplink and 851-869 MHz on downlink), US FCC frequencies (896-901 MHz on uplink and 929-941 MHz on downlink), US FCC frequencies (793-805 MHz on uplink and 763-775 MHz on downlink), and US FCC frequencies (2495-2690 MHz on uplink and downlink).
With continuing reference to
The OIMs 3608(1)-3608(W) each include E-O converters to convert the downlink electrical communications signals 3606D(1)-3606D(S) into the downlink optical spectrum chunks 3610D(1)-3610D(S). The downlink optical spectrum chunks 3610D(1)-3610D(S) are communicated over downlink optical fiber communications medium 3612D to a plurality of remote units provided in the form of RAUs 3614(1)-3614(X). The notation “1-X” indicates that any number of the referenced component 1-X may be provided. O-E converters provided in the RAUs 3614(1)-3614(X) convert the downlink optical spectrum chunks 3610D(1)-3610D(S) back into the downlink electrical communications signals 3606D(1)-3606D(S), which are provided to antennas 3616(1)-3616(X) in the RAUs 3614(1)-3614(X) to user equipment (not shown) in the reception range of the antennas 3616(1)-3616(X).
E-O converters are also provided in the RAUs 3614(1)-3614(X) to convert uplink electrical communications signals 3620U(1)-3620U(X) received from user equipment (not shown) through the antennas 3616(1)-3616(X) into uplink optical spectrum chunks 3610U(1)-3610U(X). The RAUs 3614(1)-3614(X) communicate the uplink optical spectrum chunks 3610U(1)-3610U(X) over an uplink optical fiber communications medium 3612U to the OIMs 3608(1)-3608(W) in the central unit 3604. The OIMs 3608(1)-3608(W) include O-E converters that convert the received uplink optical spectrum chunks 3610U(1)-3610U(X) into uplink electrical communications signals 3622U(1)-3622U(X), which are processed by the RIMs 3602(1)-3602(T) and provided as uplink electrical communications signals 3622U(1)-3622U(X). The central unit 3604 may provide the uplink electrical communications signals 3622U(1)-3622U(X) to a source transceiver such as a base station or other communications system.
Note that the downlink optical fiber communications medium 3612D and uplink optical fiber communications medium 3612U connected to each RAU 3614(1)-3614(X) may be a common optical fiber communications medium, wherein for example, wave division multiplexing (WDM) may be employed to provide the downlink optical spectrum chunks 3610D(1)-3610D(S) and the uplink optical spectrum chunks 3610U(1)-3610U(X) on the same optical fiber communications medium.
In this regard, the computer system 3800 in
The exemplary computer system 3800 in this embodiment includes a processing device or processor 3802, a main memory 3804 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM), such as synchronous DRAM (SDRAM), etc.), and a static memory 3806 (e.g., flash memory, static random access memory (SRAM), etc.), which may communicate with each other via a data bus 3808. Alternatively, the processor 3802 may be connected to the main memory 3804 and/or static memory 3806 directly or via some other connectivity means. The processor 3802 may be a controller, and the main memory 3804 or static memory 3806 may be any type of memory.
The processor 3802 represents one or more general-purpose processing devices, such as a microprocessor, central processing unit, or the like. More particularly, the processor 3802 may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor implementing other instruction sets, or other processors implementing a combination of instruction sets. The processor 3802 is configured to execute processing logic in instructions for performing the operations and steps discussed herein.
The computer system 3800 may further include a network interface device 3810. The computer system 3800 also may or may not include an input 3812, configured to receive input and selections to be communicated to the computer system 3800 when executing instructions. The computer system 3800 also may or may not include an output 3814, including but not limited to a display, a video display unit (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device (e.g., a keyboard), and/or a cursor control device (e.g., a mouse).
The computer system 3800 may or may not include a data storage device that includes instructions 3816 stored in a computer-readable medium 3818. The instructions 3816 may also reside, completely or at least partially, within the main memory 3804 and/or within the processor 3802 during execution thereof by the computer system 3800, the main memory 3804 and the processor 3802 also constituting computer-readable medium. The instructions 3816 may further be transmitted or received over a network 3820 via the network interface device 3810.
While the computer-readable medium 3818 is shown in an exemplary embodiment to be a single medium, the term “computer-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable medium” shall also be taken to include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by the processing device and that cause the processing device to perform any one or more of the methodologies of the embodiments disclosed herein. The term “computer-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical medium, and magnetic medium.
The embodiments disclosed herein include various steps. The steps of the embodiments disclosed herein may be formed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the steps. Alternatively, the steps may be performed by a combination of hardware and software.
The embodiments disclosed herein may be provided as a computer program product, or software, that may include a machine-readable medium (or computer-readable medium) having stored thereon instructions, which may be used to program a computer system (or other electronic devices) to perform a process according to the embodiments disclosed herein. A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes: a machine-readable storage medium (e.g., ROM, random access memory (“RAM”), a magnetic disk storage medium, an optical storage medium, flash memory devices, etc.); and the like.
Unless specifically stated otherwise and as apparent from the previous discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing,” “computing,” “determining,” “displaying,” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data and memories represented as physical (electronic) quantities within the computer system's registers into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission, or display devices.
The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatuses to perform the required method steps. The required structure for a variety of these systems will appear from the description above. In addition, the embodiments described herein are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the embodiments as described herein.
Those of skill in the art will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithms described in connection with the embodiments disclosed herein may be implemented as electronic hardware, instructions stored in memory or in another computer-readable medium and executed by a processor or other processing device, or combinations of both. The components of the distributed antenna systems described herein may be employed in any circuit, hardware component, integrated circuit (IC), or IC chip, as examples. Memory disclosed herein may be any type and size of memory and may be configured to store any type of information desired. To clearly illustrate this interchangeability, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. How such functionality is implemented depends on the particular application, design choices, and/or design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present embodiments.
The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), or other programmable logic device, a discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. Furthermore, a controller may be a processor. A processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration).
The embodiments disclosed herein may be embodied in hardware and in instructions that are stored in hardware, and may reside, for example, in RAM, flash memory, ROM, Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), registers, a hard disk, a removable disk, a CD-ROM, or any other form of computer-readable medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a remote station. In the alternative, the processor and the storage medium may reside as discrete components in a remote station, base station, or server.
It is also noted that the operational steps described in any of the exemplary embodiments herein are described to provide examples and discussion. The operations described may be performed in numerous different sequences other than the illustrated sequences. Furthermore, operations described in a single operational step may actually be performed in a number of different steps. Additionally, one or more operational steps discussed in the exemplary embodiments may be combined. Those of skill in the art will also understand that information and signals may be represented using any of a variety of technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips, that may be references throughout the above description, may be represented by voltages, currents, electromagnetic waves, magnetic fields, or particles, optical fields or particles, or any combination thereof.
Unless otherwise expressly stated, it is in no way intended that any method set forth herein be construed as requiring that its steps be performed in a specific order. Accordingly, where a method claim does not actually recite an order to be followed by its steps, or it is not otherwise specifically stated in the claims or descriptions that the steps are to be limited to a specific order, it is in no way intended that any particular order be inferred.
It will be apparent to those skilled in the art that various modifications and variations can be made without departing from the spirit or scope of the invention.
Further, as used herein, it is intended that terms “fiber optic cables” and/or “optical fibers” include all types of single mode and multi-mode light waveguides, including one or more optical fibers that may be upcoated, colored, buffered, ribbonized and/or have other organizing or protective structure in a cable such as one or more tubes, strength members, jackets or the like. Likewise, other types of suitable optical fibers include bend-insensitive optical fibers, or any other expedient of a medium for transmitting light signals. An example of a bend-insensitive, or bend resistant, optical fiber is ClearCurve® Multimode fiber commercially available from Corning Incorporated. Suitable fibers of this type are disclosed, for example, in U.S. Patent Application Publication Nos. 2008/0166094 and 2009/0169163.
Many modifications and other embodiments of the embodiments set forth herein will come to mind to one skilled in the art to which the embodiments pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the description and claims are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. It is intended that the embodiments cover the modifications and variations of the embodiments provided they come within the scope of the appended claims and their equivalents. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
Claims
1. A system for implementing a live distributed antenna system (DAS) configuration from a virtual DAS design using an original equipment manufacturer (OEM) specific software system in a real DAS, comprising:
- a real DAS comprising signal distribution equipment, the signal distribution equipment comprising a processor, a memory coupled to the processor, and a display device coupled to the processor; and
- an OEM specific software system electronically stored in the memory of the real DAS, the OEM specific software system configured to: configure at least one virtual DAS setting for a virtual DAS; enforce upon the at least one virtual DAS setting OEM design constraints of at least one real setting of signal distribution equipment in the real DAS; generate at least one virtual DAS configuration file comprising the at least one virtual DAS setting for the virtual DAS; store the at least one virtual DAS configuration file in the memory at the real DAS; and modify the at least one real setting of the signal distribution equipment in the real DAS based on the at least one virtual DAS setting in the at least one virtual DAS configuration file.
2. The system of claim 1, wherein the OEM specific software system is configured to configure the at least one virtual DAS setting for the virtual DAS, by being configured to create the at least one virtual DAS setting for the virtual DAS.
3. The system of claim 2, wherein the OEM specific software system is configured to configure the at least one virtual DAS setting for the virtual DAS by being configured to import the at least one virtual DAS setting for the virtual DAS.
4. The system of claim 3, wherein the OEM specific software system is configured to configure the at least one virtual DAS setting for the virtual DAS by being configured to modify the at least one virtual DAS setting for the virtual DAS.
5. The system of claim 3, wherein the at least one real setting of the signal distribution equipment in the real DAS comprises at least one of an RF path configuration, power amplifier setting, attenuator setting, and RF input power setting.
6. The system of claim 3, wherein the at least one virtual DAS setting comprises a virtual DAS placeholder setting of a virtual placeholder component for configuring signal distribution equipment connected to the real DAS after activation of the virtual DAS and a virtual DAS existing setting of a virtual existing component for configuring signal distribution equipment connected to the real DAS upon activation of the virtual DAS.
7. The system of claim 6,
- wherein the at least one real setting of the signal distribution equipment in the real DAS comprises at least one real existing setting of real existing equipment and at least one real placeholder setting of real placeholder equipment, and
- wherein the OEM specific software system is configured to modify the at least one real setting of the signal distribution equipment in the real DAS based on the at least one virtual DAS setting in the at least one virtual DAS configuration file by being configured to: modify the at least one real existing setting of the real existing equipment electronically connected to the real DAS when the virtual DAS is activated based on the virtual DAS existing setting of the virtual existing component in the at least one virtual DAS configuration file, and modify at least one real placeholder setting of real placeholder equipment based on the virtual DAS placeholder setting of the virtual placeholder component in the at least one virtual DAS configuration file when the real placeholder equipment is electronically connected to the real DAS after the virtual DAS is activated.
8. The system of claim 3, wherein the OEM specific software system is further configured to guide a user through setup of the signal distribution equipment in the real DAS for execution of the virtual DAS in the real DAS.
9. The system of claim 8, wherein the setup of the signal distribution equipment in the real DAS comprises at least one of placement of signal distribution equipment in a signal distribution equipment rack, placement of signal distribution equipment modules within a real chassis, connections between signal distribution equipment, and geographic placement of signal distribution equipment for execution of the virtual DAS in the real DAS.
10. The system of claim 8, further comprising alerting, by the OEM specific software system, the user if the signal distribution equipment is improperly setup.
11. The system of claim 10, further comprising alerting, by the OEM specific software system, the user if the signal distribution equipment is properly setup.
12. A method for implementing a live distributed antenna system (DAS) configuration from a virtual DAS design using an original equipment manufacturer (OEM) specific software system in a real DAS, comprising:
- configuring, by an OEM specific software system in a real DAS, at least one virtual DAS setting for a virtual DAS;
- enforcing, by the OEM specific software system, upon the at least one virtual DAS setting OEM design constraints of at least one real setting of signal distribution equipment in the real DAS;
- generating, by the OEM specific software system, at least one virtual DAS configuration file comprising the at least one virtual DAS setting for the virtual DAS;
- storing, by the OEM specific software system, the at least one virtual DAS configuration file in memory at the real DAS; and
- modifying, by the OEM specific software system, the at least one real setting of the signal distribution equipment in the real DAS based on the at least one virtual DAS setting in the at least one virtual DAS configuration file.
13. The method of claim 12, wherein configuring, by the OEM specific software system in the real DAS, the at least one virtual DAS setting for the virtual DAS comprises creating the at least one virtual DAS setting for the virtual DAS.
14. The method of claim 13, wherein configuring, by the OEM specific software system in the real DAS, the at least one virtual DAS setting for the virtual DAS comprises importing the at least one virtual DAS setting for the virtual DAS.
15. The method of claim 14, wherein configuring, by the OEM specific software system in the real DAS, the at least one virtual DAS setting for the virtual DAS comprises modifying the at least one virtual DAS setting for the virtual DAS.
16. The method of claim 15, wherein the at least one real setting of the signal distribution equipment in the real DAS comprises at least one of an RF path configuration, power amplifier setting, attenuator setting, and RF input power setting.
17. The method of claim 15, wherein the at least one virtual DAS setting comprises a virtual DAS placeholder setting of a virtual placeholder component for configuring the signal distribution equipment connected to the real DAS after activation of the virtual DAS and a virtual DAS existing setting of a virtual existing component for configuring the signal distribution equipment connected to the real DAS upon activation of the virtual DAS.
18. The method of claim 17,
- wherein the at least one real setting of the signal distribution equipment in the real DAS comprises at least one real existing setting of real existing equipment and at least one real placeholder setting of real placeholder equipment, and
- wherein modifying, by the OEM specific software system, the at least one real setting of the signal distribution equipment in the real DAS based on the at least one virtual DAS setting in the at least one virtual DAS configuration file comprises: modifying, by the OEM specific software system, the at least one real existing setting of the real existing equipment electronically connected to the real DAS when the virtual DAS is activated based on the virtual DAS existing setting of the virtual existing component in the at least one virtual DAS configuration file, and modifying, by the OEM specific software system, the at least one real placeholder setting of the real placeholder equipment based on the virtual DAS placeholder setting of the virtual placeholder component in the at least one virtual DAS configuration file when the real placeholder equipment is electronically connected to the real DAS after the virtual DAS is activated.
19. The method of claim 14, further comprising guiding, by the OEM specific software system, a user through setup of the signal distribution equipment in the real DAS for execution of the virtual DAS in the real DAS.
20. The method of claim 19, wherein the setup of the signal distribution equipment in the real DAS comprises at least one of placement of the signal distribution equipment in a signal distribution equipment rack, placement of signal distribution equipment modules within a real chassis, connections between the signal distribution equipment, and geographic placement of the signal distribution equipment for execution of the virtual DAS in the real DAS.
21. The method of claim 19, further comprising alerting, by the OEM specific software system, the user if the signal distribution equipment is improperly setup.
22. The method of claim 19, further comprising alerting, by the OEM specific software system, the user if the signal distribution equipment is properly setup.
23.-33. (canceled)
Type: Application
Filed: Oct 24, 2016
Publication Date: Nov 2, 2017
Inventors: Lior Michael Kruh (Kfar Saba), Bryan Ray Roark (New Bern, NC)
Application Number: 15/332,603
