Field survey data preloading and synchronization for third-party systems

Abstract

The method includes receiving node site plan data from a first party application, validating the node site plan data based on one or more parameters of the validation, preloading at least a portion of the node site plan data into a second party application for field survey data collection, and receiving the field survey data from the second party application.

Description

[Technical field]

[0001] The present disclosure relates to a system for field survey data preloading and synchronization for third party systems and methods of using same. [Background technology]

[0002] A cellular network is a telecommunications system in which mobile devices (e.g., mobile telephone devices) communicate by radio waves through one or more local antennas at a cellular base station (e.g., cell tower). The coverage area served is divided into small geographic areas called cells. Each cell is served by a separate low-power multi-channel transceiver and antenna at the cell tower. Mobile devices within a cell communicate through that cell's antenna on an individual frequency channel assigned by the base station from a common pool of frequencies and frequencies used by the cellular network.

[0003] A radio access network (RAN) is a part of a communication system that implements radio access technology. The RAN resides between devices such as mobile phones, computers, or remote control machines and provides connectivity to a core network (CN). Depending on the standard, mobile phones and other wirelessly connected devices are variously known as user equipment (UE), terminal equipment (TE), mobile station (MS), etc. Summary of the Invention

[0004] In some embodiments, the method includes receiving node site plan data from a first party application, validating the node site plan data based on one or more parameters of the validation, preloading at least a portion of the node site plan data into a second party application for field survey data collection, and receiving the field survey data from the second party application.

[0005] In some embodiments, an apparatus comprises a processor and a memory storing instructions that, when executed by the processor, cause the processor to receive node-site planning data from a first-party application, validate the node site planning data based on one or more parameters of validation, pre-load at least a portion of the node site planning data into a second-party application for field-survey data gathering, and receive the field survey data from the second-party application.

[0006] In some embodiments, a non-transitory computer readable medium is provided having instructions stored thereon that, when executed by a processor, cause the processor to receive node site plan data from a first party application, validate the node site plan data based on one or more parameters of the validation, pre-load at least a portion of the node site plan data into a second party application for field survey data collection, and receive field survey data from the second party application.

[0007] Aspects of the present disclosure will be understood from the following detailed description when read in conjunction with the accompanying drawings. In accordance with standard industry practice, various features (elements, parts, shapes, etc.) have not been drawn to scale. In some embodiments, dimensions of various features are arbitrarily increased or decreased for clarity of discussion. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a schematic diagram of a system for field survey data preload and synchronization (FSDPS), according to some embodiments.

[0009] [Diagram 2] FIG. 1 is a block diagram of an FSDPS system, according to some embodiments.

[0010] [Diagram 3] FIG. 1 is a data flow diagram of a method for preloading and synchronizing field survey data according to some embodiments. [Figure 3c] FIG. 1 is a data flow diagram of a method for preloading and synchronizing field survey data according to some embodiments.

[0011] [Figure 4] FIG. 1 is a high-level functional block diagram of a processor-based system according to some embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] The following disclosure provides many different embodiments or examples for implementing the particular features of the subject matter discussed. Examples of components, values, operations, materials, arrangements, etc. are described below to simplify the disclosure. These are, of course, examples and are not intended to be limiting. Other components, values, operations, materials, arrangements, etc. are contemplated. For example, forming a first feature on a second feature (element, part) in the following description includes embodiments in which the first feature and the second feature are formed in direct contact, and further includes embodiments in which an additional feature is formed between the first feature and the second feature such that the first feature and the second feature cannot be in direct contact. In addition, the present disclosure repeats reference numbers and / or letters in many examples. This repetition is for brevity and clarity and is not intended to determine a relationship between the various embodiments and / or configurations discussed.

[0013] Additionally, spatially relative terms such as below, below, lower, above, upper, etc. are used herein for ease of description to describe the relationship of one element or feature as shown in the figures to another element(s) or feature(s). The device may be otherwise oriented (rotated 90 degrees or at other orientations) and the spatially relative descriptors used herein similarly interpreted accordingly.

[0014] In some embodiments, a Field Survey Data Preload and Synchronization (FSDPS) system for maintaining data integrity through automated FSDPS between third party systems is discussed in the embodiments of the present disclosure.

[0015] A wireless site survey, sometimes referred to as a radio frequency (RF) site survey, field survey, or wireless survey, is the process of planning and designing a wireless network to provide a wireless solution that provides the required wireless coverage, data rates, network capacity, roaming capabilities, and quality of service (QoS). The survey typically includes a site visit to test for RF interference, identifying optimal locations for access points, analyzing building floor plans, inspecting facilities, and using site survey tools. Interviews with information technology (IT) management and end users of the wireless network are also used to determine the design parameters of the wireless network.

