Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8193


Information Model for Large-Scale Measurement Platforms (LMAPs)

Part 3 of 3, p. 41 to 53
Prev Section


prevText      Top      ToC       Page 41 
4.11.  Common Objects: Event Information

   The Event information object used throughout the Information Models
   can initially take one of several different forms.  Additional forms
   may be defined later in order to bind the execution of Schedules to
   additional Events.  The initially defined Event forms are:

   1.  Periodic Timing: Emits multiple Events periodically according to
       an interval time defined in seconds

   2.  Calendar Timing: Emits multiple Events according to a calendar-
       based pattern, e.g., 22 minutes past each hour of the day on

   3.  One-Off Timing: Emits one Event at a specific date and time

   4.  Immediate: Emits one Event as soon as possible

Top      Up      ToC       Page 42 
   5.  Startup: Emits an Event whenever the MA is started (e.g., at
       device startup)

   6.  Controller Lost: Emits an Event when connectivity to the
       Controller has been lost

   7.  Controller Connected: Emits an Event when connectivity to the
       Controller has been established or re-established

   Optionally, each of the Event options may also specify a randomness
   that should be evaluated and applied separately to each indicated
   Event.  This randomness parameter defines a uniform interval in
   seconds over which the start of the Task is delayed from the starting
   times specified by the Event object.

   Both the periodic and calendar timing objects allow for a series of
   Actions to be executed.  While both have an optional end time, it is
   best practice to always configure an end time and refresh the
   information periodically to ensure that lost MAs do not continue
   their Tasks forever.

   Startup Events are only created on device startup, not when a new
   Instruction is transferred to the MA.  If scheduled Task execution is
   desired both on the transfer of the Instruction and on device
   restart, then both the Immediate and Startup timing needs to be used
   in conjunction.

   The datetime format used for all elements in the Information Model
   MUST conform to RFC 3339 [RFC3339].

