Presentation on theme: "IEEE 11073 20101 ACSE_rev02.ppt SLIDE 1 IEEE 11073 20101 Application Profile – Association Control Function Dan Smith,"— Presentation transcript:
IEEE 11073 20101 ACSE_rev02.ppt SLIDE 1 IEEE 11073 20101 Application Profile – Association Control Function Dan Smith, email@example.com@westhealth.org Harry McKee, firstname.lastname@example.org@westhealth.org
IEEE 11073 20101 ACSE_rev02.ppt SLIDE 3 Scope Summary: Define compatible set of ASN.1 messages for both 20101 & 20601 Allow all data to be communicated using the MDER Encoding Rules Support the existence of multiple-protocol managers that support both POC & PHD devices
IEEE 11073 20101 ACSE_rev02.ppt SLIDE 4 Assumptions The CNS (20401) proposal will identify unique network paths (ie. TCP port) for each standard (classic 20101, 20601 & proposed harmonized) Existing PHD devices properly verify the fields in existing 20601 messages (ie data- proto-id) before using the data received
IEEE 11073 20101 ACSE_rev02.ppt SLIDE 5 General Approach Adopt the 20601 approach to messaging Move away from ACSE Standard Add new data fields to the 20601 structures to capture needed 20101 data Implement a NULL Presentation & Session Layer – aka remove their functionality from association.
IEEE 11073 20101 ACSE_rev02.ppt SLIDE 7 Advantages to this approach POC & PHD devices will share the same messaging structure at a high level All message data is encoded using MDER POC-specific data is captured with the new MDAPAssociationInformation field Simplifies Implementation Allows managers to more easily support multiple association styles*. * See disadvantage page
IEEE 11073 20101 ACSE_rev02.ppt SLIDE 8 Disadvantages to this approach May require separate port for classic ACSE messages vs. new style messages due to overlap between MDAP-XT session layer & PHD-defined AARQ (0xe2) Moves away from standardized association towards a custom solution for medical devices
IEEE 11073 20101 ACSE_rev02.ppt SLIDE 12 Open Issues Is there a need to support other encoding rules (such as BER?) MDER-only makes implementations easier Must be able to encode all data properly Must account for all applications of this protocol Is anything lost by being MDER-only?
IEEE 11073 20101 ACSE_rev02.ppt SLIDE 13 Open Issues Adding in a fast-association component Match PHD's config-id based fast association feature Reduce amount of data transferred during connection process POC order of association (initial message sent from manager) makes things more difficult Possibly could be solved with a second AARQ message
IEEE 11073 20101 ACSE_rev02.ppt SLIDE 14 Next Steps Write up a full proposal Discuss it on a periodic web-ex Finalize proposal & vote – hopefully at F2F in Jan.