Presentation is loading. Please wait.

Presentation is loading. Please wait.

IEEE 11073 20101 ACSE_rev02.ppt SLIDE 1 IEEE 11073 20101 Application Profile – Association Control Function Dan Smith,

Similar presentations


Presentation on theme: "IEEE 11073 20101 ACSE_rev02.ppt SLIDE 1 IEEE 11073 20101 Application Profile – Association Control Function Dan Smith,"— Presentation transcript:

1 IEEE ACSE_rev02.ppt SLIDE 1 IEEE Application Profile – Association Control Function Dan Smith, Harry McKee,

2 IEEE ACSE_rev02.ppt SLIDE 2 Agenda Scope Assumptions Approach Sample Advantages Disadvantages Removed fields Issues Next Steps

3 IEEE ACSE_rev02.ppt SLIDE 3 Scope Summary: Define compatible set of ASN.1 messages for both & Allow all data to be communicated using the MDER Encoding Rules Support the existence of multiple-protocol managers that support both POC & PHD devices

4 IEEE ACSE_rev02.ppt SLIDE 4 Assumptions The CNS (20401) proposal will identify unique network paths (ie. TCP port) for each standard (classic 20101, & proposed harmonized) Existing PHD devices properly verify the fields in existing messages (ie data- proto-id) before using the data received

5 IEEE ACSE_rev02.ppt SLIDE 5 General Approach Adopt the approach to messaging Move away from ACSE Standard Add new data fields to the structures to capture needed data Implement a NULL Presentation & Session Layer – aka remove their functionality from association.

6 IEEE ACSE_rev02.ppt SLIDE 6 AARQ ASN.1 AarqApdu ::= SEQUENCE { assoc-version AssociationVersion, data-proto-list DataProtoList } AssociationVersion ::= BITS-32 { assoc-version1 (0) -- association protocol version 1 } DataProtoList ::= SEQUENCE OF DataProto DataProto ::= SEQUENCE { data-proto-id DataProtoId, data-proto-info ANY DEFINED BY data-proto-id } DataProtoId ::= INT-U16 { data-proto-id-empty (0), data-proto-id (20101), data-proto-id (20601), data-proto-id-external (65535) } MdapAssociationInformation ::= SEQUENCE { user-info MDSEUserInfo } MDSEUserInfo ::= SEQUENCE { protocolVersion ProtocolVersion, nomenclatureVersion NomenclatureVersion, functionalUnits FunctionalUnits, systemType SystemType, startupMode StartupMode, optionList AttributeList, supportedAProfiles AttributeList }

7 IEEE 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

8 IEEE 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

9 IEEE ACSE_rev02.ppt SLIDE 9 Removed Fields Proposal removes application-context-name (AARQ/AARE) AARQ-apdu ::= [APPLICATION 0] IMPLICIT SEQUENCE { protocol-version [0] IMPLICIT BIT STRING {version1(0)} DEFAULT {version1}, application-context-name [1] Application-context-name, user-information [30] IMPLICIT Association-information }

10 IEEE ACSE_rev02.ppt SLIDE 10 Removed Fields Proposal removes the Associate-source-diagnostic field AARE-apdu ::= [APPLICATION 1] IMPLICIT SEQUENCE { protocol-version [0] IMPLICIT BIT STRING {version1(0)} DEFAULT {version1}, application-context-name [1] Application-context-name, result [2] Associate-result, Result-source-diagnostic [3] Associate-source-diagnostic, user-information [30] IMPLICIT Association-information } Associate-source-diagnostic ::= CHOICE { acse-service-user [1] INTEGER { null(0), no-reason-given(1), application-context-name-not-supported (2), }, acse-service-provider [2] INTEGER { null(0), no-reason-given(1), no-common-acse-version(2) }

11 IEEE ACSE_rev02.ppt SLIDE 11 Removed Fields POC & PHD aborts are slightly different ABRT-apdu ::= [APPLICATION 4] IMPLICIT SEQUENCE { abort-source [0] IMPLICIT ABRT-source } ABRT-source ::= INTEGER { acse-service-user(0), acse-service-provider(1) } AbrtApdu ::= SEQUENCE { reason Abort-reason } Abort-reason ::= INT-U16 { undefined(0), buffer-overflow(1), response-timeout(2), configuration-timeout(3) }

12 IEEE 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?

13 IEEE 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

14 IEEE 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.


Download ppt "IEEE 11073 20101 ACSE_rev02.ppt SLIDE 1 IEEE 11073 20101 Application Profile – Association Control Function Dan Smith,"

Similar presentations


Ads by Google