Events coming from applications can take on a variety of forms.
To preserve generality, events incoming from an application are dealt with by an application request processor (ARP) that is specific to the application. Broadcom provides three different applications and the corresponding ARPs as examples.
The simplest ARP is an interactive request manager (Interactive Request Manager (IRM) Commands) that deals with simple text commands to start and stop GPS positioning.
The second ARP interacts with a Spirent/ADS system (ADS/RRC Application Request Processor) to carry out RRC positioning requests. This provides an example of a network stack element making requests to the GLCT.
The third ARP supplied is a batch request manager. The batch request manager carriers out GPS "jobs" specified in the XML configuration file used by the GLCT. These jobs start automatically when the GLCT is activated. The simplest job initiates continuous GPS positioning and outputs NMEA data. This is sufficient for applications where the GPS runs continuously after startup. More complex "jobs" involve turning the GPS on and off repetitively, mainly to support testing of GPS software and hardware.
The Application Request Processors are registered with the GLCT at run time. Any number of ARPs can be supported. The interface to the ARP is a straightforward C programming interface, making it easy for customers to create their own ARP to deal with the specific events being generated by their own application or applications. In a complete cellular system the customer may have several applications that make use of the GLCT such as a Java middleware, a user plane protocol stack, a control plan protocol stack, and a manufacturing test mode.
This section discusses about the general idea and concept of Application Request Processors (ARPs). Also we will list some ARPs we implemented to the system.