[0016] In other approaches, there was no way to preload data from third-party systems with various configurations and compatibilities. In other approaches, data synchronization was performed manually using spreadsheet imports or manual entry. In other approaches, data synchronization between different systems with different architectures was performed manually using spreadsheets, which was not user-friendly and was unreliable.

[0017] In some embodiments, a Field Survey Data Preload and Synchronization (FSDPS) system discussed in various embodiments throughout preloads and populates survey data directly into third party tools, which reduces or eliminates the risk of inaccurate manual data insertion by users and reduces the time it takes to manually enter data. In some embodiments, the FSDPS system maintains data state and integrity between different systems owned by different companies. In some embodiments, an algorithm fetches survey data from a first system, parses the data into multiple parts, and updates the data across multiple third party systems.

[0018] In a non-limiting example, the FSDPS system fetches data from party one's system, stores the data in the FSDPS system, fetches data from party two's system, and simultaneously updates at least a portion of the relevant data in party three's system.

[0019] In other approaches, a field engineer manually inputs data into a field survey application (e.g., Spectra Pro App (aka CPI)) and the information is transmitted from the field survey application to the wireless network system. In some embodiments, to overcome the risk of inaccurate manual data input into the field survey application (e.g., a field engineer periodically transmits inaccurate site-related field site data due to manual error), preloading is applied between the wireless network system and the field survey application.

[0020] In some embodiments, the data is preloaded into an FSDPS system owned by a different organization (not the originator of the data), substantially eliminating manual entry errors. In some embodiments, after preloading, at least a portion of the data updates a field survey application with parameter data such as site longitude and latitude, site identification, address, etc. A user enters data regarding the remaining parameters such as antenna details, photos of the actual site, and other suitable parameters within the scope of the embodiment. In some embodiments, after the data is verified as correct by the FSDPS system, third parties using the data are updated.

[0021] In some embodiments, manual data entry is limited and automated processes facilitate efficient data sharing, with data updated in multiple systems in response to successful data requests. In some embodiments, the FSDPS system automatically schedules triggers (e.g., every 11 hours) for each data request from a field survey application (e.g., CPI). In some embodiments, based on a data availability request, the FSDPS system updates data from one party to multiple parties.

[0022] In some embodiments, the data is entered into a centralized database (DB) and shared with other parties. In some embodiments, the FSDPS system requests site plan data from a site planner. This communication is secured with a session token. In response to the session token being incorrect, the communication cannot be established. In response to the session token being correct, the FSDPS system receives an extensible markup language (XML) file from a centralized database where site details are available. In some embodiments, the XML is parsed and data is retrieved from the centralized DB to create the site in the FSDPS system.

[0023] In some embodiments, in response to a site being created in the FSDPS system, data is preloaded into a field survey application (e.g., a Spectra third party system). This preloaded data is used by the field engineer to complete the survey of the desired site. The preloaded data saves the field engineer's time and reduces the risk of data corruption or inaccurate data entry. In some embodiments, after the field survey is completed, the field survey application synchronizes the data back to the FSDPS system. The FSDPS system updates the initial survey site plan data with the final data coming from the field survey application. In some embodiments, the same data is updated in a centralized DB to maintain data integrity between each party in the FSDPS system.

[0024] FIG. 1 is a schematic diagram of a system 100 for field survey data preload and synchronization (FSDPS), according to some embodiments.

[0025] The FSDPS system 100 includes a CN 102 communicatively connected to a RAN 104 via a transport network (TN) 106, which is communicatively connected to base stations 108A and 108B (hereinafter base stations 108) having antennas 110 wirelessly connected to UEs 112 located within geographic coverage cells 114A and 114B (hereinafter geographic coverage cells 114). The CN 102 includes one or more service provider(s) 116, third-party vendors 118, and an FSDPS module 120.

[0026] The CN 102 (also known as a backbone) is the portion of a computer network that interconnects networks and provides a pathway for exchanging information between different local area networks (LANs) or sub-networks. In some embodiments, the CN 102 ties diverse networks together across a wide geographic area, in different buildings in a campus environment, or even within the same building.

[0027] In some embodiments, the RAN 104 is a global system for mobile communications (GSM) RAN, a GSM / EDGE RAN, a universal mobile telecommunications system (UMTS) RAN (UTRAN), an evolved UMTS terrestrial radio access network (E-UTRAN), an open RAN (O-RAN), or a cloud-RAN (C-RAN). The RAN 104 resides between the UE 112 (e.g., a mobile phone, a computer, or any remote control machine) and the CN 102. In some embodiments, the RAN 104 is a C-RAN for simplified representation and explanation. In some embodiments, base band units (BBUs) replace the C-RAN.