4.11.1.  Definition of ma-event-obj

     object {
        string               ma-event-name;
        union {
            ma-periodic-obj             ma-event-periodic;
            ma-calendar-obj             ma-event-calendar;
            ma-one-off-obj              ma-event-one-off;
            ma-immediate-obj            ma-event-immediate;
            ma-startup-obj              ma-event-startup;
            ma-controller-lost-obj      ma-event-controller-lost;
            ma-controller-connected-obj ma-event-controller-connected;
        [int                 ma-event-random-spread;]
        [int                 ma-event-cycle-interval;]
     } ma-event-obj;

Top      Up      ToC       Page 43 
   The ma-event-obj is the main Event object.  Event objects are
   identified by a name.  A generic Event object itself contains a more
   specific Event object.  The set of specific Event objects should be
   extensible.  The initial set of specific Event objects is further
   described below.  The ma-event-obj also includes an optional uniform
   random spread that can be used to randomize the start times of
   Schedules triggered by an Event.  The ma-event-obj consists of the
   following elements:

   ma-event-name:                  The name uniquely identifies an Event
                                   object.  Schedules refer to Event
                                   objects by this name.

   ma-event-periodic:              The ma-event-periodic is present for
                                   periodic timing objects.

   ma-event-calendar:              The ma-event-calendar is present for
                                   calendar timing objects.

   ma-event-one-off:               The ma-event-one-off is present for
                                   one-off timing objects.

   ma-event-immediate:             The ma-event-immediate is present for
                                   immediate Event objects.

   ma-event-startup:               The ma-event-startup is present for
                                   startup Event objects.

   ma-event-controller-lost:       The ma-event-controller-lost is
                                   present for connectivity to
                                   Controller lost Event objects.

   ma-event-controller-connected:  The ma-event-controller-connected is
                                   present for connectivity to
                                   Controller established Event objects.

   ma-event-random-spread:         The optional ma-event-random-spread
                                   adds a random delay defined in
                                   seconds to the Event object.  No
                                   random delay is added if
                                   ma-event-random-spread does not

Top      Up      ToC       Page 44 
   ma-event-cycle-interval:        The optional ma-event-cycle-interval
                                   defines the duration of the time
                                   interval in seconds that is used to
                                   calculate cycle numbers.  No cycle
                                   number is calculated if
                                   ma-event-cycle-interval does not

4.11.2.  Definition of ma-periodic-obj

     object {
        [datetime            ma-periodic-start;]
        [datetime            ma-periodic-end;]
         int                 ma-periodic-interval;
     } ma-periodic-obj;

   The ma-periodic-obj timing object has an optional start and an
   optional end time plus a periodic interval.  Schedules using an
   ma-periodic-obj are started periodically between the start and end
   time.  The ma-periodic-obj consists of the following elements:

   ma-periodic-start:        The optional date and time at which
                             Schedules using this object are first
                             started.  If not present, it defaults to

   ma-periodic-end:          The optional date and time at which
                             Schedules using this object are last
                             started.  If not present, it defaults to

   ma-periodic-interval:     The interval defines the time in seconds
                             between two consecutive starts of Tasks.

4.11.3.  Definition of ma-calendar-obj

   Calendar timing supports the routine execution of Schedules at
   specific times and/or on specific dates.  It can support more
   flexible timing than periodic timing since the execution of Schedules
   does not have to be uniformly spaced.  For example, a calendar timing
   could support the execution of a Measurement Task every hour between
   6 pm and midnight on weekdays only.

   Calendar timing is also required to perform measurements at
   meaningful times in relation to network usage (e.g., at peak times).
   If the optional time zone offset is not supplied, then local system
   time is assumed.  This is essential in some use cases to ensure
   consistent peak-time measurements as well as supporting MA devices

Top      Up      ToC       Page 45 
   that may be in an unknown time zone or to roam between different time
   zones (but know their own time zone information such as through the
   mobile network).

   The calendar elements within the calendar timing do not have defaults
   in order to avoid accidental high-frequency execution of Tasks.  If
   all possible values for an element are desired, then the wildcard *
   is used.

     object {
        [datetime            ma-calendar-start;]
        [datetime            ma-calendar-end;]
        [string              ma-calendar-months<0..*>;]
        [string              ma-calendar-days-of-week<0..*>;]
        [string              ma-calendar-days-of-month<0..*>;]
        [string              ma-calendar-hours<0..*>;]
        [string              ma-calendar-minutes<0..*>;]
        [string              ma-calendar-seconds<0..*>;]
        [int                 ma-calendar-timezone-offset;]
     } ma-calendar-obj;

   ma-calendar-start:            The optional date and time at which
                                 Schedules using this object are first
                                 started.  If not present, it defaults
                                 to immediate.

   ma-calendar-end:              The optional date and time at which
                                 Schedules using this object are last
                                 started.  If not present, it defaults
                                 to indefinite.

   ma-calendar-months:           The optional set of months (1-12) on
                                 which Tasks scheduled using this object
                                 are started.  The wildcard * means all
                                 months.  If not present, it defaults to
                                 no months.

   ma-calendar-days-of-week:     The optional set of days of a week
                                 ("Mon", "Tue", "Wed", "Thu", "Fri",
                                 "Sat", "Sun") on which Tasks scheduled
                                 using this object are started.  The
                                 wildcard * means all days of the week.
                                 If not present, it defaults to no days.

Top      Up      ToC       Page 46 
   ma-calendar-days-of-month:    The optional set of days of a month
                                 (1-31) on which Tasks scheduled using
                                 this object are started.  The wildcard
                                 * means all days of a month.  If not
                                 present, it defaults to no days.

   ma-calendar-hours:            The optional set of hours (0-23) on
                                 which Tasks scheduled using this object
                                 are started.  The wildcard * means all
                                 hours of a day.  If not present, it
                                 defaults to no hours.

   ma-calendar-minutes:          The optional set of minutes (0-59) on
                                 which Tasks scheduled using this object
                                 are started.  The wildcard * means all
                                 minutes of an hour.  If not present, it
                                 defaults to no minutes.

   ma-calendar-seconds:          The optional set of seconds (0-59) on
                                 which Tasks scheduled using this object
                                 are started.  The wildcard * means all
                                 seconds of an hour.  If not present, it
                                 defaults to no seconds.

   ma-calendar-timezone-offset:  The optional time zone offset in
                                 minutes.  If not present, it defaults
                                 to the system's local time zone.

   If a day of the month is specified that does not exist in the month
   (e.g., the 29th of February), then those values are ignored.

4.11.4.  Definition of ma-one-off-obj

     object {
         datetime            ma-one-off-time;
     } ma-one-off-obj;

   The ma-one-off-obj timing object specifies a fixed point in time.
   Schedules using an ma-one-off-obj are started once at the specified
   date and time.  The ma-one-off-obj consists of the following

   ma-one-off-time:          The date and time at which Schedules using
                             this object are started.

Top      Up      ToC       Page 47 
4.11.5.  Definition of ma-immediate-obj

     object {
                             // empty
     } ma-immediate-obj;

   The ma-immediate-obj Event object has no further information
   elements.  Schedules using an ma-immediate-obj are started as soon as

4.11.6.  Definition of ma-startup-obj

     object {
                             // empty
     } ma-startup-obj;

   The ma-startup-obj Event object has no further information elements.
   Schedules or Suppressions using an ma-startup-obj are started at MA
   initialization time.

4.11.7.  Definition of ma-controller-lost-obj

     object {
                             // empty
     } ma-controller-lost-obj;

   The ma-controller-lost-obj Event object has no further information
   elements.  The ma-controller-lost-obj indicates that connectivity to
   the Controller has been lost.  This is determined by a timer started
   after each successful contact with a Controller.  When the timer
   reaches the controller-timeout (measured in seconds), a
   ma-controller-lost-obj Event is generated.  This Event may be used to
   start a Suppression.

4.11.8.  Definition of ma-controller-connected-obj

     object {
                             // empty
     } ma-controller-connected-obj;

   The ma-controller-connected-obj Event object has no further
   information elements.  The ma-controller-connected-obj indicates that
   connectivity to the Controller has been established again after it
   was lost.  This Event may be used to end a Suppression.

Top      Up      ToC       Page 48 
5.  Example Execution

   The example execution has two Event sources, E1 and E2, and three
   Schedules, S1, S2, and S3.  The Schedule S3 is started by Events of
   Event source E2 while the Schedules S1 and S2 are both started by
   Events of the Event source E1.  The Schedules S1 and S2 have two
   Actions each, and Schedule S3 has a single Action.  The Event source
   E2 has no randomization while the Event source E1 has the
   randomization r.

   Figure 2 shows a possible timeline of an execution.  The time T is
   progressing downwards.  The dotted vertical line indicates progress
   of time while a dotted horizontal line indicates which Schedules are
   triggered by an Event.  Lines of tildes indicate data flowing from an
   Action to another Schedule.  Actions within a Schedule are named A1,
   A2, etc.

Top      Up      ToC       Page 49 
     E2    E1   T           S1           S2            S3
                        sequential    parallel     pipelined
             e0 +
           e0+r + .......... + .......... ++
                :            | A1      A1 || A2
                :            +            |+ ~~~~~~~>
                :            | A2         |
                :            |            + ~~~~~~~~>
                :            + ~~~~~~~~~~~~~~~~~~~~~>
             e1 +
           e1+r + .......... + .......... ++
                :            | A1      A1 ||
                :            |            +|~~~~~~~>
                :            |             | A2
                :            +             +~~~~~~~>
                :            | A2
                :            + ~~~~~~~~~~~~~~~~~~~~>
      e0        + ................................... +
                :                                     | A1
             e3 +                                     |
           e3+r + .......... + .......... ++          |
                :            | A1      A1 || A2       |
                :            +            ++ ~~~~~~>  |
                :            | A2                     +
                :            + ~~~~~~~~~~~~~~~~~~~~>

                        Figure 2: Example Execution

   Note that implementations must handle possible concurrency issues.
   In the example execution, Action A1 of Schedule S3 is consuming the
   data that has been forwarded to Schedule S3 while additional data is
   arriving from Action A2 of Schedule S2.

6.  IANA Considerations

   This document does not require any IANA actions.

Top      Up      ToC       Page 50 
7.  Security Considerations

   This Information Model deals with information about the control and
   reporting of the Measurement Agent.  There are broadly two security
   considerations for such an Information Model.  Firstly, the
   Information Model has to be sufficient to establish secure
   communication Channels to the Controller and Collector such that
   other information can be sent and received securely.  Additionally,
   any mechanisms that the Network Operator or other device
   administrator employs to preconfigure the MA must also be secure to
   protect unauthorized parties from modifying Preconfiguration
   Information.  These mechanisms are important to ensure that the MA
   cannot be hijacked, for example, to participate in a distributed
   denial-of-service attack.

   The second consideration is that no mandated information items should
   pose a risk to confidentiality or privacy given such secure
   communication Channels.  For this latter reason, items such as the MA
   context and MA-ID are left optional and can be excluded from some
   deployments.  This may, for example, allow the MA to remain anonymous
   and for information about location or other context that might be
   used to identify or track the MA to be omitted or blurred.
   Implementations and deployments should also be careful about exposing
   device-ids when this is not strictly needed.

   An implementation of this Information Model should support all the
   security and privacy requirements associated with the LMAP Framework
   [RFC7594].  In addition, users of this Information Model are advised
   to choose identifiers for Group-IDs, tags, or names of Information
   Model objects (e.g., configured Tasks, Schedules, or Actions) that do
   not reveal any sensitive information to people authorized to process
   measurement results but who are not authorized to know details about
   the Measurement Agents that were used to perform the measurement.

8.  References

8.1.  Normative References

              International Organization for Standardization,
              "Information Technology - Universal Coded Character Set
              (UCS)", ISO Standard 10646:2014, September 2014.

   [POSIX.2]  The Open Group, "Standard for Information Technology -
              Portable Operating System Interface (POSIX(R)) Base
              Specifications, Issue 7", IEEE Standard 1003.1, 2016
              Edition, DOI, 10.1109/IEEESTD.2016.7582338, September

Top      Up      ToC       Page 51 
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              DOI 10.17487/RFC4122, July 2005,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

8.2.  Informative References

   [IPPM-REG] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
              Akhter, "Registry for Performance Metrics", Work in
              Progress, draft-ietf-ippm-metric-registry-12, June 2017.

   [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
              Information Models and Data Models", RFC 3444,
              DOI 10.17487/RFC3444, January 2003,

   [RFC7398]  Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
              A. Morton, "A Reference Path and Measurement Points for
              Large-Scale Measurement of Broadband Performance",
              RFC 7398, DOI 10.17487/RFC7398, February 2015,

   [RFC7536]  Linsner, M., Eardley, P., Burbridge, T., and F. Sorensen,
              "Large-Scale Broadband Measurement Use Cases", RFC 7536,
              DOI 10.17487/RFC7536, May 2015,

Top      Up      ToC       Page 52 
   [RFC7594]  Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
              Aitken, P., and A. Akhter, "A Framework for Large-Scale
              Measurement of Broadband Performance (LMAP)", RFC 7594,
              DOI 10.17487/RFC7594, September 2015,

   [RFC8194]  Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for
              LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194,
              August 2017, <>.


   Several people contributed to this specification by reviewing early
   draft versions and actively participating in the LMAP Working Group
   (apologies to those unintentionally omitted): Vaibhav Bajpai, Michael
   Bugenhagen, Timothy Carey, Alissa Cooper, Kenneth Ko, Al Morton, Dan
   Romascanu, Henning Schulzrinne, Andrea Soppera, Barbara Stark, and
   Jason Weil.

   Marcelo Bagnulo, Trevor Burbridge, Philip Eardley, and Juergen
   Schoenwaelder worked in part on the Leone research project, which
   received funding from the European Union Seventh Framework Programme
   [FP7/2007-2013] under grant agreement number 317647.

   Juergen Schoenwaelder was partly funded by Flamingo, a Network of
   Excellence project (ICT-318488) supported by the European Commission
   under its Seventh Framework Programme.

Top      Up      ToC       Page 53 
Authors' Addresses

   Trevor Burbridge
   Adastral Park, Martlesham Heath
   Ipswich  IP5 3RE
   United Kingdom


   Philip Eardley
   Adastral Park, Martlesham Heath
   Ipswich  IP5 3RE
   United Kingdom


   Marcelo Bagnulo
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Leganes, Madrid  28911


   Juergen Schoenwaelder
   Jacobs University Bremen
   Campus Ring 1
   Bremen  28759