Page 303 - Unleashing the potenti al of the Internet of Things

Unleashing the potential of the Internet of Things 3

– Optimized traffic control should be supported. For example, the detected data may be very
small and need to be reported to the network every hour: in such a case, it is a waste of
resources to be permanently connected to the network. The network should be optimized in
terms of traffic control, and, in such a case, traffic could be delivered, for example via user
plane signalling without a data-dedicated IP bearer. Additionally, devices on a patient
might stay in sleep mode and wake up when the doctor needs to diagnose the patient
remotely.
– Different mobility levels should be supported. For instance, in the case of patients with
poor mobility (moving infrequently and not very far), it is a waste of resources to activate
full mobility management capabilities.
– Remote device activation and management should be supported. For example, devices in
sleep mode would be woken up only when the doctor needs to diagnose the patient
remotely.
– Time control should be supported. For instance, devices on patients may collect a lot of
data but do not always need to report them at every collection as the data may be not very
critical, e.g., only for routine examination. In these scenarios, the network can allocate
specific time slots for the devices' data to be reported (the devices cannot report data during
other time periods or are charged at higher rates in those periods).
– Device profiles should be supported. Patient may buy new devices and connect them to the
network dynamically: device related information should be included in the device profile
and be updated dynamically to enable the network authentication and control of the newly-
added devices and also their removal.

– Devices behind a gateway should be able to be identified by the network. The gateway
might provide only a bearer channel and act as a data aggregator for the devices connected
to it or might provide service control for the devices connected to it. In the first case, the
devices connected to the gateway should be controlled by the network, or by both the
network and gateway.

– Proprietary devices should be supported. There are plenty of proprietary devices and
gateways running in networks: adaptation to existing proprietary devices and gateways
should be supported.
– Service profile should be supported. Patients are usually not very familiar with the services
offered by different hospitals, they can usually just logon to the e-Health centre's portal and
access services, whereas the e-Health centre is usually familiar and can determine the target
hospitals based on their professional knowledge. There might be one or multiple hospitals
providing medical services to a patient jointly. In other words, when the devices on a
patient report data to the e-Health centre, the centre can intelligently help the patient to
select the best target hospitals and route the data to those hospitals for joint diagnosis.
Multimedia call control sessions might be needed in this scenario, including audio, video,
text messaging, etc. The devices should also interact with multiple applications.

When doctors diagnose and provide healthcare services remotely, they usually also need the
existing internal disease diagnostics system or database system of the hospital for assistance: data
reported from devices may be input to the existing hospital internal system. In this case, the devices
should be interoperable with existing systems (e.g., data format, service capabilities invocation,
etc.), that is the e-Health system should be able to collaborate and inter-work with the existing
application systems which are usually heterogeneous.

– Traffic load balancing should be taken into consideration in order to cope with particular
situations. For instance, due to the number of patients in areas varying quite considerably,
there may be relatively high rates of patients in geriatric wards, communities of elderly
people and certain cities, as compared with other cities. The network should be able to
handle accordingly the system imbalance in case of specific situations of high traffic or

Rec. ITU-T Y.4109/Y.2061 (06/2012) 289