[0028] In traditional distributed cellular networks, the equipment at the bottom and top of the base station at the cell site is the BBU. The BBU is a radio device that links the UE to the CN and processes billions of bits of information per hour. BBUs are traditionally located in enclosures or shelters located at the bottom of the base station. In contrast, C-RAN uses the large signal carrying capacity of optical fiber to centralize many BBUs in dedicated pool locations or base stations. This reduces the amount of equipment at the base station and provides many other benefits (such as lower latency).

[0029] In a hierarchical telecommunications network, the TN 106 of the FSDPS system 100 includes the intermediate link(s) between the CN 102 and the RAN 104. The two main methods of mobile backhaul implementations are fiber-based backhaul and wireless point-to-point backhaul. Other methods such as copper-based wireline, satellite communication, and point-to-multipoint wireless technologies are being phased out as capacity and latency requirements become higher in 4G and 5G networks. Backhaul refers to the side of the network that communicates with the Internet. The connection between the base station 108 and the UE 112 begins with the TN 106 connected to the CN 102. In some embodiments, the TN 106 includes wired, optical fiber, and wireless components. The wireless section includes the use of microwave bands, mesh and edge network topologies that use high capacity wireless channels to send packets over microwave or fiber links.

[0030] In some embodiments, the base stations 108 are lattice (or self-supporting) towers, guyed towers, monopole towers, and concealed towers (e.g., towers designed to resemble trees, cacti, water towers, signs, street lights, and other types of structures). In some embodiments, the base stations 108 are cellular-enabled mobile device sites where antennas and electronic communication equipment are typically placed on radio masts, towers, or other elevated structures to create cells (or adjacent cells) in the network. The elevated structures typically support antenna(s) 110 and a set (or sets) of transmitters / receivers (transceivers), digital signal processors, control electronics, remote radio heads (RRHs), primary power sources, backup power sources, and shelters. Base stations are known by other names such as base transceiver stations, mobile phone masts, or cell towers. In some embodiments, the base stations are replaced with other edge devices configured to wirelessly communicate with UEs. Edge devices provide an entry point into a service provider CN, such as CN 102. Examples include routers, routing switches, integrated access devices (IADs), multiplexers, and various metropolitan area network (MAN) and wide area network (WAN) access devices.

[0031] In at least one embodiment, the antenna(s) 110 are sector antennas. In some embodiments, the antenna(s) 110 are a type of directional microwave antenna with a sector-shaped radiation pattern. In some embodiments, the sector angle of the arc is designed at 60°, 90°, or 120° with a few extra degrees to ensure overlap. Furthermore, sector antennas are mounted in multiples if wider coverage or full circle coverage is desired. In some embodiments, the antenna(s) 110 are rectangular antennas used to transmit and receive waves or data between mobile devices or other devices and base stations. Rectangular antennas are sometimes referred to as panel antennas or radio antennas. In some embodiments, the antenna(s) 110 are circular antennas. In some embodiments, the antenna 110 operates at microwave or ultra-high frequency (UHF) frequencies (300 MHz to 3 GHz). In other examples, antenna(s) 110 are selected for their size and directionality. In some embodiments, antenna(s) 110 are multiple-input, multiple-output (MIMO) antennas that simultaneously transmit and receive two or more data signals over the same wireless channel by taking advantage of multipath propagation.

[0032] In some embodiments, the UE 112 is a computer or computing system. Additionally or alternatively, the UE 112 has a liquid crystal display (LCD), light emitting diode (LED), or organic light emitting diode (OLED) screen interface (e.g., user interface (UI) 422 (FIG. 4)) that functions as a touch screen interface with digital buttons and a keyboard (or physical buttons and a physical keyboard). In some embodiments, the UE 112 connects to the Internet and interconnects with other devices. Additionally or alternatively, the UE 112 incorporates integrated cameras, the ability to make and receive voice and video telephone calls, video games, and global positioning system (GPS) capabilities. Additionally or alternatively, the UE runs an operating system (OS) that allows capability-specific third-party apps to be installed and executed. In some embodiments, the UE 112 is a computer (such as a tablet computer, a netbook, a digital media player, a digital assistant, a graphing calculator, a handheld game console, a handheld personal computer (PC), a laptop, a mobile Internet device (MID), a personal digital assistant (PDA), a pocket calculator, a portable media player, or an ultra-mobile personal computer), a mobile phone (such as a camera phone, a feature phone, a smartphone, or a phablet), a digital camera (such as a digital camcorder, or a digital still camera (DSC), a digital video camera (DVC), or a front-facing camera), a pager, a personal navigation device (PND), a wearable computer (such as a calculator watch, a smart watch, a head mounted display, an earpiece, or a biometric device), or a smart card.

