1、 I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n ITU-T H.812.4 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (11/2017) SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS E-health multimedia services and applications Personal health systems Interoperability design guidelines for per
2、sonal connected health systems: Services interface: Authenticated Persistent Session capability Recommendation ITU-T H.812.4 ITU-T H-SERIES RECOMMENDATIONS AUDIOVISUAL AND MULTIMEDIA SYSTEMS CHARACTERISTICS OF VISUAL TELEPHONE SYSTEMS H.100H.199 INFRASTRUCTURE OF AUDIOVISUAL SERVICES General H.200H.
3、219 Transmission multiplexing and synchronization H.220H.229 Systems aspects H.230H.239 Communication procedures H.240H.259 Coding of moving video H.260H.279 Related systems aspects H.280H.299 Systems and terminal equipment for audiovisual services H.300H.349 Directory services architecture for audi
4、ovisual and multimedia services H.350H.359 Quality of service architecture for audiovisual and multimedia services H.360H.369 Telepresence H.420H.429 Supplementary services for multimedia H.450H.499 MOBILITY AND COLLABORATION PROCEDURES Overview of Mobility and Collaboration, definitions, protocols
5、and procedures H.500H.509 Mobility for H-Series multimedia systems and services H.510H.519 Mobile multimedia collaboration applications and services H.520H.529 Security for mobile multimedia systems and services H.530H.539 Security for mobile multimedia collaboration applications and services H.540H
6、.549 VEHICULAR GATEWAYS AND INTELLIGENT TRANSPORTATION SYSTEMS (ITS) Architecture for vehicular gateways H.550H.559 Vehicular gateway interfaces H.560H.569 BROADBAND, TRIPLE-PLAY AND ADVANCED MULTIMEDIA SERVICES Broadband multimedia services over VDSL H.610H.619 Advanced multimedia services and appl
7、ications H.620H.629 Ubiquitous sensor network applications and Internet of Things H.640H.649 IPTV MULTIMEDIA SERVICES AND APPLICATIONS FOR IPTV General aspects H.700H.719 IPTV terminal devices H.720H.729 IPTV middleware H.730H.739 IPTV application event handling H.740H.749 IPTV metadata H.750H.759 I
8、PTV multimedia application frameworks H.760H.769 IPTV service discovery up to consumption H.770H.779 Digital Signage H.780H.789 E-HEALTH MULTIMEDIA SERVICES AND APPLICATIONS Personal health systems H.810H.819 Interoperability compliance testing of personal health systems (HRN, PAN, LAN, TAN and WAN)
9、 H.820H.859 Multimedia e-health data exchange services H.860H.869 For further details, please refer to the list of ITU-T Recommendations. Rec. ITU-T H.812.4 (11/2017) i Recommendation ITU-T H.812.4 Interoperability design guidelines for personal connected health systems: Services interface: Authenti
10、cated Persistent Session capability Summary The Continua Design Guidelines (CDG) defines a framework of underlying standards and criteria that ensure the interoperability of devices and data used for personal connected health services. The Continua Design Guidelines also contains design guidelines (
11、DGs) that further clarify the underlying standards or specifications by reducing options or by adding missing features to improve interoperability. ITU-T H.812.4 defines the additional design guidelines for the Authenticated Persistent Session (APS), whose function is to provide a secure, long-lived
12、, persistent bidirectional data channel between the Health users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regular
13、ly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ITU-T H.810 Recommendation ITU-T H.810 (2017), Interoperability design guidelines for personal connected health systems: Introduction. All other reference
14、d documents can be found in clause 2 of ITU-T H.810. 3 Definitions This design guidelines document uses terms defined in ITU-T H.810. 4 Abbreviations and acronyms This design guidelines document uses abbreviations and acronyms defined in ITU-T H.810. 5 Conventions This design guidelines document fol
15、lows the conventions defined in ITU-T H.810. 6 Authenticated Persistent Session use case The Authenticated Persistent Session provides a mechanism by which future Continua Certified Capability Classes (CCCs) can initiate communications from cloud based services to the PHG. 7 Authenticated Persistent
16、 Session (APS) overview The Authenticated Persistent Session Certified Capability Class defines a long lived, persistent context for exchanging messages between a Health the APS is bound to a security credential such as an X.509 certificate, an OAuth token, or SAML token. There are three steps invol
17、ved in creating and exchanging a message using an APS. Once the APS is in place only the final step is needed to send additional messages. The three steps, in order are: Capability Exchange, see ITU-T H.812.3 In this phase the PHG application obtains information from the Health 2) an undefined futur
18、e CCC or vendor specific message handler. The MQTT message is received by the Network-IF component which forwards it to the dispatcher. The dispatcher extracts the MQTT header. The MQTT header contains the topic name which identifies the message handler to which the payload needs to be delivered. Th
19、e topic name is a string that uniquely identifies the CCC that is expected to process the message. NOTE 2 This description is illustrative and does not proscribe a particular method of implementation. Figure 7-2 Example of payload delivery to different message handlers 7.2 Topics used in MQTT Contin
20、ua compliant entities implementing the APS-CCC shall support the use of the MQTT protocol to publish and subscribe to messages. The MQTT protocol uses a topic-based addressing mechanism, and this standard specifies three kinds of topics to be used by an APS. They are shown in Table 7-1. Table 7-1 To
21、pics used in MQTT Name used in this document Format of the topic string used in MQTT Description Message topics pcha/message/ Topics used to transmit messages to the APS API client components in the PHG application. Status topic pcha/status/ Topic used to track status of the APS Response topics pcha
22、/response/ Topic used to receive responses from the PHG application Rec. ITU-T H.812.4 (11/2017) 5 Each APS is identified by a pair of APB identifiers (APBIs) in the corresponding APB resource, and these APBIs shall be inserted in the topic strings in place of the characters and . See clause 8.2.2 f
23、or more details on the APBIs. The shall be replaced by an identifier specified by the CCC that is using the APS exchange mechanism. The identifier allows different CCC peers to exchange messages in the context of a single APS. An example of a message topic for an APS might appear as follows: pcha/me
24、ssage/1/34521ee41da2eff/APS. The MQTT server shall control access to these topics using the following rules: A Health & Fitness services application shall have write access to any message topics containing its Services APBI. A Health & Fitness services application shall have read access to the statu
25、s and response topics containing its Services APBI. A PHG application shall have read access to any message topics containing its PHG APBI. A PHG application shall have write access to any status topics containing its PHG APBI. A PHG application shall have write access to any response topics contain
26、ing its PHG APBI. Suitably authenticated management applications MAY have read access to any topic. All other access shall NOT be permitted. In general the above requirements are stating that an APS-CCC shall only have access to topics defined for that APS-CCC. A similar relationship holds, in theor
27、y, between the Health & Fitness services application and MQTT server, but how the Health & Fitness services application and MQTT server actually interact is implementation dependent. In many implementations the Health & Fitness services application is also the authenticated management application. 7
28、.3 Shoulder tap If the Health & Fitness services application needs to send a message to the PHG application and the PHG application is no longer connected to the MQTT server, the Health & Fitness services application can use one of the shoulder tap methods supported by the PHG application to alert i
29、t that a message is waiting. The PHG application, upon reception of the shoulder tap, reconnects to the MQTT server. The PHG is then able to receive messages from the Health & Fitness services application. Currently the only defined shoulder tap method is binary SMS messaging. 8 APS management An au
30、thenticated persistent session (APS) is a long term association between two mutually authenticated peer entities, one associated with the Health & Fitness services application and the other with the PHG application. Authentication is performed using TLS in conjunction with OAUTH as outlined in Annex
31、 B of ITU-T H.812. The Health & Fitness services application, after it has successfully authenticated the PHG application allocates a resource, called the authenticated persistent binding (APB). The APB contains a set of attributes that both define the APS and provide the basis for its management. I
32、t is the responsibility of the Health & Fitness services application to ensure that for a given OAUTH bearer token: (1) the same APB shall be returned on repeated requests for the APS resource, and that (2) if a different OAUTH bearer token is provided a different APS resource (or an error) shall be
33、 returned. The APB resource is an XML document with a set of elements as defined in Table 8-1 and Table 8-2. The management of APB resources is covered in this clause. 6 Rec. ITU-T H.812.4 (11/2017) The Health & Fitness services application implementing the APS-CCC uses hData to present to the PHG a
34、pplication three items relating to APSs in the root.xml file. The first item is a profile. The profile is an entry that indicates that the Health & Fitness services application supports the APS-CCC. The second item, resourceType, describes the content of the APB resource and contains a reference to
35、a XML schema that can be used to validate it. The third item, section, is an entry that indicates to the PHG application where to POST its contribution to the APB resource when first establishing the APS. The initial content of the APB resource is jointly established by the PHG and Health & Fitness
36、services applications. The PHG application provides an APB resource structured in accordance with the XML schema identified in the resourceType element of the root.xml file. The PHG application provides values for a subset of the APB elements as identified in Table 8-1. The Health & Fitness services
37、 application when it receives the APB resource from the PHG application fills in the remaining elements as defined in Table 8-1. During the establishment of an APS, a pair of identifiers is allocated by the Health & Fitness services application. These identifiers are part of the APB resource. One id
38、entifier in the pair is associated with the PHG application (PHG APBI) and the other identifier is associated with the Health & Fitness services application (services APBI). The services APBI together with the PHG APBI identify the APB instance and shall be unique across all the APSs being managed b
39、y the Health & Fitness services application. 8.1 APB resources The APS-CCC-Services defines a management interface that uses HTTPS and hData. These mechanisms prescribe a RESTful and secure access mechanism to information defining the APS, which is contained in the APB resource. The starting point f
40、or the hData layout of this interface is the root.xml file. For a Health & Fitness services application implementing the APS-CCC-Services the root.xml file shall contain the entries as specified in Figure 8-1, Figure 8-2 and Figure 8-3. APS-CCC-Services http:/ handle.itu.int/11.1002/3000/hData/APS/2
41、017/01/H.812.4.pdf Figure 8-1 Profile element indicating capability The entry in Figure 8-1 indicates to the PHG application that the Health & Fitness services application supports the APS message transfer infrastructure (APS-CCC-Services). This entry shall appear exactly as shown in Figure 8-1. Rec
42、. ITU-T H.812.4 (11/2017) 7 APB http:/handle.itu.int/11.1002/3000/hData/APS/2017/01/H.812.4.pdf application/xml http:/handle.itu.int/11.1002/3000/hData/APS/2017/01/APBConfigResource.xsd Figure 8-2 ResourceType element describing APB content The entry in Figure 8-2 provides a description and the stru
43、cture (such as a schema) of the APB. The entry shall appear exactly as shown in Figure 8-2. path/to/post/folder APS-CAC-Services true APB Figure 8-3 Section element describing where to POST The entry in Figure 8-3 identifies a URL to which the PHG application performs the initial POST in the APS est
44、ablishment. The element value shall be that of the element value in the element and the value shall be APB. The element shall be present in this specification and it shall be set to true (it is optional in the hData specification). The element shall be present but the URL value is determined by the
45、application. Table 8-1 and Table 8-2 describe the contents of the APB resource that characterizes the APS. The APB resource is expressed as an xml document, an example of which is shown in Figure 8-4. The example in Figure 8-4 shows a PHG application supporting MQTT and an SMS shoulder tap. See Appe
46、ndix II for the APB resource schema. Table 8-1 APB xml elements provided by PHG application Element Usage supportedMH Mandatory A space-separated list identifying the message handlers that are supported by the PHG application. All PHG applications that support APS message transfer shall support the
47、APS diagnostic handler as denoted below. The three uppercase characters “APS“ This value shall be ignored by the PHG application whenever the APB resource is obtained from the Health & Fitness services application. 8 Rec. ITU-T H.812.4 (11/2017) Table 8-1 APB xml elements provided by PHG application
48、 Element Usage Note If a vendorspecific message handler is used, the identifying string should have properties that minimize the potential for a collision with another uncoordinated vendor message handler. exchangeMechanism Mandatory A space-separated list identifying the underlying technologies tha
49、t are being used by the PHG application to support message exchanges. The PHG application shall identify each technology that it supports in an ordered list with the first entry in the list being its preferred choice. The only currently supported exchange mechanism is MQTT. This value shall be ignored by the PHG application whenever the APB resource is obtained from the Health & Fitness services application. shoulderTapMechanism Mandatory A space-separated list identifying the underlying techn
