MPPS Behavior

greggy

unread,

Mar 5, 2010, 12:30:51 AM3/5/10

to

As I understand it, the MPPS SCU will always generate the SOP instance
UID, and the SCP should reject any N-CREATE that does not provide this
value. Is this correct?

If so, I notice that both the DCM4CHEE and JDICOM MPPS SCPs will take
the SOP instance UID and use it as the SCU provides it, but will
generate a UID if one is not provided in 0000,1000 tag and return it
like a typical N-CREATE response would.

Are they correct or does the standard require that only the SCU
generate this value?

Also, I noticed that with JDicom, the Modality SCU generates an MPPS
dataset with group 2 tags that are then used to generate the group 0
tags during transmission. It is in tag 0002,0003 that the UID is
initially formed. Is the translation from 0002,0003 to 0000,1000
proprietary to JDicom or a DICOM standard?

Greg

Marco Eichelberg

unread,

Mar 5, 2010, 2:49:09 AM3/5/10

to

Greg,

> As I understand it, the MPPS SCU will always generate the SOP instance
> UID, and the SCP should reject any N-CREATE that does not provide this
> value. Is this correct?

No. The SOP Instance UID in the N-CREATE-RQ message is optional,
see PS3.7 section 10.1.5.1.

> If so, I notice that both the DCM4CHEE and JDICOM MPPS SCPs will take
> the SOP instance UID and use it as the SCU provides it, but will
> generate a UID if one is not provided in 0000,1000 tag and return it
> like a typical N-CREATE response would.
>
> Are they correct or does the standard require that only the SCU
> generate this value?

They are absolutely correct. This is the bevaviour mandated by the
standard.

> Also, I noticed that with JDicom, the Modality SCU generates an MPPS
> dataset with group 2 tags that are then used to generate the group 0
> tags during transmission. It is in tag 0002,0003 that the UID is
> initially formed. Is the translation from 0002,0003 to 0000,1000
> proprietary to JDicom or a DICOM standard?

(0002,0003) is part of the meta-header in a DICOM file and will
contain a copy of the SOP Instanace UID there. The attribute is not
part of the main dataset, is never used in network communication
and certainly not as part of the N-CREATE procotol.
If JDicom actually transmits the (0002,0003) attribute as part
of the N-CREATE dataset, they would be in violation of the standard.

Regards,
Marco Eichelberg
OFFIS

greggy

unread,

Mar 5, 2010, 3:30:10 PM3/5/10

to

On Mar 4, 9:49 pm, Marco Eichelberg <eichelberg_nos...@offis.de>
wrote:

Marco Eichelberg,

Thanks for the response. To back up a bit, I did not say that they
send the group 2 tags. I said that they use the information in the
group 2 tags when they transmit. What is entered into (0002,0003) is
transmitted in (0000,1000). (0002,0003) is never sent.

Back to my last question, is the use of (0002,0003) to populate
(0000,1000) a proprietary mechanism that JDicom uses, or is this
expected - even somewhat?

Greg

Marco Eichelberg

unread,

Mar 8, 2010, 2:52:45 AM3/8/10

to

Greg,

> Back to my last question, is the use of (0002,0003) to populate
> (0000,1000) a proprietary mechanism that JDicom uses, or is this
> expected - even somewhat?

All implementations I am aware of will populate (0002,0003)
from the content of (0008,0018) MediaStorageSOPInstanceUID
or possibly from
(0000,1000)/(0000,1001) Requested/AffectedSOPInstanceUID
and not the other way round. However, since these attributes
where present must always contain the same UID, the result
is pretty much the same.

Regards,
Marco Eichelberg

greggy

unread,

Mar 8, 2010, 3:08:44 PM3/8/10

to

On Mar 7, 9:52 pm, Marco Eichelberg <eichelberg_nos...@offis.de>
wrote:

That is interesting to hear.

I have in my notes that according to IHETF A.1-1, (0008,0016) and
(0008,0018) were both part of the dataset for MPPS N-CREATE and then
obsoleted, with the expectations of (0000,0002) and (0000,1000)
conveying the information instead.

Thanks for the insight.

Greg