[0033] In some embodiments, the geographic coverage cell 114 includes a shape and a size. In some embodiments, the geographic coverage cell 114 is a macrocell (covering 1 Km to 30 Km), a microcell (covering 200 m to 2 Km), or a picocell (covering 4 m to 200 m). In some embodiments, the geographic coverage cell is circular, elliptical (FIG. 1), sector-shaped (fan-shaped), or lobe-shaped, although the geographic coverage cell 114 may be configured in almost any shape or size. The geographic coverage cell 114 represents the geographic area in which the antenna 110 and the UE 112 are configured to communicate. The coverage depends on multiple factors. For example, the coverage depends on the orography (i.e., mountains), buildings, technology, radio frequencies, and most importantly for two-way telecommunications, the sensitivity and transmission efficiency of the UE 112, etc. Some frequencies provide better regional coverage, while other frequencies penetrate obstacles such as buildings in cities better. The ability of a UE to connect to a base station depends on the strength of the signal.

[0034] Service provider(s) 116 are companies, vendors, customers, or organizations that provide direct Internet backbone access to Internet service providers and sell bandwidth or network access to subscribers (who use UEs), typically by providing access to Network Access Points (NAPs). Service providers are sometimes referred to as backbone providers, Internet providers, or vendors. Service providers include telecommunications companies, data carriers, wireless communication providers, Internet service providers, and cable television operators that offer high-speed Internet access.

[0035] Service provider(s) 116 often use Radio Access Network Planning (RAN Planning) to propose site locations (e.g., base stations, edge devices, or any other communication devices within the scope of the embodiments herein), configurations, and settings of new network nodes (either redistribution points or communication endpoints) to be deployed within the wireless network. The main objectives of wireless network planning are to obtain sufficient coverage over a target area, ensure satisfactory service quality and low bit error rate, provide the required network capacity with low service blocking, satisfactory user throughput and low dropped call rate, and implement an economically efficient network infrastructure (i.e., the minimum number of sites and transmitters required to satisfy the coverage, quality, and capacity requirements).

[0036] The above objectives of wireless network planning are met by appropriate selection of site locations and configuration of cell settings and parameters including antenna model, antenna height, azimuth and tilt angles, and other suitable equipment and parameters within the scope of the embodiments. Site selection and configuration is useful because the number of cells to be deployed in urban areas is much higher than with previous wireless technologies.

[0037] The next step in the RAN planning process involves the specification of technology-dependent parameters. Deriving the neighbor list for new sites is also part of the RAN planning process. Many other standardized and vendor-specific parameters are typically set to nominal values ​​at rollout and continuously adjusted as cells are operational and key performance indicators (KPIs) are available. Efficient RAN planning is reflected in satisfied subscribers (subscriber satisfaction), lower infrastructure costs, and lower optimization efforts after the network rollout.

[0038] Third party vendor(s) 118 are any business that provides goods or services to the FSDPS system 100. Generally, a supply chain vendor manufactures inventory / stock items and sells them to the next link in the chain. In some embodiments, the vendor is the entity that provides the field survey data. In some embodiments, the vendor is a networking device manufacturer. In some embodiments, the vendor is the entity that provides the site plan data.

[0039] In some embodiments, the FSDPS module 120 is configured to preload and synchronize data to and from third party systems for field surveys and maintain data integrity through automation. In some embodiments, the FSDPS module 120 maintains data state and integrity between different systems owned by different companies, such as the service provider(s) 116. In some embodiments, the FSDPS algorithms fetch survey data from a first system, parse the data into multiple parts, and update the data across multiple third party systems. In some embodiments, the FSDPS module 120 fetches site plan data from a first party system, stores the data in a centralized DB, fetches field survey data from a second party system, and simultaneously updates at least some of the associated data in the third party systems.

[0040] FIG. 2 is a block diagram of an FSDPS system 200 according to some embodiments.

[0041] FIG. 3 is a data flow diagram of a method 300 for preloading and synchronizing field survey data (PSFSD), according to some embodiments.

[0042] In some embodiments, FSDPS 200 is similar to FSDPS 100. In some embodiments, PSFSD method 300 describes process tasks for preloading and synchronizing planning and field survey data. Although the operations of PSFSD method 300 are described and shown as having a particular order, each operation in PSFSD method 300 is configured to be performed in any order unless otherwise specified. PSFSD method 300 is implemented as a set of operations, such as operations 302-330. To further aid in understanding PSFSD method 300, PSFSD method 300 will be described with reference to FIGS. 2-3.

