Topic 5: targetting Based on UID

[Kevin Hawkins]

Initially I was very pro adding this feature but in thinking through it I
have done an about turn - I am raising the topic to see if there is an
angle
I have missed.

Currently - it is not possible to target a device based on its UID eg

TargetUID="FF123400"

Let me explain why this was not permitted in v1.2. xAP is
essentially a broadcast protocol and interested parties can eavesdrop on
any
conversation that they want. As long as we stay with UDP, using the same
port and the broadcast address (and a defined packet format) then this will
remain true. It cannot be circumvented without changing one or other of
these.
Currently a device when sending a xAP message must include its UID
and its (longform) source address in all its transmissions. This is so that
listeners wanting to monitor the information based on source address or
more
importantly a wildcarded source address can do so. Eg
source="UKUSA.TempSensor.>" to monitor all the temperature
sensors from
UKUSA. It is critical to wildcarding operation that the full source address
is present.
Now suppose that we allowed targeting based on UID. TargetUID =
FF123400. The targets longform address is not being sent so another xAP
sitting on the network and monitoring all messages based on
Target=UKUSA.TempSensor.* would not see such a message. Such a xAP device
might for example be monitoring temperature sensors to see if any setpoints
were changed in a building. Can we get around this ? Well yes we would have
to mandate that whenever a target=UID was sent the longform address was
also
included - this is only the same thing as saying that when we send UID= we
must also send our source address in full.
So what would be the benefit of allowing TargetUID= in a header ? I
originally had two areas of interest in this.
My first was as a solution to storage restrictions in small PIC
devices. The UID is currently invaluable in that a xAP receiver can simply
link itself to a transmitter by storing the UID (rather than the source
address) of the transmitter in memory - so instead of having to filter
"UKUSA.FourGangSwitch.Downstairs.Lounge:Switch1" it can store
FF121201 and
all is well - 4 bytes - a saving of 90% over the full string - a huge
advantage of xAP over say xPL as well - great for low spec devices. So what
about the converse ? How about a low power switch being able to just target
a lamp based on UID - now again the low power switch can make the same
savings - but actually it can't because it would have to send the full
target address as well. Are there ways around this ?? Well yes, but they
are
not tidy. You could enlist a 'helper' (cache) on a xAP network that
monitored any devices targeting just based on UID and filled in the targets
full address as well, or you could just allow it as a device restriction.
My
feelings now are that the latter is unacceptable and the former
overcomplicates the whole operation of xAP. Is there any other way around
this anyone can think of ?? Bear in mind that a PIC controller might
typically only have 10's of bytes of RAM although these addresses could be
held in external EEPROM as well.
Secondly - configuration - being able to target a device that has no
source name set up yet. Again I thought this would be a fantastic advantage
of TargetUId= but in reality you can just use the UID as a temporary full
source address anyway as it should be unique Target=FF123400 or if xAPs are
picky on their source address parsing then perhaps Target=FF.1234:00. Of
course the UID has to be unique in the first place but that's a
configuration issue. So again no benefit...
Whilst on this UID usage point can I stress that the xAP spec
reserves 00 and FF in all cases in the UID component places as 'reserved ie
xx0000xx, xxxxxxFF and 00xxxxxx etc are reserved. Local network ID's should
be FF (one of the reserved cases) and devices with no hardware subs should
end in 00. I am expecting that we may use xxFFFFxx as a way of introducing
virgin xAP devices onto a network and auto configuring them, but that's
another topic.
So anyone got a case for Targeting based on UID or shall we close
this one ?

Kevin