ieee 11073 20101 acse_rev02.ppt slide 1 ieee 11073 20101 application profile – association control...
TRANSCRIPT
IEEE 11073 20101 ACSE_rev02.ppt SLIDE 1
IEEE 11073 20101 Application Profile – Association Control Function
Dan Smith, [email protected]
Harry McKee, [email protected]
IEEE 11073 20101 ACSE_rev02.ppt SLIDE 2
Agenda
ScopeAssumptionsApproachSampleAdvantagesDisadvantagesRemoved fieldsIssuesNext Steps
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 6
AARQ ASN.1AarqApdu ::= 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)
}
MdapAssociationInformation ::= SEQUENCE {
user-info MDSEUserInfo
}
MDSEUserInfo ::= SEQUENCE {
protocolVersion ProtocolVersion,
nomenclatureVersion NomenclatureVersion,
functionalUnits FunctionalUnits,
systemType SystemType,
startupMode StartupMode,
optionList AttributeList,
supportedAProfiles AttributeList
}
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 fieldSimplifies ImplementationAllows 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 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
}
IEEE 11073 20101 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)
}
}
IEEE 11073 20101 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)
}
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 proposalDiscuss it on a periodic web-exFinalize proposal & vote – hopefully at F2F
in Jan.