[0043] In operation 302 of PSFSD method 300, site plan data is created (or uploaded). In FIG. 2, user 222 creates the site plan data using planning application 224A (FIG. 3). After the site plan data is created, the site plan data is available in site plan DB 224B. In some embodiments, user 222 is a representative of a service provider (e.g., one or more of service providers 116). Planning application 224A includes site plan DB 224B in which the site plan data is stored locally. In some embodiments, planning application 224A and planning DB 224B are located separately. The process transitions from operation 302 to operation 304.

[0044] In operation 304 of the PSFSD method 300, the FSDPS module 220A sends a session token request to the planning application 224A using the authentication information. In computer science, a session identifier, session ID, or session token is a piece of data used in network communications (often via the Hypertext Transfer Protocol (HTTP)) to identify a session, a series of related message exchanges. Session tokens are configured to be used when the communication infrastructure uses a stateless protocol such as HTTP. Session tokens are typically granted to visitors on their first visit to a site. Because session tokens are often used to identify users logged into a website, session tokens differ from user IDs in that sessions are typically short-lived (expiring after a pre-set amount of inactivity, which can be minutes or hours) and become invalid after certain goals are met. Session tokens are typically randomly generated strings, reducing the probability of obtaining a valid one by a brute-force search. In some embodiments, the FSDPS module 220A is similar to the FSDPS 120. The process transitions from operation 304 to operation 306 or operation 308.

[0045] In response to the session token being incorrect, a failure response is sent to the FSDPS module 220A and communication is not established, at operation 306 of the PSFSD method 300. In the case of a failure response, the operation of the method 300 ends at operation 306.

[0046] In operation 308 of the PSFSD method 300, in response to the session token passing, a success response is sent to the FSDPS module 220A and communication is established. The process transitions from operation 308 to operation 310.

[0047] In operation 310 of the PSFSD method 300, the FSDPS module 220A requests site plan data from the planning application 224B. In some embodiments, the request is for XML data for site and node creation. The process transitions from operation 310 to operation 312.

[0048] In operation 312 of the PSFSD method 300, the FSDPS module 220A receives an XML file from the planning application 224B in which site details are available. In some embodiments, the planning application 224A provides 196 data parameters in XML format for each planned site to the FSDPS module 220A. In some embodiments, the FSDPS module 220A stores the plan XML file in the FSDPS 220B. The process transitions from operation 312 to operation 314 or operation 316.

[0049] At operation 314 of the PSFSD method 300, the internal validation fails. In some embodiments, a site administrator (not shown) performs a validation failure on the planning data received from the planning application 224A. In some embodiments, the site administrator determines whether one or more required fields in the XML data contain data. In some embodiments, the site administrator determines whether a unique serial number is in the data. In some embodiments, the site administrator determines whether a unique application tracking ID is present. In some embodiments, the site administrator validates that the data is in XML format. In some embodiments, the site administrator requires one or more of the validations above to validate the data. In response to the data failing validation by the site administrator, the process proceeds to operation 318 where a notification of failure is sent to the user 222. In some embodiments, the notification of failure is an email notification that includes a reason explaining why the site or node was not created. The method 300 then ends at operation 318.

[0050] At operation 316 of the PSFSD method 300, the internal validation is successful (passes). In some embodiments, the XML plan data is used to create sites in the FSDPS module 220A. In some embodiments, sites and nodes are created by a site administrator who successfully parses the XML from the plan application 224A. The process transitions from operation 316 to operation 320.

[0051] In operation 320 of the PSFSD method 300, in response to the sites and nodes being created in the FSDPS module 220A, the FSDPS module 220A preloads the same planning data into the field survey application 226A. In some embodiments, the preloaded planning data is stored in the field survey DB 226B (FIG. 2). This preloaded data is used by the field engineer to complete one or more surveys of the planned sites. The preloaded data saves the field engineer time and also reduces the risk of data corruption or erroneous data entry because at least a portion of the field survey information is already in the field survey application 226A.

[0052] In operation 322 of the PSFSD method 300, the FSDPS module 220A stores the site and node fields in the central database 228 to maintain data integrity between all involved parties, such as the planning application 224A, the FSDPS module 220A, and the field survey application 226A. The process transitions from operation 322 to operation 324.

