However the differences are that MDER messages are much smaller than the equivalent XML messages, and much simpler for machines to convert to and from internal data structures. This section shows some of the exchanges that occur between Agent and Manager. The exchanges, illustrated by UML sequence diagrams, are:   The UML sequence diagram below shows messages that would typically pass between a weighing scale PHD Agent and an IEEE 11073 Manager (such as a mobile phone or PC). The weighing scales are switched on for the first time and the Agent (scales) sends an association request (identifying the device as an IEEE 11073 PHD device), but in this example the Manager does not recognise the Agent. So the Agent sends a configuration report containing details of all of the objects it contains and their static attributes (of the Body Weight, Body Height and Body Mass Index objects, in this case). The Manager also requests details of the (top-level) MDS object. All this data would typically be stored for future reference. The Agent then sends measurement data (in a Confirmed Event Report), then disconnects from the Manager. The next UML sequence diagram shows the weighing scales in operation for a second time. In this case the Manager does recognise the Agent, so uses the configuration data that it previously stored (or that it obtained by some other route). The Agent then sends measurement data (in a Confirmed Event Report), then disconnects from the Manager. The Scanner object class is a powerful construct that enables efficient grouping of several metrics into a single message payload. Think of scanners as objects within the PHD that monitor parameters and send notifications to the manager as required. A scanner can report measurements from several other objects in a single message. There are two types of scanner: episodic (which sends a notification when some event occurs) and periodic (which send notifications at regular intervals). Not all Agents have Scanner objects: weighing scales don't but pulse oximeters can do. In the context of a pulse oximeter, an episodic scanner could be implemented to send an event report to the manager on every heart beat. A periodic scanner could be implemented to send an event report containing trend data every five seconds, say. As with the other objects, the data contained within the scanner event reports are specified in the configuration phase – the agent has considerable flexibility in defining the data it will send, yet any configuration will be intelligible to the manager. The scanner event reports are designed to be very efficient in terms of bandwidth – the parameters to be returned in each event report have been defined during configuration, so each report need only identify the object and pass the data values.