The base POSIX version of the AEP is being updated within the specification. In the update a new set of Error Conditions has been defined. The new error conditions need to be evaluated in order to determine whether or not they should be included within the specification.

The meta-model needs to allow implementation properties (e.g., entry point arguments for environment types) to be defined at the implementation level

Recommendation:
Complex data type should be defined in UML Profile for SWRadio.

Resolution:
Mark have requested SBC DTF to consider this problem.

Table 7.2 shows 11 stereotypes, but the 7.1.4 subsections support only 2 of them (RequiresPort and StreamPort). The other 9 are NOT detailed.

I believe there is an error in Figure 7.1 in the "Component Document Type Definition Specification" dtc/06-04-22. Please note that the "DevicePackageDescriptor" is NOT showing any dependency on "Properties". This is a defined relationship in SCA 2.2.2.

Proposed Resolution: DPD ----> (0..*) Properties

In Section 6.1 of the PIM & PSM for SW Radio intro book dtc/06-04-18,
currently under DTC vote, one finds these references to Life Science specs:

===============================

• Life Sciences Identifiers (LSID) - There are many
  cross references in the model defined by this specification. They are
  expressed using LSIDs. The relevant specification
  is available as OMG documents: formal/04-12-01 and dtc/04-08-03.
• Genomic Map (GM) - The definitions in GM
  specification are either too limiting or too generic for SNPs purposes.
  The GM was designed at the time when genetic maps
  were the only genome wide maps. Current focus is on sequence
  maps.
  ===============================

Presumably this is a cut-n-paste error/artifact, and should be repaired.
The reference to BQS may be spurious as well.

Issue:

The domain manager register operations take in an object reference, so a callback is needed to get the identifier and profile attributes thus being inefficient.

Extent of Change: Major

Resolution:

Add to the DeviceManagerRegistration interface operations, identifier and profile parameters to eliminate the callbacks.

Problem

The domain manager and device manager unregister operations take in an object reference, which cannot be used directly for determining what component to unregister since one cannot compare on object references, so a callback is needed to get the identifier for unregistering service thus being inefficient.

Proposed Solution: Replace the unregistering operations and remove device parameters with an unregistering identifier parameter of string type. This change affects CompositeDevice, DeviceManagerRegistration and ServiceRegistration interfaces.

The following issue was raised in the SDR Forum's SCA WG:

The Audio API does not include an interface for configuring or exchanging
information that is specific to a stream or channel. Such information might
include: quality of service parameters, packet size, symbol size, priority,
and audio codec.

The following issue was raised in the SDR Forum's SCA WG:

The group was concerned that without a control structure along with the data
payload, the Audio API might impose unnecessary constraints. Discussion
within the group identified that a control structure containing at least a
Stream Id, a Payload Length, and a Sequence number could provide much
greater flexibility that the API as currently stated

The following issue was raised in the SDR Forum's SCA WG:

The PTT function is a oneway call and the audio device does not wait for an
RTS signal. This situation prevents the waveform from providing a negative
response to the PTT. If the waveform is unable to transmit data at the time
of a PTT, does the waveform just ignore/drop the data without alerting the
audio device or user through some specified mechanism?

Simple Property Datatype. This allows users to form common definitions that can be used for components properties. A data/primitive stereotype that similar tags as RadioProperty. Add to properties section.

Wrong Stereotypes for Property Types. Make struct property and test def property types stereotypes of datatype instead of class in the properties. These should be treated type definitions not classes. EnumerationProperty?

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.

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.

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.

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.