[0053] At operation 324 of the PSFSD method 300, in response to the field survey being completed, the field survey data is sent to and synchronized with the FSDPS module 220A using the field survey application 226A. In some embodiments, the field survey application 226A sends a trigger when it is powered up in the field. In some embodiments, the field survey data is in XML format. In some embodiments, the trigger is automatically scheduled 11 hours later for a data request from the field survey application 226A. The process transitions from operation 324 to operation 326 or 330.

[0054] At operation 326 of the PSFSD method 300, another internal validation of the field survey data is performed by the FSDPS module 220A. In some embodiments, a site administrator (not shown) performs a failure validation on the field survey data received from the field survey application 226A. In some embodiments, the site administrator determines whether one or more required fields in the XML data contain data. In some embodiments, the site administrator determines whether a unique serial number is in the data. In some embodiments, the site administrator determines whether a unique application tracking ID is present. In some embodiments, the site administrator validates that the data is in XML format. In some embodiments, the site administrator requires one or more of the above validations to validate the data. In response to the data being unsuccessfully validated by the site administrator, the process proceeds to operation 328 where a failure notification is sent to the user 222. In some embodiments, the failure notification is an email notification that includes a reason explaining why the site or node was not created. The method 300 then ends at operation 318.

[0055] In operation 330 of the PSFSD method 300, in response to the field survey data being verified, the FSDPS module 220A updates the planning data with the field survey data from the field survey application 226A. In some embodiments, the planning data is updated in the planning application 224A and / or the planning DB 224B to maintain data integrity within the FSDPS system 200.

[0056] In some embodiments, planning / field survey data is obtained by spectrum access system (SAS) DB 230 and other third parties such as manufacturer DB 232 .

[0057] In some embodiments, the SAS DB 230 communicates with the FSDPS module 220A to determine whether sites and nodes are compliant with the citizens broadband radio service (CBRS). The SAS is a cloud-based service that manages wireless communications for devices transmitting in the CBRS band (a 150 MHz wide broadcast band located in the 3550-3700 MHz band) to prevent harmful interference to higher priority users. The SAS is an automated radio spectrum coordinator responsible for allocating spectrum channels and their associated transmit power to CBRS Service Devices (CBSDs). CBSDs require permission from the SAS before they can begin transmitting in the CBRS band. The SAS uses information provided by Environmental Sensing Capability (ESC) sensors to manage the spectrum and ensure that FCC rules are always enforced while giving maximum commercial access to the available spectrum.

[0058] In some embodiments, the manufacturer DB 232 communicates with the FSDPS module 220A and / or the FSDPS DB 220B to obtain data from devices being monitored in the field. Thus, vendors who manufacture devices for networking can monitor how their devices are performing through field survey data.

[0059] 4 is a block diagram of a field survey data preload and synchronization (FSDPS) processing circuit 400, according to some embodiments. In some embodiments, the FSDPS processing circuit 400 is a general-purpose computing device that includes a hardware processor 402 and a non-transitory computer-readable storage medium 404. The storage medium 404 is encoded with, among other things, computer program code 406 (i.e., a set of executable instructions, such as an algorithm or method 300). That is, the storage medium 404 stores the computer program code 406. Execution of the instructions 406 by the hardware processor 402 represents (at least in part) a field survey data application preload and synchronization that implements some or all of the methods described herein (hereinafter referred to as processes and / or methods) according to one or more embodiments.

[0060] The processor 402 is electrically coupled to a computer readable storage medium 404 via a bus 408. The processor 402 is further electrically coupled to an I / O interface 410 by the bus 408. A network interface 412 is further electrically coupled to the processor 402 via the bus 408. The network interface 412 is connected to a network 414 such that the processor 402 and the computer readable storage medium 404 connect to external elements via the network 414. The processor 402 is configured to execute computer program code 406 encoded on the computer readable storage medium 404 to enable the FSDPS processing circuit 400 to perform some or all of the processes and / or methods mentioned. In one or more embodiments, the processor 402 is a central processing unit, a multiprocessor, a distributed processing system, an application specific integrated circuit (ASIC), and / or other suitable processing unit.

[0061] In one or more embodiments, computer readable storage medium 404 is an electronic, magnetic, optical, electromagnetic, infrared, and / or semiconductor system (or apparatus or device). For example, computer readable storage medium 404 includes a semiconductor or solid state memory, a magnetic tape, a removable computer diskette, a random access memory (RAM), a read only memory (ROM), a rigid magnetic disk, and / or an optical disk. In one or more embodiments using an optical disk, computer readable storage medium 404 includes a compact disk read only memory (CD-ROM), a compact disk read / write (CD-R / W), and / or a digital video disk (DVD).

