IEEE 11073 20101
Download
1 / 14

IEEE 11073 20101 Application Profile – Association Control Function - PowerPoint PPT Presentation


  • 83 Views
  • Uploaded on

IEEE 11073 20101 Application Profile – Association Control Function. Dan Smith, [email protected]esthealth.org Harry McKee, [email protected] Agenda. Scope Assumptions Approach Sample Advantages Disadvantages Removed fields Issues Next Steps. Scope Summary:.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' IEEE 11073 20101 Application Profile – Association Control Function' - brilliant


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

IEEE 11073 20101 Application Profile – Association Control Function

Dan Smith, [email protected]

Harry McKee, [email protected]


Agenda

  • Scope

  • Assumptions

  • Approach

  • Sample

  • Advantages

  • Disadvantages

  • Removed fields

  • Issues

  • Next Steps


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


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


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.


AARQ ASN.1

MdapAssociationInformation ::= SEQUENCE {

user-info MDSEUserInfo

}

MDSEUserInfo ::= SEQUENCE {

protocolVersion ProtocolVersion,

nomenclatureVersion NomenclatureVersion,

functionalUnits FunctionalUnits,

systemType SystemType,

startupMode StartupMode,

optionList AttributeList,

supportedAProfiles AttributeList

}

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 (20101),

data-proto-id-20601 (20601),

data-proto-id-external (65535)

}


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


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


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

}


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)

}

}


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)

}


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?


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


Next Steps

  • Write up a full proposal

  • Discuss it on a periodic web-ex

  • Finalize proposal & vote – hopefully at F2F in Jan.


ad