Re: FRCP - OML Clarification
I'm forwarding this to the OML mailing list to get the others here at NICTA involved.
I think you are basically right when you say that some kind of proxy is needed that reads measurements from
your cloud and sends them as measurement streams to wherever the user wants them. I don't know how the data
is organised in your cloud and how to get it out, but it should be possible to convert it into an OML
There would be one OMF6 RC running inside your cloud, which accepts CREATE messages via FRCP. These
messages are encapsulated in an assertion envelope, as described in . If the validated assertion says
that the user can access the measurement points he/she wants to create in the CREATE message, your OMF6 RC
can then start your proxy application, which fetches the data from your cloud and forwards it to the
user-specified destination as an OML stream.
So I think what you want to have is:
d. 1 global RC which starts OML proxies with custom defined measurement points as requested
More on FRCP can be found at . Everything you need to know for getting started with your own OML
application can be found at .
On 12/02/2013, at 7:07 PM, Pablo Sotres <psotres@...> wrote:
> Hi Christoph,
> This is exactly the dark hole we were saying. In service layer we don't have any application deployed on the
node that the user can interact with by using OMF (or whatever). All nodes are periodically sending their
sensor measurements to the SmartSantander backend, and eventually all those measurements ends up in a
cloud owned by Telefonica. The point is that the security in this cloud is controlled by firewall so we are
going to create a kind of proxy for the external experimenters to be able to get those service measurements
using the authorization scheme in Fed4Fire, and we would like to do it by using OML.
> In a very simplified way, service layer experimentation in SmartSantander consists in getting
measurements from a big database and processing them to create added value services on top of this
information. There isn't any traditional "measuring application" so once the experimenter has the
service measurements it is on his own to process them the way he wants or need.
> So, summarizing, we would like to create a component in this proxy that will allow each experimenter to
create an OML MP to redirect the service measurements he is subscribed to (from all the measurements that
the proxy is getting from the cloud) to its own "thin" experiment controller as long as the reservation
(which is shared with other users) is valid.
> In this case, and for N concurrent experimenters accessing the system this would imply...
> a. Having N MPs controlled by N OMF6 RC
> b. Only 1 global RC controlling the lifecycle of all the OML MP's
> c. 1 global RC and 1 OML MP's with multiple configurations (one for each experimenter)
> As we are not very experienced in OMF/OML, Could you please provide us some starting hints on how to deal
> El martes, 12 de febrero de 2013 7:23:42, Christoph Dwertmann escribió:
>> Hi Pablo and Jorge!
>> If you don't need an OMF EC/RC on your testbed, that's fine. You can still use OML to measure things.
However if you want to dynamically configure MPs over FRCP, it may make sense to use an OMF6 RC for that. What
are you measuring and how is that set up? If, for example, you are measuring something by starting an
application on the node, this application could be started by an OMF6 RC, which passes OML configuration
parameters to it.
>> Do you already have a "measuring application"? Or does the user need to create one? Or does this work
>> Kind regards,
>> Christoph Dwertmann
>> On 11/02/2013, at 10:18 PM, Pablo Sotres <psotres@...> wrote:
>>> Hi Christoph, Alina,
>>> How is everything going after the meeting?
>>> We at UC are having some discussions regarding what will be the best approach to transform
SmartSantander into an OML compliant testbed. As you know, in SmartSantander service layer we don't
really need an experiment controller, but after learning about how FRCP in OMF6 interacts with OML MP's we
are starting to think in a thin experiment control component. This component should allow each
experimenter to create (in real time) one OML MP and configure it in order to get the service measurements
he is subscribed to (only if he is allowed to) and once the experiment is finished this OML MP should "die".
>>> The theory, if we understood Alina correctly, shouldn't be very difficult. The big black hole we still
have is what would be the mechanism to create those OML MPs in real time, having in mind that we don't have
real reserved resources to interact with OMF.
>>> Best regards,
>>> Pablo and Jorge
>> The information in this e-mail may be confidential and subject to legal professional privilege and/or
copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.