[0062] In one or more embodiments, the storage medium 404 stores computer program code 406 configured to enable the FSDPS processing circuit 400 to perform some or all of the processes and / or methods mentioned. In one or more embodiments, the storage medium 404 further stores information such as algorithms that enable the execution of some or all of the processes and / or methods mentioned.

[0063] FSDPS processing circuitry 400 includes an I / O interface 410. I / O interface 410 is coupled to external circuitry. In one or more embodiments, I / O interface 410 includes a keyboard, keypad, mouse, trackball, trackpad, touch screen, and / or cursor direction keys for communicating information and commands to processor 402.

[0064] The FSDPS processing circuit 400 further includes a network interface 412 coupled to the processor 402. The network interface 412 allows the FSDPS processing circuit 400 to communicate with a network 414 to which one or more other computer systems are connected. The network interface 412 includes a wireless network interface, such as BLUETOOTH, WIFI, WIMAX, GPRS, or WCDMA, or a wired network interface, such as ETHERNET, IEEE-864, etc. In one or more embodiments, some or all of the processes and / or methods mentioned are implemented in more than one FSDPS processing circuit 400.

[0065] The FSDPS processing circuit 400 is configured to receive information via an I / O interface 410. The information received via the I / O interface 410 includes one or more of instructions, data, design rules, and / or other parameters for processing by the processor 402. The information is transferred to the processor 402 via a bus 408. The FSDPS processing circuit 400 is configured to receive information regarding a UI 422 via the I / O interface 410. The information is stored in a computer-readable medium 404 as a user interface (UI) 422.

[0066] In some embodiments, some or all of the processes and / or methods mentioned are implemented as a standalone software application for execution by a processor. In some embodiments, some or all of the processes and / or methods mentioned are implemented as a software application that is part of an additional software application. In some embodiments, some or all of the processes and / or methods mentioned are implemented as a plug-in to a software application.

[0067] In some embodiments, these processes are implemented as functions of a program stored on a non-transitory computer-readable recording medium. Examples of non-transitory computer-readable recording media include, but are not limited to, one or more of external / removable and / or internal / built-in storage or memory units, such as optical disks, such as DVDs, magnetic disks, such as hard disks, semiconductor memories, such as ROMs, RAMs, memory cards, and the like.

[0068] In some embodiments, the method includes receiving node site plan data from a first party application, validating the node site plan data based on one or more parameters of the validation, preloading at least a portion of the node site plan data into a second party application for field survey data collection, and receiving the field survey data from the second party application.

[0069] In some embodiments, the method further includes creating node sites based on the node site planning data and storing the node sites or the node site planning data in a centralized database.

[0070] In some embodiments, the method further includes validating the field survey data from the second party application based on one or more parameters of the validation.

[0071] In some embodiments, the method further includes, in response to a failed validation of the field survey data, sending a communication to the first party describing the failed validation.

[0072] In some embodiments, the method further includes, in response to successful validation of the field survey data, sending updates to the node site plan data to the first party application, the node site plan data being updated based on the received field survey data.

[0073] In some embodiments, the method further includes sending a session token request to the first party application prior to receiving the node site planning data from the first party application.

[0074] In some embodiments, the method further includes receiving a valid token response from the first party application or receiving an invalid token response from the first party application.

[0075] In some embodiments, the method further includes sending a request for node site planning data from the first party application in response to receiving the valid token response from the first party application.

[0076] In some embodiments, an apparatus includes a processor and a memory storing instructions that, when executed by the processor, cause the processor to receive node site plan data from a first party application, validate the node site plan data based on one or more parameters of the validation, pre-load at least a portion of the node site plan data into a second party application for field survey data collection, and receive field survey data from the second party application.

[0077] In some embodiments, the instructions further cause the processor to create node sites based on the node site planning data and store the node sites or the node site planning data in a centralized database.

[0078] In some embodiments, the instructions further cause the processor to validate the field survey data from the second party application based on one or more parameters of the validation.

[0079] In some embodiments, the instructions further cause the processor, in response to a failed validation of the field survey data, to send a communication to the first party describing the failed validation.

[0080] In some embodiments, the instructions further cause the processor to, in response to successful validation of the field survey data, send updates to the node site plan data to the first party application, wherein the node site plan data has been updated based on the received field survey data.

[0081] In some embodiments, the instructions further cause the processor to send a session token request to the first party application prior to receiving the node site planning data from the first party application.

[0082] In some embodiments, the instructions further cause the processor to receive a valid token response from the first party application or receive an invalid token response from the first party application.

[0083] In some embodiments, the instructions further cause the processor to send a request for node site planning data from the first party application in response to receiving a valid token response from the first party application.

