diff --git a/docs/monitoring.md b/docs/monitoring.md
index 21899ef3b621af7977eb35a4e633466a5bb17e0e..b2509b73a565600a973ea9f8dc3b17706e6fb36a 100644
--- a/docs/monitoring.md
+++ b/docs/monitoring.md
@@ -25,10 +25,35 @@ Tags can be structured to provide query by dimensions allowing series data to be
 
 #### Temporal Measurements
 
-####Spatial Measurements
+Monitoring data must have time-stamp values that are consistent and sycnrhonised across the platform. 
+This means that all VMs hosting SFs should have a synchronised system clock, or at least (and more likely) 
+a means by which an millisecond offset from the local time can be retrieved so that a 'platform-correct' 
+time value can be calculated.
+
+
+#### Spatial Measurements
 
 Discuss hierarchical tags vs GPS coordinate systems
 
+Location should be provided in two forms: labelled (tag) and numeric (longitude and latitude as digitial degrees). Note that the location label is likely to be a _global tag_. This allows us to support the 
+following scenarios:
+
+##### SF with no knowlegde of GPS coordinates
+
+| loc_label | loc_long | loc_lat |
+| --- | --- | --- |
+| DATACENTRE_1 | 0 | 0 |
+
+A SF media transcoder is placed in a lamp-post. It has no means to obtain GPS coordinates but has a _loc_label_ provided to it as a VM environment variable. It provides zeros in the longitude and latitude. In subsequent data analysis we can search for this SF by location label.
+
+##### SF with full location knowledge
+
+| loc_label | loc_long | loc_lat |
+| --- | --- | --- |
+| LAMP_1 | 50.842715 | -0.778276 |
+
+A SF that is a proxy to a user attached to a NAP running in street lamp post LAMP_1. Here we have knowledge both of the logical location of the service and also the fine-grained, dynamic position of the service user. Lots of interesting possibilities with both of these bits of information!
+
 ### Logical Model
 
 The high-level entities involved in the measurement model are defined in the figure below. The core of the model is the Surrogate SF as the primary measurement point as this is the physical realisation of services running on the platform. A Surrogate SF is a process running on a physical or virtual host with ports connecting to other Surrogate SFs within the network. The Surrogate SF has measurement processes running to capture different views on the SF include the network, host resources, and SF usage/performance. The acquisition of these different views on the SF together is a key element of the cross-layer information required for management and control.  The measurements about a surrogate SF is captured by different processes running on the VM or container but are brought together by globally asserted monitoring metadata allowing the information to be integrated, correlated and analysed.
@@ -98,7 +123,6 @@ A couple of comments
 * CPU_UTILISATION_M: will be replaced by other metrics provided directly by Telegraf plugins
 * END_TO_END_LATENCY_M (not clear who the endpoints are)
 
-
 ### Measurements
 
 #### Capacity Measurements