--- a/Symbian3/PDK/Source/GUID-16794D4F-23D7-5A96-B363-E25A3DD75C45.dita	Fri Jul 02 12:51:36 2010 +0100
+++ b/Symbian3/PDK/Source/GUID-16794D4F-23D7-5A96-B363-E25A3DD75C45.dita	Fri Jul 16 17:23:46 2010 +0100
@@ -11,6 +11,6 @@
   PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
 <concept xml:lang="en" id="GUID-16794D4F-23D7-5A96-B363-E25A3DD75C45"><title>Location Monitor Overview</title><shortdesc>The Location Monitor is responsible for storing position fixes calculated by the LBS subsystem. It provides the stored fixes to LBS components that request them. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody><section><title>Purpose</title> <p>The Location Monitor monitors internal communications between LBS components and with the network in order to maintain its database of stored position fixes. Whenever the Location Monitor obtains a position fix it adds it to the database, together with the Global Cell ID received from the network. </p> <p>When the Location Monitor receives a request for location information, it uses the current network Global Cell ID to search the database for the closest stored position. </p> <p>If the database search is successful the Location Monitor returns the stored position with an indication of its accuracy, based on the current information received from the network. A stored position's accuracy can be estimated to be at the country level (least accurate), down to street level in urban areas (most accurate). </p> <p>If the database search is unsuccessful the Location Monitor simply returns the most recently stored position. </p> </section> <section><title>Required background</title> <p>A knowledge of the material covered in the following is useful to understanding how this component fits into the LBS architecture: </p> <ul><li id="GUID-D7EAF921-5D72-533E-B08F-69FE32FDA50D"><p><xref href="GUID-7233BC33-6060-5D6B-A5D2-01135F059337.dita">LBS Architecture Overview</xref>  </p> </li> </ul> </section> <section><title>Key concepts and terms</title> <p>The Location Monitor uses the Global Cell ID broadcast by the network. </p> <p>The Global Cell ID is made up of four values: </p> <dl><dlentry><dt>MCC</dt> <dd><p>Mobile Country Code. A unique three digit number used to identify a country. </p> </dd> </dlentry> <dlentry><dt>MNC</dt> <dd><p>Mobile Network Code. A unique three digit number used to identify a mobile phone operator. </p> </dd> </dlentry> <dlentry><dt>LAC</dt> <dd><p>Location Area Code. A unique number used to identify a group of cells within a cellular network. </p> </dd> </dlentry> <dlentry><dt>CID</dt> <dd><p>Cell ID. The unique number used to identify an individual cell within a cellular network. </p> </dd> </dlentry> </dl> <p>A Location Monitor client can get these values from the Location Monitor, or a simple single value that is an estimate of the stored position accuracy. </p> </section> <section><title>Architecture</title> <p>The Location Monitor is a server with a client interface. Currently the Location Monitior does not have a published API. </p> <p>Client applications use the Location Monitor indirectly via the Location Server (<codeph>eposserver.exe</codeph>). Figure 1 shows the Location Monitor architecture. </p> <fig id="GUID-C080410E-38C6-5E1E-BC1A-4E9B0D208507"><title>
              Figure 1. Location Monitor architecture 
-          </title> <image href="GUID-5384FBBC-0171-5AD2-8CDA-23548DF99DCE_d0e449052_href.png" placement="inline"/></fig> </section> <section><title>APIs</title> <p>The Location Monitor does not have a published API at this time. It has an internal API which is used by other LBS components. </p> </section> <section><title>Typical uses</title> <p>Client applications use the Location Monitor indirectly through the <xref href="GUID-D0318BB6-0B9F-5A1C-AB0B-61BA22D28661.dita">Location Acquisition API</xref>. </p> <p>An Location Acquisition API client calls <xref href="GUID-51157D56-2848-300C-8B1E-A26E7EA6AF20.dita"><apiname>RPositioner::GetLastKnownPositionArea()</apiname></xref> to get a stored position with an accuracy estimate. The Location Server delegates this function call to the Location Monitor. </p> </section> </conbody><related-links><link href="GUID-F6B5F777-D12F-5913-AECE-047DF8C72F1F.dita"><linktext>How to Get Location
+          </title> <image href="GUID-5384FBBC-0171-5AD2-8CDA-23548DF99DCE_d0e454897_href.png" placement="inline"/></fig> </section> <section><title>APIs</title> <p>The Location Monitor does not have a published API at this time. It has an internal API which is used by other LBS components. </p> </section> <section><title>Typical uses</title> <p>Client applications use the Location Monitor indirectly through the <xref href="GUID-D0318BB6-0B9F-5A1C-AB0B-61BA22D28661.dita">Location Acquisition API</xref>. </p> <p>An Location Acquisition API client calls <xref href="GUID-51157D56-2848-300C-8B1E-A26E7EA6AF20.dita"><apiname>RPositioner::GetLastKnownPositionArea()</apiname></xref> to get a stored position with an accuracy estimate. The Location Server delegates this function call to the Location Monitor. </p> </section> </conbody><related-links><link href="GUID-F6B5F777-D12F-5913-AECE-047DF8C72F1F.dita"><linktext>How to Get Location
                 Information</linktext> </link> <link href="GUID-70E1117B-17F0-5CF4-A5D0-35D3BEBB0FEA.dita"><linktext>Position Area Data
                 Classes</linktext> </link> </related-links></concept>
\ No newline at end of file