[0084] In some embodiments, a non-transitory computer readable medium is provided having instructions stored thereon that, when executed by a processor, cause the processor to receive node site plan data from a first party application, validate the node site plan data based on one or more parameters of the validation, pre-load at least a portion of the node site plan data into a second party application for field survey data collection, and receive field survey data from the second party application.

[0085] In some embodiments, the instructions further cause the processor to create node sites based on the node site planning data and store the node sites or the node site planning data in a centralized database.

[0086] In some embodiments, the instructions further cause the processor to validate the field survey data from the second party application based on one or more parameters of the validation.

[0087] In some embodiments, the instructions further cause the processor, in response to a failed validation of the field survey data, to send a communication to the first party describing the failed validation.

[0088] The above outlines the features of several embodiments so that those skilled in the art may better understand the aspects of the present disclosure. Those skilled in the art will appreciate that they can easily use this disclosure as a basis for designing or modifying other processes and structures to carry out the same purposes and / or achieve the same advantages as the embodiments introduced herein. Those skilled in the art should further recognize that such equivalent constructions do not depart from the spirit and scope of the present disclosure, and that they can make various changes, substitutions, and alterations herein without departing from the spirit and scope of the present disclosure.

Claims

1. receiving node site planning data from a first party application; validating the node site plan data based on one or more parameters of a validation; preloading at least a portion of the node site planning data into a second party application for field survey data collection; receiving field survey data from the second party application; The method includes:

2. creating a node site based on the node site planning data; storing the node site or the node site planning data in a centralized database; The method of claim 1 further comprising:

3. The method of claim 1 , further comprising validating the field survey data from the second party application based on one or more parameters of the validation.

4. The method of claim 3 , further comprising, in response to a failed validation of the field survey data, sending a communication to a first party describing the failed validation.

5. 4. The method of claim 3, further comprising: in response to successful validation of the field survey data, sending an update to the node site planning data to the first party application, wherein the node site planning data is updated based on the received field survey data.

6. 10. The method of claim 1, further comprising sending a session token request to the first party application prior to receiving the node site planning data from the first party application.

7. receiving a valid token response from the first party application; or The method of claim 6 , further comprising receiving an invalid token response from the first party application.

8. 8. The method of claim 7, further comprising sending a request for the node site plan data from the first party application in response to receiving the valid token response from the first party application.

9. An apparatus comprising: A processor; A memory storing instructions, The instructions, when executed by the processor, cause the processor to: receiving node site planning data from a first party application; validating the node site plan data based on one or more parameters of a validation; preloading at least a portion of the node site planning data into a second party application for field survey data collection; receiving field survey data from the second party application; A device that performs the above function.

10. The instructions further cause the processor to: creating a node site based on the node site planning data; storing the node site or the node site planning data in a centralized database; 10. The apparatus of claim 9, further comprising:

11. The instructions further cause the processor to: The apparatus of claim 9 , further configured to validate the field survey data from the second party application based on one or more parameters of the validation.

12. The instructions further cause the processor to:

12. The apparatus of claim 11, further comprising: in response to a failed verification of the field survey data, sending a communication to a first party describing the failed verification.

13. The instructions further cause the processor to:

12. The apparatus of claim 11, further comprising: in response to successful validation of the field survey data, sending an update to the node site planning data to the first party application, wherein the node site planning data is updated based on the received field survey data.

14. The instructions further cause the processor to:

10. The apparatus of claim 9, further comprising: causing the first party application to send a session token request prior to receiving the node site planning data from the first party application.

15. The instructions further cause the processor to: receiving a valid token response from the first party application; or receiving an invalid token response from the first party application; 15. The apparatus of claim 14, further comprising:

16. The instructions further cause the processor to:

16. The apparatus of claim 15, further comprising: in response to receiving the valid token response from the first party application, causing sending a request for the node site planning data from the first party application.

17. A non-transitory computer-readable medium having instructions stored thereon that, when executed by a processor, cause the processor to: receiving node site planning data from a first party application; validating the node site plan data based on one or more parameters of a validation; preloading at least a portion of the node site planning data into a second party application for field survey data collection; receiving field survey data from the second party application; A non-transitory computer-readable medium for causing

18. The instructions further cause the processor to: creating a node site based on the node site planning data; storing the node site or the node site planning data in a centralized database; 20. The non-transitory computer-readable medium of claim 17,

19. The instructions further cause the processor to:

20. The non-transitory computer readable medium of claim 17, further comprising: validating the field survey data from the second party application based on one or more parameters of the validation.

20. The instructions further cause the processor to:

20. The non-transitory computer readable medium of claim 19, further comprising: in response to a failed validation of the field survey data, sending a communication to a first party describing the failed validation.

Images