Issues for Mailing list of the PIM & PSM For Software Radio Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 7853: Section 9.2.6.1 IStream localSetup operation
Issue 7869: Unable to import the UML Profile for SWRadio into another UML tool
Issue 7894: A port may have characteristics
Issue 8697: SWRadio UML Model is not referenced in the spec

Issue 7853: Section 9.2.6.1 IStream localSetup operation (swradio-ftf)

localSetup operation of the IStream interface should take the streamID parameter at a minimum. It may also provide access to the parameters defined by the IQualityOfServiceConnection facility. 

Discussion:
The FTF needs to look into the overlap between this spec and the CCM Streams specification. FTF will look into CCM Streams revised submission.
Will be deferred since CCM revised submission that the resolution may take advantage of is delayed until April 2005 TC Meeting and the FTF has no time to explore other options at this juncture, with only 1 month prior to end of 1st FTF

Disposition:	Deferred     Discussion:
This issue is deferred to the follow-on RTF, since RTF #1 ran out of time.  
Disposition:	Deferred

Save the UML Profile for SWRadio into XMI when there is UML 2 tool support
that allows UML profiles creation and supports saving the profile as XMI.

Discussion:
We had several discussions with IBM, Zeligsoft and other UML tool vendors. 
We are waiting for OMG to decide what we are going to use for UML model exchanging.  After that, the SWRADIO FTF/RTF can decide how to go about resolving this issue.
Disposition:	Deferred

Problem: A port may have characteristics, such as throughput, latency,
non-blocking time, etc.


Proposed Solution: Add a characteristics property (TAG value) to the
SWRadioPort
stereotype. Add characteristics tag value for SWRadioPort in Table 8-3
Interface
and Port Stereotypes.


Related to issue 7888


Add to


Attributes section for SWRadioPort


characteristics : CharacteristicProperty [*]


The characteristics attribute defines the characteristics for a port.

Discussion:
Jerry:  
Add a characteristics property (TAG value) to the SWRadioPort stereotype. Add characteristics tag value for SWRadioPort in Table 8-3 Interface and Port Stereotypes.

Related to issue 7888

Add to Attributes section for SWRadioPort characteristics:  characteristicProperty [*]

The characteristics attribute defines the characteristics for a port.

December 9, 2004 FTF Telecon:  
·	Jerry requested to get group consensus before assignees proceed with the recommended resolution.  
·	John confirmed for Jerry that there is a QoS Profile in RT UML.  
·	Jerry:  We also want to look at QoS characteristics and see if want to add this to our list of characteristics, i.e. consider allowing a port to express what its characteristics are.
·	Jerry:  We need to look at an RTF to see if we want to have the RT UML profile updated as a part of UML 2.0.

Sunday January 30th, 2005, Burlingame Technical Meeting:
Neli took care of proposing the request to the RTESS RTAD WG and getting the above proposal into the group's RFP for the Burlingame Technical Meeting.

February 2, 2005 Burlingame Meeting:

Neli and Michael:  Provide rationale as to why this issue is being deferred to the RTF.  
Tansu:  Is not adding a characteristics property to a port allowing users to do whatever they want?
Michael:  Per the tag, if you read the model, you can tell that this component that has this port type can have this behavior.   
Tansu is concerned about the benefit of defining characteristics that no one but that component and that port understand.  
Michael:  This is a facility for defining port characteristics for possible future "registration".
Tansu:  If there is a minimum set of characteristics, they should be defined in addition to providing the proposed facility for defining more.  
Neli:  Where is the appropriate place for defining these minimum characteristics?
Tansu:  8.1.4 Interface and Port Stereotypes.  Currently no section for SWRadioPort, since it currently has no TAGs defined.  A new subsection must be added. 
See Eric Nicolet from Thales for a possible minimum set.  Eric.NICOLLET@fr.thalesgroup.com.  He presented his view of this minimum set of characteristic at the January SCA 3.1 Workshop.
Neli:  Finalized RTESS RFP for Adding QoS Characteristics to Ports, Burlingame Meeting February 2005. The UML Profile for MARTE RFP has been posted to the OMG server with the  document number realtime/2005-02-06 at URL
http://www.omg.org/cgi-bin/doc?realtime/2005-02-06

March 10, 2005 Telecon:
Neli and Jerry:  Handle just like the lack of descriptors in the specification.  As a resolution, point to the real time specification and expand to the full resolution in RTF.
Disposition:	Deferred
Discussion:
Per recommendation from and working with the SWRADIO FTF, the RTESS RTAD WG incorporated the desire for adding QoS characteristics to Ports into the UML Profile for MARTE RFP at the February 2005 Burlingame Technical Meeting, document number realtime/2005-02-06.  Hoping to resolve this issue by leveraging from the UML 2.0 Profile for MARTE (as opposed to defining such TAGs in the UML Profile for Software Radio), this issue is deferred pending the draft of the UML 2.0 Profile for MARTE specification which expresses QoS characteristics for Ports.

The SWRadio UML model is not mentioned in the SWRadio specification. Add a non-normative reference in the convenience document for the UML model. Add a paragraph explaining that the UML model is non-normative at the end of Section 6.2.