From Ernoe.Kovacs at neclab.eu Wed Feb 1 07:43:52 2012 From: Ernoe.Kovacs at neclab.eu (Ernoe Kovacs) Date: Wed, 1 Feb 2012 06:43:52 +0000 Subject: [Fiware-iot] IoT weekly meeting [Standardisatisation] Message-ID: <8152E2132B13FB488CFD1947E2DEF19C24F7918A@PALLENE.office.hd> Thierry, Lorant, Denes, [Unfortunately I will not be in the PhC] With respect to the agenda item (2). (a) All FIWare partners are requested to input a standardization plan !!! Please sent to Lindsay ASAP, deadlines are all missed and only 5 partners have responded yet... (b) All WPLs have to input a section according to the attached powerpoint. This was said by Juanjo in the meeting with WP5 /* That a section needed to be written was always clear, but the change in structure is now making it more clear */ As said, deadlines are all passed, so please speed up your contributions. Expect also a lot of reminder emails. @Thierry, Lorant There seems to be no list of Names/eMails for WPL and WPAs available. As you might know them by hart due to your frequent calls/meetings. Can you sent them to us. We asked Juanjo and Juan several times, but no answer... -Ern? From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Farkas, Lorant (NSN - HU/Budapest) Sent: Dienstag, 31. Januar 2012 12:43 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] IoT weekly meeting When: 2012. febru?r 1. 11:00-12:30 (GMT+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague. Where: telco/webex Note: The GMT offset above does not reflect daylight saving time adjustments. *~*~*~*~*~*~*~*~*~* Dear All, Please mind the new PIN code: 1628 For our next weekly meeting we are proposing the following topics: 1. The testbed topic: we have an Excel sheet to be filled, need to better understand what to achieve for the first release <> 2. Standardization topic: this is a deliverable for the end of this week <<[Fiware] Standardisation Plan - 5 out of 26 Partners have answered - can you add your input?>> 3. Architecture topic: should agree on the final version of the FMC diagram and agree on the next steps which means mainly editing in the wiki (deliverable is due 17th of February) We would also like to shift this instance from 10:00-11:30 to 11:00-12:30 at the request of our WPL, hopefully most of you can make it. Thanks & Br, Lorant Dear All, Let's resume our weekly meeting starting from next week in the usual day/time, which is Wednesday, 10:00 AM (CET) to 11:30. Either WPL or WPA will be present to host the meeting. In case we find good reason to skip the meeting, then we will skip it, but I propose not to deviate from this slot. Thanks & Br, Lorant Topic: IOT WP weekly Date: Every Wednesday, from Wednesday, 10 August 2011 to Wednesday, 26 March 2014 Time: 10:00, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 709 472 921 Meeting Password: FI-WARE ------------------------------------------------------- To join the online meeting ------------------------------------------------------- 1. Go to https://nsn.webex.com/nsn/j.php?ED=175018962&UID=0&PW=NYzEzYWM0ZTNk&RT=MTgjMjM%3D 2. Enter your name and email address. 3. Enter the meeting password: FI-WARE 4. Click "Join Now". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://nsn.webex.com/nsn/j.php?ED=175018962&UID=0&PW=NYzEzYWM0ZTNk&ORT=MTgjMjM%3D ------------------------------------------------------- NSN Voice Conference information Conference ID: 58465 New PIN: 1628 Making a conference call * from the office: 8071870 (in Finland and Germany) * from out of office: +358 7180 71870 (in Finland) and +49 89 5159 43800 (in Germany) All out-of-office conference access numbers are listed in page https://inside.nokiasiemensnetworks.com/global/MyServices/IT/Infrastructure_Services/RealTimeCommunication/VoiceService/NSNVoiceConference/MakingaCall/LocalAccessNumbers/Pages/Outofofficenumbers.aspx. Please check and prioritize them. If there is no access number for your country then please use access numbers of the area where to the calling costs are lowest. ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://nsn.webex.com/nsn/mc 2. On the left navigation bar, click "Support". You can contact me at: lorant.farkas at nsn.com Argentina - Buenos Aires +54 11 5983 9400 (PRIMARY) or +54 11 4814 9373 Argentina - Cordoba +54 35 1568 2208 Australia - Sydney +61 28 014 7189 (PRIMARY) or +61 29 429 9664 Australia - Melbourne +61 38 739 4333 Austria +43 72 088 0245 Bahrain +97 31 619 9028 Belgium - Generic +32 1448 0116 Belgium - Diegem-Machelen +32 2710 3300 Brazil - Belo Horizonte +55 31 3956 0546 Brazil - Brazil +55 61 3717 2043 Brazil - Curitiba +55 41 3906 0826 Brazil - Manaus +55 92 3652 7576 Brazil - Rio De Janeiro +55 21 3958 0804 (PRIMARY) or +55 21 3431 1999 Brazil - Salvador +55 71 3717 5351 Brazil - Sao Paolo +55 11 5508 0630 Bulgaria +359 2491 7085 Canada - Ajax +1 90 5619 4346 Canada - Burnaby +1 60 4456 5897 Canada - Hamilton +1 905 581 0212 Canada - Mississauga +1 289 360 3950 Canada - Montreal +1 51 4789 9125 Canada - Ottawa +1 61 3800 0568 Chile - Santiago +56 2350 6485 China - Mainland +86 10 8405 5000 ext 1870 China - Beijing +86 10 8405 5000 ext 1870 China - Chengdu +86 28 8689 0188 ext 1870 China - Dongguan +86 0769 2240 2844 ext 1870 China - Guangzhou +86 20 8755 6190 ext 1870 China - Hangzhou +86 571 8722 0877 ext 1870 China - Hong Kong +852 259 70220 ext 1870 China - Kunming +86 871 362 2880 ext 1870 China - Shanghai +86 21 6101 1870 ext 1870 China - ShenZhen +86 755 8613 3688 ext 1870 China - Suzhou +86 512 6761 6166 ext 1870 China - Zhengzhou +86 371 6566 9768 ext 1870 Colombia +57 1640 7979 ext 444 Croatia +38 51 777 6122 Czech Republic +42 02 460 19300 Denmark +45 699 18450 (PRIMARY) or +45 3329 2882 Egypt +97 31 619 9028 (Bahrain nbr) Estonia +37 266 67297 Finland +358 7180 71870 France +33 17 061 7813 (PRIMARY) or +33 14 915 1553 Germany +49 89 5159 43800 Greece +30 21 1176 8207 (PRIMARY) or +30 21 1120 3677 Hungary - Budapest +36 17 009 888 Hungary - Kom?rom +36 20 884 2499 India 000 800 100 7777 Indonesia - Jakarta (Menara Mulia/Plaza Kuningan +62 21 2557 9102 Indonesia - Bandung +62 22 8427 5992 Indonesia - Medan +62 61 3001 2702 Indonesia - Semarang +62 24 3300 0702 Ireland +353 1526 2862 Israel +97 29 775 1700 Italy - Milan +39 024 004 2007 Italy - Rome +39 069 481 6656 Japan +81 3 4578 0230 (PRIMARY) or +81 3 5474 7979 Kuwait +97 31 619 9028 (Bahrain nbr) Latvia +37 16 765 2510 Lithuania +37 0 5205 8994 Luxembourg +352 2088 0106 Malaysia +60 323 029 009 Mexico - Mexico City +52 55 3686 9759 (PRIMARY) or +52 55 5261 7245 Mexico - Reynosa +52 89 9909 1555 Netherlands +31 79 346 5225 New Zealand +64 9306 6933 Norway - Oslo +47 21 548 223 Oman +97 31 619 9028 (Bahrain nbr) Pakistan +92 512 092 444 Panama +507 832 7981 Peru +51 1708 5370 (PRIMARY) or +51 1215 7650 Philippines +63 2754 1700 Poland - Warsaw +48 22 398 8116 Poland - Wroclaw +48 71 718 1215 Portugal +351 21 044 4698 Qatar +97 31 619 9028 (Bahrain nbr) Romania +40 36 440 3799 Russia +74 95 725 2706 Saudi Arabia +97 31 619 9028 (Bahrain nbr) Singapore +65 3103 1065 (PRIMARY) or +65 6723 2582 Slovakia +42 12 3300 6924 Slovenia +38 61 600 2713 South Africa - Johannesburg +27 1 0500 2221 South Africa - Pretoria +27 1 2004 2334 South Korea - Masan +82 5 5290 7690 South Korea - Seoul +82 2 2186 5088 Spain +349 1187 5929 Sweden +46 85 250 0862 (PRIMARY), +46 84 100 9299 Switzerland +41 44 279 7943 Taiwan +88 62 8175 9298 Thailand +66 2762 6750 Turkey +90 216 570 2345 Ukraine +38 044 520 2272 UK +44 12 5275 8334 UK - Camberley +44 12 5286 5849 UK - Church Crookham +44 12 5261 1100 UK - Huntingdon +44 14 8087 8220 (PRIMARY), +44 14 8044 4206 UK - London +44 20 3318 1924 United Arab Emirates +97 31 619 9028 (Bahrain nbr) USA - Alpharetta +1 770 871 3050 USA - Arizona +1 480 588 3748 USA - Atlanta +1 404 236 4550 USA - Atlanta Notheast +1 678 317 3165 USA - Austin/Round Rock +1 512 600 2027 USA - Belleville +1 973 547 7982 USA - Boca Raton +1 561 910 2843 USA - Boston +1 617 963 8320 (PRIMARY) or +1 781 993 4850 USA - Burlington +1 781 993 4850 USA - Calabasas +1 818 914 0215 USA - Canoga Park +1 818 914 0215 USA - Cary +1 919 655 1388 USA - Chelmsford/Littleton +1 978 679 0233 USA - Chicago +1 773 303 4710 USA - Dallas +1 214 269 7626 USA - Dallas/Fort Worth +1 214 270 0352 USA - Greenville, NC +1 252 329 1677 USA - Herndon +1 703 483 4485 USA - Johnson City +1 423 952 1545 USA - Kirkland +1 425 242 3113 USA - Miami +1 786 388 4150 or +1 786 329 7177 USA - Naperville +1 630 596 2203 USA - New Brunswick +1 732 579 6483 USA - New Century, KS +1 913 254 5900 USA - New York White Plains +1 914 368 0650 USA - New York Peekskill, White Plains +1 914 293 1885 USA - Palo Alto +1 650 644 1349 USA - Redmond +1 425 242 3113 USA - San Diego +1 858 769 5309 or +1 619 330 9699 USA - Sunnyvale +1 408 419 1750 USA - Washington D.C +1 202 552 4781 Vietnam +84 4 3724 6110 Yemen +97 31 619 9028 (Bahrain nbr) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2012-01-25 FI-WARE Standardization_Request.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 761098 bytes Desc: 2012-01-25 FI-WARE Standardization_Request.pptx URL: From lorant.farkas at nsn.com Wed Feb 1 08:02:07 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Wed, 1 Feb 2012 09:02:07 +0200 Subject: [Fiware-iot] IoT weekly meeting [Standardisatisation] In-Reply-To: <8152E2132B13FB488CFD1947E2DEF19C24F7918A@PALLENE.office.hd> References: <8152E2132B13FB488CFD1947E2DEF19C24F7918A@PALLENE.office.hd> Message-ID: <93D28BDF64839C468B848D14227151A203079B80@FIESEXC014.nsn-intra.net> Hi Ern?, 1. Thanks for the clarifications on the agenda item no. 2 2. I don't know by heart all the WPA/WPL-s. What I recall: I2ND: WPL - Pierangelo Garino, WPA - Hans Einsiedler DCM: WPL - Carlos Ralli Ucendo, WPA - ?? Cloud: WPL - Alex Glikson, WPA - ?? ASE: WPL - Thorsten Leidig, WPA - ?? Security: WPL - Pascal Bisson, WPA - ?? Tools: WPL - Davide Dalle Carbonare For the rest maybe Thierry or D?nes can help. We don't have access to the admin interface of the mailing lists, unfortunately. Br, Lorant From: ext Ernoe Kovacs [mailto:Ernoe.Kovacs at neclab.eu] Sent: Wednesday, February 01, 2012 7:44 AM To: Farkas, Lorant (NSN - HU/Budapest); fiware-iot at lists.fi-ware.eu Cc: Lindsay Frost Subject: RE: IoT weekly meeting [Standardisatisation] Thierry, Lorant, Denes, [Unfortunately I will not be in the PhC] With respect to the agenda item (2). (a) All FIWare partners are requested to input a standardization plan !!! Please sent to Lindsay ASAP, deadlines are all missed and only 5 partners have responded yet... (b) All WPLs have to input a section according to the attached powerpoint. This was said by Juanjo in the meeting with WP5 /* That a section needed to be written was always clear, but the change in structure is now making it more clear */ As said, deadlines are all passed, so please speed up your contributions. Expect also a lot of reminder emails. @Thierry, Lorant There seems to be no list of Names/eMails for WPL and WPAs available. As you might know them by hart due to your frequent calls/meetings. Can you sent them to us. We asked Juanjo and Juan several times, but no answer... -Ern? From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Farkas, Lorant (NSN - HU/Budapest) Sent: Dienstag, 31. Januar 2012 12:43 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] IoT weekly meeting When: 2012. febru?r 1. 11:00-12:30 (GMT+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague. Where: telco/webex Note: The GMT offset above does not reflect daylight saving time adjustments. *~*~*~*~*~*~*~*~*~* Dear All, Please mind the new PIN code: 1628 For our next weekly meeting we are proposing the following topics: 1. The testbed topic: we have an Excel sheet to be filled, need to better understand what to achieve for the first release <> 2. Standardization topic: this is a deliverable for the end of this week <<[Fiware] Standardisation Plan - 5 out of 26 Partners have answered - can you add your input?>> 3. Architecture topic: should agree on the final version of the FMC diagram and agree on the next steps which means mainly editing in the wiki (deliverable is due 17th of February) We would also like to shift this instance from 10:00-11:30 to 11:00-12:30 at the request of our WPL, hopefully most of you can make it. Thanks & Br, Lorant Dear All, Let's resume our weekly meeting starting from next week in the usual day/time, which is Wednesday, 10:00 AM (CET) to 11:30. Either WPL or WPA will be present to host the meeting. In case we find good reason to skip the meeting, then we will skip it, but I propose not to deviate from this slot. Thanks & Br, Lorant Topic: IOT WP weekly Date: Every Wednesday, from Wednesday, 10 August 2011 to Wednesday, 26 March 2014 Time: 10:00, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 709 472 921 Meeting Password: FI-WARE ------------------------------------------------------- To join the online meeting ------------------------------------------------------- 1. Go to https://nsn.webex.com/nsn/j.php?ED=175018962&UID=0&PW=NYzEzYWM0ZTNk&RT=MTgjMjM%3D 2. Enter your name and email address. 3. Enter the meeting password: FI-WARE 4. Click "Join Now". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://nsn.webex.com/nsn/j.php?ED=175018962&UID=0&PW=NYzEzYWM0ZTNk&ORT=MTgjMjM%3D ------------------------------------------------------- NSN Voice Conference information Conference ID: 58465 New PIN: 1628 Making a conference call * from the office: 8071870 (in Finland and Germany) * from out of office: +358 7180 71870 (in Finland) and +49 89 5159 43800 (in Germany) All out-of-office conference access numbers are listed in page https://inside.nokiasiemensnetworks.com/global/MyServices/IT/Infrastructure_Services/RealTimeCommunication/VoiceService/NSNVoiceConference/MakingaCall/LocalAccessNumbers/Pages/Outofofficenumbers.aspx . Please check and prioritize them. If there is no access number for your country then please use access numbers of the area where to the calling costs are lowest. ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://nsn.webex.com/nsn/mc 2. On the left navigation bar, click "Support". You can contact me at: lorant.farkas at nsn.com Argentina - Buenos Aires +54 11 5983 9400 (PRIMARY) or +54 11 4814 9373 Argentina - Cordoba +54 35 1568 2208 Australia - Sydney +61 28 014 7189 (PRIMARY) or +61 29 429 9664 Australia - Melbourne +61 38 739 4333 Austria +43 72 088 0245 Bahrain +97 31 619 9028 Belgium - Generic +32 1448 0116 Belgium - Diegem-Machelen +32 2710 3300 Brazil - Belo Horizonte +55 31 3956 0546 Brazil - Brazil +55 61 3717 2043 Brazil - Curitiba +55 41 3906 0826 Brazil - Manaus +55 92 3652 7576 Brazil - Rio De Janeiro +55 21 3958 0804 (PRIMARY) or +55 21 3431 1999 Brazil - Salvador +55 71 3717 5351 Brazil - Sao Paolo +55 11 5508 0630 Bulgaria +359 2491 7085 Canada - Ajax +1 90 5619 4346 Canada - Burnaby +1 60 4456 5897 Canada - Hamilton +1 905 581 0212 Canada - Mississauga +1 289 360 3950 Canada - Montreal +1 51 4789 9125 Canada - Ottawa +1 61 3800 0568 Chile - Santiago +56 2350 6485 China - Mainland +86 10 8405 5000 ext 1870 China - Beijing +86 10 8405 5000 ext 1870 China - Chengdu +86 28 8689 0188 ext 1870 China - Dongguan +86 0769 2240 2844 ext 1870 China - Guangzhou +86 20 8755 6190 ext 1870 China - Hangzhou +86 571 8722 0877 ext 1870 China - Hong Kong +852 259 70220 ext 1870 China - Kunming +86 871 362 2880 ext 1870 China - Shanghai +86 21 6101 1870 ext 1870 China - ShenZhen +86 755 8613 3688 ext 1870 China - Suzhou +86 512 6761 6166 ext 1870 China - Zhengzhou +86 371 6566 9768 ext 1870 Colombia +57 1640 7979 ext 444 Croatia +38 51 777 6122 Czech Republic +42 02 460 19300 Denmark +45 699 18450 (PRIMARY) or +45 3329 2882 Egypt +97 31 619 9028 (Bahrain nbr) Estonia +37 266 67297 Finland +358 7180 71870 France +33 17 061 7813 (PRIMARY) or +33 14 915 1553 Germany +49 89 5159 43800 Greece +30 21 1176 8207 (PRIMARY) or +30 21 1120 3677 Hungary - Budapest +36 17 009 888 Hungary - Kom?rom +36 20 884 2499 India 000 800 100 7777 Indonesia - Jakarta (Menara Mulia/Plaza Kuningan +62 21 2557 9102 Indonesia - Bandung +62 22 8427 5992 Indonesia - Medan +62 61 3001 2702 Indonesia - Semarang +62 24 3300 0702 Ireland +353 1526 2862 Israel +97 29 775 1700 Italy - Milan +39 024 004 2007 Italy - Rome +39 069 481 6656 Japan +81 3 4578 0230 (PRIMARY) or +81 3 5474 7979 Kuwait +97 31 619 9028 (Bahrain nbr) Latvia +37 16 765 2510 Lithuania +37 0 5205 8994 Luxembourg +352 2088 0106 Malaysia +60 323 029 009 Mexico - Mexico City +52 55 3686 9759 (PRIMARY) or +52 55 5261 7245 Mexico - Reynosa +52 89 9909 1555 Netherlands +31 79 346 5225 New Zealand +64 9306 6933 Norway - Oslo +47 21 548 223 Oman +97 31 619 9028 (Bahrain nbr) Pakistan +92 512 092 444 Panama +507 832 7981 Peru +51 1708 5370 (PRIMARY) or +51 1215 7650 Philippines +63 2754 1700 Poland - Warsaw +48 22 398 8116 Poland - Wroclaw +48 71 718 1215 Portugal +351 21 044 4698 Qatar +97 31 619 9028 (Bahrain nbr) Romania +40 36 440 3799 Russia +74 95 725 2706 Saudi Arabia +97 31 619 9028 (Bahrain nbr) Singapore +65 3103 1065 (PRIMARY) or +65 6723 2582 Slovakia +42 12 3300 6924 Slovenia +38 61 600 2713 South Africa - Johannesburg +27 1 0500 2221 South Africa - Pretoria +27 1 2004 2334 South Korea - Masan +82 5 5290 7690 South Korea - Seoul +82 2 2186 5088 Spain +349 1187 5929 Sweden +46 85 250 0862 (PRIMARY), +46 84 100 9299 Switzerland +41 44 279 7943 Taiwan +88 62 8175 9298 Thailand +66 2762 6750 Turkey +90 216 570 2345 Ukraine +38 044 520 2272 UK +44 12 5275 8334 UK - Camberley +44 12 5286 5849 UK - Church Crookham +44 12 5261 1100 UK - Huntingdon +44 14 8087 8220 (PRIMARY), +44 14 8044 4206 UK - London +44 20 3318 1924 United Arab Emirates +97 31 619 9028 (Bahrain nbr) USA - Alpharetta +1 770 871 3050 USA - Arizona +1 480 588 3748 USA - Atlanta +1 404 236 4550 USA - Atlanta Notheast +1 678 317 3165 USA - Austin/Round Rock +1 512 600 2027 USA - Belleville +1 973 547 7982 USA - Boca Raton +1 561 910 2843 USA - Boston +1 617 963 8320 (PRIMARY) or +1 781 993 4850 USA - Burlington +1 781 993 4850 USA - Calabasas +1 818 914 0215 USA - Canoga Park +1 818 914 0215 USA - Cary +1 919 655 1388 USA - Chelmsford/Littleton +1 978 679 0233 USA - Chicago +1 773 303 4710 USA - Dallas +1 214 269 7626 USA - Dallas/Fort Worth +1 214 270 0352 USA - Greenville, NC +1 252 329 1677 USA - Herndon +1 703 483 4485 USA - Johnson City +1 423 952 1545 USA - Kirkland +1 425 242 3113 USA - Miami +1 786 388 4150 or +1 786 329 7177 USA - Naperville +1 630 596 2203 USA - New Brunswick +1 732 579 6483 USA - New Century, KS +1 913 254 5900 USA - New York White Plains +1 914 368 0650 USA - New York Peekskill, White Plains +1 914 293 1885 USA - Palo Alto +1 650 644 1349 USA - Redmond +1 425 242 3113 USA - San Diego +1 858 769 5309 or +1 619 330 9699 USA - Sunnyvale +1 408 419 1750 USA - Washington D.C +1 202 552 4781 Vietnam +84 4 3724 6110 Yemen +97 31 619 9028 (Bahrain nbr) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorant.farkas at nsn.com Wed Feb 1 09:47:06 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Wed, 1 Feb 2012 10:47:06 +0200 Subject: [Fiware-iot] FW: FW: IoT weekly meeting Message-ID: <93D28BDF64839C468B848D14227151A2030B4B9F@FIESEXC014.nsn-intra.net> Dear All, In the Excel sheet on the testbed there were columns called Q1...Q5. Stefano explains below what are these questions. If you have time please read these through before our meeting. Thanks & Br, Lorant -----Original Message----- From: ste.depanfilis at gmail.com [mailto:ste.depanfilis at gmail.com] On Behalf Of ext stefano de panfilis Sent: Wednesday, February 01, 2012 9:46 AM To: Farkas, Lorant (NSN - HU/Budapest) Cc: Bisztray, Denes (NSN - HU/Budapest); thierry.nagellen at orange.com Subject: Re: FW: [Fiware-iot] IoT weekly meeting dear lorant, here are the questions as copied from the wikimedia page of testbed wp. ======================= [QUESTION 1] Which are your HW and Deployment infrastructure requirements for your GEs? Can you HW be virtualised? If "no" why? What will you provide to the testbed? [edit] [QUESTION 2] What is the level of maturity (in terms of functionality offered) of your GE implementation for: testbed version 1 (M15)? testbed version 2 (M27)? testbed version 3 (M36) [edit] [QUESTION 3] Are there relationships with other GEs? What GEs do you plan to integrate with (inside/outside your FI-WARE Chapter)? For which testbed version do you plan the integration? Is your GEs dependent on the HW released by other FI-WARE Chapter? [edit] [QUESTION 4] Have you made a preliminary check about the need to execute your GEs in a private local infrastructure? If "yes" explain why (e.g. technical, legal) [edit] [QUESTION 5] Do you have already a link with a Use Case project? If "yes": how Use Case projects do expect to use your GE? are there specific HW/SW requirements? are there domain specific enablers developed by the Use Case you need to relate to? ============== ciao, stefano 2012/2/1 Farkas, Lorant (NSN - HU/Budapest) : > Dear Stefani, > > We don't know what are the questions. I guess these are in relationship with columns Q1...Q5 from your Excel sheet, right? > Could you send these questions over? > We don't have access to the Testbed project in Forge, we applied only this morning and we believe these questions are there in the mediawiki of your project, thus unaccessible to us (yet). > > Thanks & Br, > > Lorant > > -----Original Message----- > From: ste.depanfilis at gmail.com [mailto:ste.depanfilis at gmail.com] On Behalf Of ext stefano de panfilis > Sent: Tuesday, January 31, 2012 2:00 PM > To: Farkas, Lorant (NSN - HU/Budapest) > Cc: Bisztray, Denes (NSN - HU/Budapest); thierry.nagellen at orange.com > Subject: Re: FW: [Fiware-iot] IoT weekly meeting > > dear lorant, > > delighted to be invited at you weekly phc to progrees with the common work. > > in order to have the work more efficient can the other colleagues of > iot read the questions and familiarise with them? > > ciao, > stefano > > 2012/1/31 Farkas, Lorant (NSN - HU/Budapest) : >> Dear Stefano, >> >> >> >> Would you be available tomorrow at 11:00 for a discussion on the >> testbed-related Excel sheet? We have a work package internal weekly meeting >> and would like to better understand what we have to do by the end of the >> week. >> >> >> >> Thanks & Br, >> >> >> >> Lorant >> >> >> >> From: fiware-iot-bounces at lists.fi-ware.eu >> [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Farkas, Lorant >> (NSN - HU/Budapest) >> Sent: Tuesday, January 31, 2012 12:43 PM >> To: fiware-iot at lists.fi-ware.eu >> Subject: [Fiware-iot] IoT weekly meeting >> >> >> >> When: 2012. febru?r 1. 11:00-12:30 (GMT+01:00) Belgrade, Bratislava, >> Budapest, Ljubljana, Prague. >> >> Where: telco/webex >> >> Note: The GMT offset above does not reflect daylight saving time >> adjustments. >> >> *~*~*~*~*~*~*~*~*~* >> >> Dear All, >> >> Please mind the new PIN code: 1628 >> >> For our next weekly meeting we are proposing the following topics: >> >> 1.????? The testbed topic: we have an Excel sheet to be filled, need to >> better understand what to achieve for the first release >> >> <> >> >> 2.????? Standardization topic: this is a deliverable for the end of this >> week >> >> <<[Fiware] Standardisation Plan - 5 out of 26 Partners have answered - can >> you add your input?>> >> >> 3.????? Architecture topic: should agree on the final version of the FMC >> diagram and agree on the next steps which means mainly editing in the wiki >> (deliverable is due 17th of February) >> >> We would also like to shift this instance from 10:00-11:30 to 11:00-12:30 at >> the request of our WPL, hopefully most of you can make it. >> >> Thanks & Br, >> >> Lorant >> >> Dear All, >> >> Let's resume our weekly meeting starting from next week in the usual >> day/time, which is Wednesday, 10:00 AM (CET) to 11:30. >> >> Either WPL or WPA will be present to host the meeting. >> >> In case we find good reason to skip the meeting, then we will skip it, but I >> propose not to deviate from this slot. >> >> Thanks & Br, >> >> Lorant >> >> Topic: IOT WP weekly >> >> Date: Every Wednesday, from Wednesday, 10 August 2011 to Wednesday, 26 March >> 2014 Time: 10:00, Europe Summer Time (Paris, GMT+02:00) >> >> Meeting Number: 709 472 921 >> >> Meeting Password: FI-WARE >> >> ------------------------------------------------------- >> >> To join the online meeting >> >> ------------------------------------------------------- >> >> 1.????? Go to >> https://nsn.webex.com/nsn/j.php?ED=175018962&UID=0&PW=NYzEzYWM0ZTNk&RT=MTgjMjM%3D >> >> 2.????? Enter your name and email address. >> >> 3.????? Enter the meeting password: FI-WARE >> >> 4.????? Click "Join Now". >> >> 5.????? Follow the instructions that appear on your screen. >> >> To view in other time zones or languages, please click the link: >> >> https://nsn.webex.com/nsn/j.php?ED=175018962&UID=0&PW=NYzEzYWM0ZTNk&ORT=MTgjMjM%3D >> >> ------------------------------------------------------- >> >> NSN Voice Conference information >> >> Conference ID: 58465 >> >> New PIN: 1628 >> >> Making a conference call >> >> from the office: 8071870 (in Finland and Germany) >> >> from out of office: +358 7180 71870 (in Finland) and +49 89 5159 43800 (in >> Germany) >> >> All out-of-office conference access numbers are listed in page >> https://inside.nokiasiemensnetworks.com/global/MyServices/IT/Infrastructure_Services/RealTimeCommunication/VoiceService/NSNVoiceConference/MakingaCall/LocalAccessNumbers/Pages/Outofofficenumbers.aspx. >> >> Please check and prioritize them. If there is no access number for your >> country then please use access numbers of the area where to the calling >> costs are lowest. >> >> ------------------------------------------------------- >> >> For assistance >> >> ------------------------------------------------------- >> >> 1.????? Go to https://nsn.webex.com/nsn/mc >> >> 2.????? On the left navigation bar, click "Support". >> >> You can contact me at: >> >> lorant.farkas at nsn.com >> >> Argentina - Buenos Aires??????? +54 11 5983 9400 (PRIMARY) or +54 11 4814 >> 9373 >> >> Argentina - Cordoba???? +54 35 1568 2208 >> >> Australia - Sydney????? +61 28 014 7189 (PRIMARY) or +61 29 429 9664 >> >> Australia - Melbourne?? +61 38 739 4333 >> >> Austria +43 72 088 0245 >> >> Bahrain +97 31 619 9028 >> >> Belgium - Generic?????? +32 1448 0116 >> >> Belgium - Diegem-Machelen?????? +32 2710 3300 >> >> Brazil - Belo Horizonte +55 31 3956 0546 >> >> Brazil - Brazil +55 61 3717 2043 >> >> Brazil - Curitiba?????? +55 41 3906 0826 >> >> Brazil - Manaus +55 92 3652 7576 >> >> Brazil - Rio De Janeiro +55 21 3958 0804 (PRIMARY) or +55 21 3431 1999 >> >> Brazil - Salvador?????? +55 71 3717 5351 >> >> Brazil - Sao Paolo????? +55 11 5508 0630 >> >> Bulgaria??????? +359 2491 7085 >> >> Canada - Ajax?? +1 90 5619 4346 >> >> Canada - Burnaby??????? +1 60 4456 5897 >> >> Canada - Hamilton?????? +1 905 581 0212 >> >> Canada - Mississauga??? +1 289 360 3950 >> >> Canada - Montreal?????? +1 51 4789 9125 >> >> Canada - Ottawa +1 61 3800 0568 >> >> Chile - Santiago??????? +56 2350 6485 >> >> China - Mainland??????? +86 10 8405 5000 ext 1870 >> >> China - Beijing +86 10 8405 5000 ext 1870 >> >> China - Chengdu +86 28 8689 0188 ext 1870 >> >> China - Dongguan??????? +86 0769 2240 2844 ext 1870 >> >> China - Guangzhou?????? +86 20 8755 6190 ext 1870 >> >> China - Hangzhou??????? +86 571 8722 0877 ext 1870 >> >> China - Hong Kong?????? +852 259 70220 ext 1870 >> >> China - Kunming +86 871 362 2880 ext 1870 >> >> China - Shanghai??????? +86 21 6101 1870 ext 1870 >> >> China - ShenZhen??????? +86 755 8613 3688 ext 1870 >> >> China - Suzhou? +86 512 6761 6166 ext 1870 >> >> China - Zhengzhou?????? +86 371 6566 9768 ext 1870 >> >> Colombia??????? +57 1640 7979 ext 444 >> >> Croatia +38 51 777 6122 >> >> Czech Republic? +42 02 460 19300 >> >> Denmark +45 699 18450 (PRIMARY) or +45 3329 2882 >> >> Egypt?? +97 31 619 9028 (Bahrain nbr) >> >> Estonia +37 266 67297 >> >> Finland +358 7180 71870 >> >> France? +33 17 061 7813 (PRIMARY) or +33 14 915 1553 >> >> Germany +49 89 5159 43800 >> >> Greece? +30 21 1176 8207 (PRIMARY) or +30 21 1120 3677 >> >> Hungary - Budapest????? +36 17 009 888 >> >> Hungary - Kom?rom?????? +36 20 884 2499 >> >> India?? 000 800 100 7777 >> >> Indonesia - Jakarta (Menara Mulia/Plaza Kuningan??????? +62 21 2557 >> 9102 >> >> Indonesia - Bandung???? +62 22 8427 5992 >> >> Indonesia - Medan?????? +62 61 3001 2702 >> >> Indonesia - Semarang??? +62 24 3300 0702 >> >> Ireland +353 1526 2862 >> >> Israel? +97 29 775 1700 >> >> Italy - Milan?? +39 024 004 2007 >> >> Italy - Rome??? +39 069 481 6656 >> >> Japan?? +81 3 4578 0230 (PRIMARY) or +81 3 5474 7979 >> >> Kuwait? +97 31 619 9028 (Bahrain nbr) >> >> Latvia? +37 16 765 2510 >> >> Lithuania?????? +37 0 5205 8994 >> >> Luxembourg????? +352 2088 0106 >> >> Malaysia??????? +60 323 029 009 >> >> Mexico - Mexico City??? +52 55 3686 9759 (PRIMARY) or +52 55 5261 7245 >> >> Mexico - Reynosa??????? +52 89 9909 1555 >> >> Netherlands???? +31 79 346 5225 >> >> New Zealand???? +64 9306 6933 >> >> Norway - Oslo?? +47 21 548 223 >> >> Oman??? +97 31 619 9028 (Bahrain nbr) >> >> Pakistan??????? +92 512 092 444 >> >> Panama? +507 832 7981 >> >> Peru??? +51 1708 5370 (PRIMARY) or +51 1215 7650 >> >> Philippines???? +63 2754 1700 >> >> Poland - Warsaw +48 22 398 8116 >> >> Poland - Wroclaw??????? +48 71 718 1215 >> >> Portugal??????? +351 21 044 4698 >> >> Qatar?? +97 31 619 9028 (Bahrain nbr) >> >> Romania +40 36 440 3799 >> >> Russia? +74 95 725 2706 >> >> Saudi Arabia??? +97 31 619 9028 (Bahrain nbr) >> >> Singapore?????? +65 3103 1065 (PRIMARY) or +65 6723 2582 >> >> Slovakia??????? +42 12 3300 6924 >> >> Slovenia??????? +38 61 600 2713 >> >> South Africa - Johannesburg???? +27 1 0500 2221 >> >> South Africa - Pretoria +27 1 2004 2334 >> >> South Korea - Masan???? +82 5 5290 7690 >> >> South Korea - Seoul???? +82 2 2186 5088 >> >> Spain?? +349 1187 5929 >> >> Sweden? +46 85 250 0862 (PRIMARY), +46 84 100 9299 >> >> Switzerland???? +41 44 279 7943 >> >> Taiwan? +88 62 8175 9298 >> >> Thailand??????? +66 2762 6750 >> >> Turkey? +90 216 570 2345 >> >> Ukraine +38 044 520 2272 >> >> UK????? +44 12 5275 8334 >> >> UK - Camberley? +44 12 5286 5849 >> >> UK - Church Crookham??? +44 12 5261 1100 >> >> UK - Huntingdon +44 14 8087 8220 (PRIMARY), +44 14 8044 4206 >> >> UK - London???? +44 20 3318 1924 >> >> United Arab Emirates??? +97 31 619 9028 (Bahrain nbr) >> >> USA - Alpharetta??????? +1 770 871 3050 >> >> USA - Arizona?? +1 480 588 3748 >> >> USA - Atlanta?? +1 404 236 4550 >> >> USA - Atlanta Notheast? +1 678 317 3165 >> >> USA - Austin/Round Rock +1 512 600 2027 >> >> USA - Belleville??????? +1 973 547 7982 >> >> USA - Boca Raton??????? +1 561 910 2843 >> >> USA - Boston??? +1 617 963 8320 (PRIMARY) or +1 781 993 4850 >> >> USA - Burlington??????? +1 781 993 4850 >> >> USA - Calabasas +1 818 914 0215 >> >> USA - Canoga Park?????? +1 818 914 0215 >> >> USA - Cary????? +1 919 655 1388 >> >> USA - Chelmsford/Littleton????? +1 978 679 0233 >> >> USA - Chicago?? +1 773 303 4710 >> >> USA - Dallas??? +1 214 269 7626 >> >> USA - Dallas/Fort Worth +1 214 270 0352 >> >> USA - Greenville, NC??? +1 252 329 1677 >> >> USA - Herndon?? +1 703 483 4485 >> >> USA - Johnson City????? +1 423 952 1545 >> >> USA - Kirkland? +1 425 242 3113 >> >> USA - Miami???? +1 786 388 4150 or +1 786 329 7177 >> >> USA - Naperville??????? +1 630 596 2203 >> >> USA - New Brunswick???? +1 732 579 6483 >> >> USA - New Century, KS?? +1 913 254 5900 >> >> USA - New York White Plains???? +1 914 368 0650 >> >> USA - New York Peekskill, White Plains? +1 914 293 1885 >> >> USA - Palo Alto +1 650 644 1349 >> >> USA - Redmond?? +1 425 242 3113 >> >> USA - San Diego +1 858 769 5309 or +1 619 330 9699 >> >> USA - Sunnyvale +1 408 419 1750 >> >> USA - Washington D.C??? +1 202 552 4781 >> >> Vietnam +84 4 3724 6110 >> >> Yemen?? +97 31 619 9028 (Bahrain nbr) >> >> >> >> ---------- Messaggio inoltrato ---------- >> From:?"ext Lindsay Frost" >> To:? >> Cc:?"Lindsay Frost" , "Ernoe Kovacs" >> >> Date:?Wed, 25 Jan 2012 17:56:15 +0200 >> Subject:?[Fiware] Standardisation Plan - 5 out of 26 Partners have answered >> - can you add your input? >> >> Dear all, >> >> many of you may not have received requests to contribute to the >> FI-Ware standardization plan, although a template and updates >> have been sent to work-package leaders. Attached is the accumulated >> "input" so far (5 out of 26), without any editing or re-organizing >> into a readable document or workplan. Please provide your input too! >> >> The workplan is due to be delivered to the EC on my birthday, 31st January, >> but I think it will be a sad birthday present with only 5 inputs so far! >> >> I hope that this "broadcast to all" will allow many of you to quickly >> get a consensus in your companies to provide the needed status information. >> >> Everything arriving by Monday 30th January 10:00 am I will include >> in the draft document I will send to you all on Monday night. >> Tuesday 31st is the last chance to correct all the thousand errors, >> or at least any major ones you find. Then the document gets delivered. >> >> If project leaders can show that a more delayed schedule is possible, I am >> of course happy for that (perhaps I misinterpret the deliverables >> schedule?). >> But that is the situation as I understand it. >> >> Best regards >> Lindsay Frost >> >> _____________________________________________ >> Dr. Lindsay Frost, Chief Standardization Eng. >> NEC Laboratories Europe, Heidelberg, Germany. >> NEC Europe Ltd, Reg. England, VAT DE161569151 >> frost at neclab.eu?????? Mobile +49.163.275.1734 >> >> >> >> >> >> >> _______________________________________________ >> Fiware-iot mailing list >> Fiware-iot at lists.fi-ware.eu >> http://lists.fi-ware.eu/listinfo/fiware-iot >> > > > > -- > Stefano De Panfilis > Chief Innovation Officer > Engineering Ingegneria Informatica S.p.A. > via Riccardo Morandi 32 > 00148 Roma > Italy > > tel (direct): +39-068307-4295 > tel (secr.): +39-068307-4513 > fax: +39-068307-4200 > cell: +39-335-7542-567 > -- Stefano De Panfilis Chief Innovation Officer Engineering Ingegneria Informatica S.p.A. via Riccardo Morandi 32 00148 Roma Italy tel (direct): +39-068307-4295 tel (secr.): +39-068307-4513 fax: +39-068307-4200 cell: +39-335-7542-567 From gianpiero.fici at telecomitalia.it Wed Feb 1 11:56:04 2012 From: gianpiero.fici at telecomitalia.it (Fici Gian Piero) Date: Wed, 1 Feb 2012 11:56:04 +0100 Subject: [Fiware-iot] I: Filling in the Standardisation Plan (due Friday 13th January) In-Reply-To: <58967817BA9AEA4E92A38F89CE2EA93224C1A982@PALLENE.office.hd> References: <3F4C11BC54A36642BFB5875D599F47BD0573DDD3@DEMUEXC013.nsn-intra.net> <58967817BA9AEA4E92A38F89CE2EA93224C18A5D@PALLENE.office.hd> <3F4C11BC54A36642BFB5875D599F47BD057B9C49@DEMUEXC013.nsn-intra.net> <58967817BA9AEA4E92A38F89CE2EA93224C1A982@PALLENE.office.hd> Message-ID: Da: Lindsay Frost [mailto:Lindsay.Frost at neclab.eu] Inviato: mercoled? 1 febbraio 2012 11:26 A: Fici Gian Piero Cc: Guerra Sabrina; Bisztray, Denes (NSN - HU/Budapest) Oggetto: RE: [Fiware-iot] Filling in the Standardisation Plan (due Friday 13th January) Dear Gian, dear all, thanks for the confirmation. I had assumed something like that ... Meanwhile this gives me an excuse to send you the resulting XLS which I created. Can you take a look and see if you find it understandable? sheet1 is an intro with links sheet 2 is a general list of SDO information and where FI-Ware partners are already active in relevant spots sheet 3 is where Partners say they should/will do standardization (lots of holes!) sheet 4 is intended as a calendar and to-do-list but is currently just a placeholder. I would be grateful for any quick feedback before I "send to all". Of course any errors re Telecom Italia should be pointed out (sorry in advance) thanks (I hope) Lindsay From: Fici Gian Piero [mailto:gianpiero.fici at telecomitalia.it] Sent: Mittwoch, 1. Februar 2012 11:08 To: Lindsay Frost Cc: Guerra Sabrina; Bisztray, Denes (NSN - HU/Budapest) Subject: R: [Fiware-iot] Filling in the Standardisation Plan (due Friday 13th January) Hi Lindsay, the contribution you got is the Telecom Italia one (the first part saying "Partner Organisation: NEC" is just the example we used as a template). We already sent the contribution for the Standardisation Plan through Pier Garino (Telecom Italia, WPL I2ND), but then it looks like these contributions were asked to each WP so we passed the contribution to D?nes who forwarded it to you. The two contributions are the same. Sorry if we confused you. :) For any clarification please feel free to ask me or Sabrina Guerra. Best regards, Gian Piero Fici Da: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com] Inviato: marted? 31 gennaio 2012 15:09 A: ext Lindsay Frost; Guerra Sabrina Cc: Fici Gian Piero Oggetto: RE: [Fiware-iot] Filling in the Standardisation Plan (due Friday 13th January) I believe this is Telecom Italia. Best, D?nes From: ext Lindsay Frost [mailto:Lindsay.Frost at neclab.eu] Sent: Tuesday, January 31, 2012 1:53 PM To: Bisztray, Denes (NSN - HU/Budapest); ext Guerra Sabrina Cc: ext Fici Gian Piero Subject: RE: [Fiware-iot] Filling in the Standardisation Plan (due Friday 13th January) Importance: High Dear D?nes, dear Sabrina, which company or companies should I list as contributing in the document you sent ? Telecom Italia and NSN both send separate input, earlier. thanks Lindsay From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com] Sent: Mittwoch, 25. Januar 2012 12:02 To: Lindsay Frost Cc: ext Guerra Sabrina; ext Fici Gian Piero Subject: FW: [Fiware-iot] Filling in the Standardisation Plan (due Friday 13th January) Hi Lindsay, I believe you are responsible for the Standardisation Plan docs. Can you have a look at this one? Best, D?nes From: ext Guerra Sabrina [mailto:sabrina.guerra at telecomitalia.it] Sent: Wednesday, January 25, 2012 11:56 AM To: Bisztray, Denes (NSN - HU/Budapest); ext Jan H?ller Cc: fiware-iot at lists.fi-ware.eu; Fici Gian Piero Subject: RE: [Fiware-iot] Filling in the Standardisation Plan (due Friday 13th January) Hi Denes, we send you the document updated with our contributions. These contributions are related to WP5 and WP11. Let me know if it is ok or you need any other information. Best regards, Sabrina ________________________________ From: fiware-iot-bounces at lists.fi-ware.eu [fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Bisztray, Denes (NSN - HU/Budapest) [denes.bisztray at nsn.com] Sent: Tuesday, January 24, 2012 9:29 AM To: ext Jan H?ller Cc: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] FW: [FI-Ware] Filling in the Standardisation Plan (due Friday 13th January) From: ext Lindsay Frost [mailto:Lindsay.Frost at neclab.eu] Sent: Thursday, January 05, 2012 3:40 PM To: fiware-pcc at lists.fi-ware.eu; fiware-wpl at lists.fi-ware.eu; JOSE JIMENEZ DELGADO; Nuria De-Lama Sanchez; Carmen Perea Escribano; GLIKSON at il.ibm.com; andreas.friesen at sap.com; axel.fasse at sap.com; Burkhard.Neidecker-Lutz at sap.com; ralli at tid.es; Bisztray, Denes (NSN - HU/Budapest); jdps at tid.es; jimenez at tid.es; jhierro at tid.es; Farkas, Lorant (NSN - HU/Budapest); matteo.melideo at eng.it; mcp at tid.es; nuria.delama at atosresearch.eu; Olivier.Festor at inria.fr; pascal.bisson at thalesgroup.com; pierangelo.garino at telecomitalia.it; stefano.depanfilis at eng.it; thierry.nagellen at orange-ftgroup.com; thomas.bohnert at zhaw.ch; torsten.leidig at sap.com Cc: Ernoe Kovacs; Juan Bare?o Guerenabarrena Subject: [FI-Ware] Filling in the Standardisation Plan (due Friday 13th January) Importance: High Dear colleagues in FI-Ware, welcome into 2012 A.D. ! Another year, another set of deadlines ... In the last email of Juan Bare?o Guerenabarrena from 2011, there was a request to provide information for the FI-Ware standardization plan. I am tasked with filling in the relevant deliverable by the end of January - about 3 weeks from now. So far there is nearly nothing new to say, compared to the broad remarks given one year ago in applying for the project. I am sure this is not the impression you want to give to the EC about your organization... To make contributing a bit easier, I drafted the attached SHORT input formula. Could you please make sure your organization fills in Page 2 and returns it to me by Friday 13th January ? Thank you Lindsay Frost PS: if you are not the proper contact in your organization for this topic, please send me the correct email address and I will bother them instead ;-) _____________________________________________ Dr. Lindsay Frost, Chief Standardization Eng. NEC Laboratories Europe, Heidelberg, Germany. NEC Europe Ltd, Reg. England, VAT DE161569151 frost at neclab.eu Mobile +49.163.275.1734 __________________________________ From: Juan Bare?o Guerenabarrena [mailto:juan.bareno at atosresearch.eu] Sent: Freitag, 23. Dezember 2011 13:43 To: fiware-pcc at lists.fi-ware.eu; fiware-wpl at lists.fi-ware.eu Cc: JOSE JIMENEZ DELGADO; Nuria De-Lama Sanchez; Carmen Perea Escribano; Lindsay Frost; Ernoe Kovacs Subject: WP11-Explotation Summary and Next Steps Dear Colleagues Please find here enclosed a initial presentation of what business issues regarding FI WARE have to be discussed to agree on a common message about FI WARE market positioning and the IPRs and Standardization activities management Additionally you can find the templates to fulfill aiming to obtain the exploitation and standardization issues feedback from each partner: - Exploitation: o Individual exploitation plan- by partner (Form 1) o Domain exploitation plan- by WPL (Form 2) - Standardization o Standardization Report- by WPL o Excel with main contacts- by partner Please review the presentation and send feedback and fulfill the templates accordingly I take advantage of this email to wish you all a very nice Christmas and a Happy New Year Br Juan Next week we will circulate a first commercial draft brochure Juan Bare?o Global Innovation, Business Development & Strategy Research & Innovation T +34 912148859 juan.bareno at atos.net Albarrac?n 25 28037 Madrid Spain www.atos.net www.atosresearch.eu ------------------------------------------------------------------ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. Este mensaje y los ficheros adjuntos pueden contener informacion confidencial destinada solamente a la(s) persona(s) mencionadas anteriormente pueden estar protegidos por secreto profesional. Si usted recibe este correo electronico por error, gracias por informar inmediatamente al remitente y destruir el mensaje. Al no estar asegurada la integridad de este mensaje sobre la red, Atos no se hace responsable por su contenido. Su contenido no constituye ningun compromiso para el grupo Atos, salvo ratificacion escrita por ambas partes. Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor no puede garantizar nada al respecto y no sera responsable de cualesquiera danos que puedan resultar de una transmision de virus. ------------------------------------------------------------------ Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:image001.gif at 01CCE0D4.50078360]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:image001.gif at 01CCE0D4.50078360]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:00000000000000000000000000000001 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 677 bytes Desc: image001.gif URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FI-Ware_Standardization_List_20120201_CONFIDENTIAL.xlsx Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet Size: 80995 bytes Desc: FI-Ware_Standardization_List_20120201_CONFIDENTIAL.xlsx URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia.jpg URL: From lorant.farkas at nsn.com Wed Feb 1 14:02:28 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Wed, 1 Feb 2012 15:02:28 +0200 Subject: [Fiware-iot] IoT weekly meeting minutes Message-ID: <93D28BDF64839C468B848D14227151A2030B4E6C@FIESEXC014.nsn-intra.net> Dear All, Please find the minutes under the following link: https://forge.fi-ware.eu/docman/view.php/11/771/IoT-Minutes-Telco-010220 12.docx I attach also in doc format for Stefano. <> Thanks & Br, Lorant -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IoT-Minutes-Telco-01022012.docx Type: application/octet-stream Size: 188499 bytes Desc: IoT-Minutes-Telco-01022012.docx URL: From lorant.farkas at nsn.com Fri Feb 3 10:42:41 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Fri, 3 Feb 2012 11:42:41 +0200 Subject: [Fiware-iot] testbed, standardization, arch specs Message-ID: <93D28BDF64839C468B848D14227151A2030B5912@FIESEXC014.nsn-intra.net> Dear Partners, I would like to remind you about the following: 1. The testbed topic: please provide by today or latest by Monday the testbed requirements for your assets based on the 5 questions from Stefano, the link where you can fill the data is https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/FI-WAR E_Testbed_Fact_Finding_Investigation. If you don't have access to it, please apply for it in forge in the Testbed project, or alternatively fill it in the Excel sheet rather than in the Wiki and provide the filled Excel to Stefano. 2. The standardization topic: those of you who have not done yet please provide input to Lindsay Frost/NEC by filling either the word template <> or directly by editing the Excel sheet <> The due date for this activity was 3 days ago. 3. Please find new information on the format of the architecture specifications, of which the due date is 17th of February. If you addressed points 1 and 2, please (especially task leaders) concentrate on this task. <> Thanks & Br, Lorant -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FI-Ware_Input_for_Standardisation_Plan_6AnswersFrom20_20120201.docx Type: application/octet-stream Size: 270366 bytes Desc: FI-Ware_Input_for_Standardisation_Plan_6AnswersFrom20_20120201.docx URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FI-Ware_Standardization_List_20120201_CONFIDENTIAL.XLSX Type: application/octet-stream Size: 81336 bytes Desc: FI-Ware_Standardization_List_20120201_CONFIDENTIAL.XLSX URL: -------------- next part -------------- An embedded message was scrubbed... From: "ext Juanjo Hierro" Subject: Re: [Fiware-wpa] Guidelines section for Architecture Description deliverable available on the Wiki Date: Fri, 3 Feb 2012 09:24:04 +0200 Size: 27814 URL: From lorant.farkas at nsn.com Mon Feb 6 10:08:20 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Mon, 6 Feb 2012 11:08:20 +0200 Subject: [Fiware-iot] [Fiware-support] FW: testbed, standardization, arch specs In-Reply-To: <4F2F97BC.8070609@tid.es> References: <93D28BDF64839C468B848D14227151A203134C10@FIESEXC014.nsn-intra.net> <4F2F97BC.8070609@tid.es> Message-ID: <93D28BDF64839C468B848D14227151A203134E97@FIESEXC014.nsn-intra.net> Dear Miguer, Thanks, we were not aware that there is a support tracker, but now we are! IoT team, FYI. Br, Lorant From: ext Miguel Carrillo [mailto:mcp at tid.es] Sent: Monday, February 06, 2012 10:05 AM To: Farkas, Lorant (NSN - HU/Budapest); fiware-support at lists.fi-ware.eu; ext Guerra Sabrina Subject: Re: [Fiware-support] FW: testbed, standardization, arch specs Dear Lorant, This is a widely know (and suffered!) bug. It was noticed in the attached email months ago. It is a real pain and we are pushing the admin team to solve it. There is already a bug on the support tracker (ticket 1187 ) with all the details. We would appreciate it if you could use the support tracker to report this sort of stuff (better than the support mailing list). Thanks Miguel El 03/02/2012 16:59, Farkas, Lorant (NSN - HU/Budapest) escribi?: Dear Support Team, Can you help Sabrina with this issue? Thanks & Br, Lorant From: ext Guerra Sabrina [mailto:sabrina.guerra at telecomitalia.it] Sent: Friday, February 03, 2012 4:55 PM To: Farkas, Lorant (NSN - HU/Budapest) Subject: R: testbed, standardization, arch specs Hi Lorant, I have some problems to access Tracker on Forge. I login as user 'sabrina', then click on the Projects List and then on FI-WARE Iot. Now I try to access the Tracker and then click on Backlog Management and at this point the following error is shown: Error Database Error: ERROR: syntax error at or near "assigned_to" LINE 1: ... AND aefd0.artifact_id=artifact_vw.artifact_idAND assigned_t... ^ When I login as user 'gianpiero' and I repeat these operations, I have no problems. Thank you in advance for your help Best regards, Sabrina Guerra __________________________________ Telecom Italia S.p.a. Strategia e Innovazione, Research & Trends Telefono +39 011 228 8359 Cellulare +39 331 600 1349 ________________________________ Da: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] Per conto di Farkas, Lorant (NSN - HU/Budapest) Inviato: Friday, February 03, 2012 10:43 AM A: fiware-iot at lists.fi-ware.eu Oggetto: [Fiware-iot] testbed, standardization, arch specs Dear Partners, I would like to remind you about the following: 1. The testbed topic: please provide by today or latest by Monday the testbed requirements for your assets based on the 5 questions from Stefano, the link where you can fill the data is https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/FI-WARE_Testbed_Fact_Finding_Investigation . If you don't have access to it, please apply for it in forge in the Testbed project, or alternatively fill it in the Excel sheet rather than in the Wiki and provide the filled Excel to Stefano. 2. The standardization topic: those of you who have not done yet please provide input to Lindsay Frost/NEC by filling either the word template <> or directly by editing the Excel sheet <> The due date for this activity was 3 days ago. 3. Please find new information on the format of the architecture specifications, of which the due date is 17th of February. If you addressed points 1 and 2, please (especially task leaders) concentrate on this task. <> Thanks & Br, Lorant Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -- ---------------------------------------------------------------------- _/ _/_/ Miguel Carrillo Pacheco _/ _/ _/ _/ Telef?nica Distrito Telef?nica _/ _/_/_/ _/ _/ Investigaci?n y Edifico Oeste 1, Planta 9 _/ _/ _/ _/ Desarrollo Ronda de la Comunicaci?n S/N _/ _/_/ 28050 Madrid (Spain) Tel: (+34) 91 483 26 77 e-mail: mcp at tid.es Follow FI-WARE on the net Website: http://www.fi-ware.eu Facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 Twitter: http://twitter.com/Fiware LinkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ---------------------------------------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 677 bytes Desc: image001.gif URL: From lorant.farkas at nsn.com Mon Feb 6 10:54:00 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Mon, 6 Feb 2012 11:54:00 +0200 Subject: [Fiware-iot] IoT meeting minutes Message-ID: <93D28BDF64839C468B848D14227151A203134F33@FIESEXC014.nsn-intra.net> Dear All, Please find under this link the minutes of our bi-weekly WP sync. https://forge.fi-ware.eu/docman/view.php/11/782/IoT-coordinator-sync-Min utes-Telco-06022012.docx Dear IoT team, we created some action items to some of you, if there are unclarities please ask. Thanks & Br, Lorant -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorant.farkas at nsn.com Mon Feb 6 10:57:51 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Mon, 6 Feb 2012 11:57:51 +0200 Subject: [Fiware-iot] FW: Joint Cloud Hosting-i2nd meeting in Madrid Message-ID: <93D28BDF64839C468B848D14227151A203134F39@FIESEXC014.nsn-intra.net> Dear IoT team, Please check the minutes from Pier and make additions/changes in case. Please indicate who was there from IoT side (D?nes, Thierry for sure, but maybe also other IoT team members). Thanks & Br, Lorant From: ext Garino Pierangelo [mailto:pierangelo.garino at telecomitalia.it] Sent: Monday, February 06, 2012 10:50 AM To: thierry.nagellen at orange-ftgroup.com; Farkas, Lorant (NSN - HU/Budapest) Cc: Hans Einsiedler (Hans.Einsiedler at telekom.de) Subject: I: Joint Cloud Hosting-i2nd meeting in Madrid Dear Thierry and Lorant, At the Madrid meeting we had a joint session between IoT and I2ND chapters, during which I wrote a short summary of the discussions, you can find it at the following link: https://docs.google.com/document/d/1EnpG_itze4lEjw1Kqe9kQ6Adi6gSW8QX3elBI74zjtk/edit Could you please check that it's ok for you (list of IoT attendants should be added), and make possible modifications if something is erroneously reported, so that we can later upload the minutes on the project Forge site? Many thanks and Best Regards Pier ------------------------------------------------------------------ Telecom Italia Pierangelo Garino Innovation & Industry Relations - Research & Prototyping Via G. Reiss Romoli 274, I-10148 TORINO Tel: +39 011 228 7142 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia.jpg URL: From lorant.farkas at nsn.com Mon Feb 6 15:38:40 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Mon, 6 Feb 2012 16:38:40 +0200 Subject: [Fiware-iot] some missing info for testebed In-Reply-To: References: Message-ID: <93D28BDF64839C468B848D14227151A203135271@FIESEXC014.nsn-intra.net> Hi Thierry, 1. My suggestion for process automation would be that we don't have it for testbed release 1, we will specify in more detail after M15 2. Resources management is missing (IDAS), Telecom Italia contribution: Gian Piero/Sabrina, would it be possible that you please take it from the minutes and put it to the Wiki? I remember you elaborated on it quite in detail and I captured most of it in the minutes (https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/FI-WARE_Testbed_Fact_Finding_Investigation) 3. NEC contrib is missing. Thanks & Br, Lorant -----Original Message----- From: ext thierry.nagellen at orange.com [mailto:thierry.nagellen at orange.com] Sent: Monday, February 06, 2012 3:29 PM To: Farkas, Lorant (NSN - HU/Budapest); Bisztray, Denes (NSN - HU/Budapest); rheras at tid.es Subject: TR: some missing info for testebed Hi all, Please could you check what is missing for your tasks? I think that for Process Automation this is the NEC contribution. Any other missing contribution? BR Thierry -----Message d'origine----- De?: ste.depanfilis at gmail.com [mailto:ste.depanfilis at gmail.com] De la part de stefano de panfilis Envoy??: lundi 6 f?vrier 2012 14:43 ??: Riss, Uwe; MIGUEL CARRILLO PACHECO; Garino Pierangelo; NAGELLEN Thierry RD-BIZZ-SOP; NAGELLEN Thierry RD-BIZZ-SOP; Pascal Bisson; Matteo Antonio Melideo Cc?: fiware-testbed at lists.fi-ware.eu Objet?: some missing info for testebed dear uwe, miguel (on behalf of carlos), thierry, pier, pascal and matteo there are still some info missing from your chapters as per current status of https://forge.fi-ware.eu/plugins/mediawiki/wiki/testbed/index.php/FI-WARE_Testbed_Fact_Finding_Investigation summarising they are: WP3: - Composition Execution from DT - Store from Ericsson WP5: - IoT Process Automation - IoT Resources Management WP6: - confirm that the ges without company they do not exist WP7: - Service, Capability, Connectivity, and Control (S3C) WP8: - Identity Management from NSN - Privacy from Thales (only missing answer to q2) - Privacy from IBM WP9: - TraceAnalyzer from IBM can you help on the matter? i kindly also colleagues from the wp10 to help as well. for all deadline today. ciao, stefano Stefano De Panfilis Chief Innovation Officer Engineering Ingegneria Informatica S.p.A. via Riccardo Morandi 32 00148 Roma Italy tel (direct): +39-068307-4295 tel (secr.): +39-068307-4513 fax: +39-068307-4200 cell: +39-335-7542-567 From Tobias.Jacobs at neclab.eu Tue Feb 7 11:42:35 2012 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Tue, 7 Feb 2012 10:42:35 +0000 Subject: [Fiware-iot] NGSI 9 and Exposure Interface explanation Message-ID: <8755F290097BD941865DC4245B335D2D08B99B7B@PALLENE.office.hd> Dear Juanjo, all, please find an answer from NEC side to the two points raised in yesterday's WP sync meeting. Should we write the information into the wiki as well? And if yes, which one? ;) Best regards Martin Bauer and Tobias Jacobs Role of Thing-level API in task Process Automation --------------------------------------------------------------------- Without the Thing-level API in the Process Automation subchapter, Applications can obtain Thing-level information from IoT by first going to the "Things/Resources Management GE" to retrieve the Resources that provide the values of the attributes they are interested in. In case that the "Things/Resources Management GE" provides complete resource descriptions, the applications can then go and query directly the relevant resources. In case that the "Things/Resources Management GE" only returns resource identifiers, the applications has to retrieve the corresponding resource description from the "Things/Resources Management GE" in a second step, and access the corresponding resources in the third step. The process described in the preceding paragraph is a natural candidate for automation, and this is what we are planning to do in Task 5.4. The role of the NGSI-10 interface here is to receive requests on the thing level from applications and deploy the process just described on behalf of the application. On the capability of NGSI-9 to discover associations between Things and Resources -------------------------------------------------------------------------------------------------------------- NGSI-9 is for exchanging information about the availability of context information - and it is based on the assumption that all context information can be retrieved from some resource using NGSI-10. Let us, for example, consider the operation DiscoverContextAvailability. In the request, the Context Consumer specifies a list of EntityIDs and Attributes, possibly including patterns, type specifications, etc. The answer from the Context Management Component is a list of ContextRegistrationResponse objects. Each ContextRegistrationResponse contains Entity identifiers, Attribute identifiers, Metadata and - importantly - the ProvidingApplication URI (note that this URI is NOT optional). In other words, A ContextRegistrationResponse states "the value of these entity/attribute combinations can be retrieved at ". As already mentioned earlier, the implicit assumption is that the values are provided by the ProvidingApplication via NGSI 10. However, in FI-WARE the assumption that everything is provided via NGSI-10 is not generally valid, because information will be provided by ETSI M2M resources as well. This is why we were skeptical if NGSI-9 is the right interface for doing resolution. From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Farkas, Lorant (NSN - HU/Budapest) Sent: Montag, 6. Februar 2012 10:54 To: fiware-iot at lists.fi-ware.eu; jhierro at tid.es Subject: [Fiware-iot] IoT meeting minutes Dear All, Please find under this link the minutes of our bi-weekly WP sync. https://forge.fi-ware.eu/docman/view.php/11/782/IoT-coordinator-sync-Minutes-Telco-06022012.docx Dear IoT team, we created some action items to some of you, if there are unclarities please ask. Thanks & Br, Lorant -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorant.farkas at nsn.com Tue Feb 7 13:41:16 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Tue, 7 Feb 2012 14:41:16 +0200 Subject: [Fiware-iot] IoT weekly meeting Message-ID: <93D28BDF64839C468B848D14227151A203135738@FIESEXC014.nsn-intra.net> When: 2012. febru?r 8. 10:00-11:30 (GMT+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague. Where: telco/webex Note: The GMT offset above does not reflect daylight saving time adjustments. *~*~*~*~*~*~*~*~*~* Dear All, We propose the following topics for tomorrow: 1. Architecture specifications - we have feedback from Juanjo that I disclosed yesterday, we need to proceed taking these into account, see this link: https://forge.fi-ware.eu/docman/view.php/11/782/IoT-coordinator-sync-Minutes-Telco-06022012.docx 2. The testbed topic: info still missing from TID and NEC 3. AoB (standardization topic, tracker issues, sprint planning etc) Thanks & Br, Lorant Dear All, Let's resume our weekly meeting starting from next week in the usual day/time, which is Wednesday, 10:00 AM (CET) to 11:30. Either WPL or WPA will be present to host the meeting. In case we find good reason to skip the meeting, then we will skip it, but I propose not to deviate from this slot. Thanks & Br, Lorant Topic: IOT WP weekly Date: Every Wednesday, from Wednesday, 10 August 2011 to Wednesday, 26 March 2014 Time: 10:00, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 709 472 921 Meeting Password: FI-WARE ------------------------------------------------------- To join the online meeting ------------------------------------------------------- 1. Go to https://nsn.webex.com/nsn/j.php?ED=175018962&UID=0&PW=NYzEzYWM0ZTNk&RT=MTgjMjM%3D 2. Enter your name and email address. 3. Enter the meeting password: FI-WARE 4. Click "Join Now". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://nsn.webex.com/nsn/j.php?ED=175018962&UID=0&PW=NYzEzYWM0ZTNk&ORT=MTgjMjM%3D ------------------------------------------------------- NSN Voice Conference information Conference ID: 58465 New PIN: 1628 Making a conference call * from the office: 8071870 (in Finland and Germany) * from out of office: +358 7180 71870 (in Finland) and +49 89 5159 43800 (in Germany) All out-of-office conference access numbers are listed in page https://inside.nokiasiemensnetworks.com/global/MyServices/IT/Infrastructure_Services/RealTimeCommunication/VoiceService/NSNVoiceConference/MakingaCall/LocalAccessNumbers/Pages/Outofofficenumbers.aspx. Please check and prioritize them. If there is no access number for your country then please use access numbers of the area where to the calling costs are lowest. ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://nsn.webex.com/nsn/mc 2. On the left navigation bar, click "Support". You can contact me at: lorant.farkas at nsn.com Argentina - Buenos Aires +54 11 5983 9400 (PRIMARY) or +54 11 4814 9373 Argentina - Cordoba +54 35 1568 2208 Australia - Sydney +61 28 014 7189 (PRIMARY) or +61 29 429 9664 Australia - Melbourne +61 38 739 4333 Austria +43 72 088 0245 Bahrain +97 31 619 9028 Belgium - Generic +32 1448 0116 Belgium - Diegem-Machelen +32 2710 3300 Brazil - Belo Horizonte +55 31 3956 0546 Brazil - Brazil +55 61 3717 2043 Brazil - Curitiba +55 41 3906 0826 Brazil - Manaus +55 92 3652 7576 Brazil - Rio De Janeiro +55 21 3958 0804 (PRIMARY) or +55 21 3431 1999 Brazil - Salvador +55 71 3717 5351 Brazil - Sao Paolo +55 11 5508 0630 Bulgaria +359 2491 7085 Canada - Ajax +1 90 5619 4346 Canada - Burnaby +1 60 4456 5897 Canada - Hamilton +1 905 581 0212 Canada - Mississauga +1 289 360 3950 Canada - Montreal +1 51 4789 9125 Canada - Ottawa +1 61 3800 0568 Chile - Santiago +56 2350 6485 China - Mainland +86 10 8405 5000 ext 1870 China - Beijing +86 10 8405 5000 ext 1870 China - Chengdu +86 28 8689 0188 ext 1870 China - Dongguan +86 0769 2240 2844 ext 1870 China - Guangzhou +86 20 8755 6190 ext 1870 China - Hangzhou +86 571 8722 0877 ext 1870 China - Hong Kong +852 259 70220 ext 1870 China - Kunming +86 871 362 2880 ext 1870 China - Shanghai +86 21 6101 1870 ext 1870 China - ShenZhen +86 755 8613 3688 ext 1870 China - Suzhou +86 512 6761 6166 ext 1870 China - Zhengzhou +86 371 6566 9768 ext 1870 Colombia +57 1640 7979 ext 444 Croatia +38 51 777 6122 Czech Republic +42 02 460 19300 Denmark +45 699 18450 (PRIMARY) or +45 3329 2882 Egypt +97 31 619 9028 (Bahrain nbr) Estonia +37 266 67297 Finland +358 7180 71870 France +33 17 061 7813 (PRIMARY) or +33 14 915 1553 Germany +49 89 5159 43800 Greece +30 21 1176 8207 (PRIMARY) or +30 21 1120 3677 Hungary - Budapest +36 17 009 888 Hungary - Kom?rom +36 20 884 2499 India 000 800 100 7777 Indonesia - Jakarta (Menara Mulia/Plaza Kuningan +62 21 2557 9102 Indonesia - Bandung +62 22 8427 5992 Indonesia - Medan +62 61 3001 2702 Indonesia - Semarang +62 24 3300 0702 Ireland +353 1526 2862 Israel +97 29 775 1700 Italy - Milan +39 024 004 2007 Italy - Rome +39 069 481 6656 Japan +81 3 4578 0230 (PRIMARY) or +81 3 5474 7979 Kuwait +97 31 619 9028 (Bahrain nbr) Latvia +37 16 765 2510 Lithuania +37 0 5205 8994 Luxembourg +352 2088 0106 Malaysia +60 323 029 009 Mexico - Mexico City +52 55 3686 9759 (PRIMARY) or +52 55 5261 7245 Mexico - Reynosa +52 89 9909 1555 Netherlands +31 79 346 5225 New Zealand +64 9306 6933 Norway - Oslo +47 21 548 223 Oman +97 31 619 9028 (Bahrain nbr) Pakistan +92 512 092 444 Panama +507 832 7981 Peru +51 1708 5370 (PRIMARY) or +51 1215 7650 Philippines +63 2754 1700 Poland - Warsaw +48 22 398 8116 Poland - Wroclaw +48 71 718 1215 Portugal +351 21 044 4698 Qatar +97 31 619 9028 (Bahrain nbr) Romania +40 36 440 3799 Russia +74 95 725 2706 Saudi Arabia +97 31 619 9028 (Bahrain nbr) Singapore +65 3103 1065 (PRIMARY) or +65 6723 2582 Slovakia +42 12 3300 6924 Slovenia +38 61 600 2713 South Africa - Johannesburg +27 1 0500 2221 South Africa - Pretoria +27 1 2004 2334 South Korea - Masan +82 5 5290 7690 South Korea - Seoul +82 2 2186 5088 Spain +349 1187 5929 Sweden +46 85 250 0862 (PRIMARY), +46 84 100 9299 Switzerland +41 44 279 7943 Taiwan +88 62 8175 9298 Thailand +66 2762 6750 Turkey +90 216 570 2345 Ukraine +38 044 520 2272 UK +44 12 5275 8334 UK - Camberley +44 12 5286 5849 UK - Church Crookham +44 12 5261 1100 UK - Huntingdon +44 14 8087 8220 (PRIMARY), +44 14 8044 4206 UK - London +44 20 3318 1924 United Arab Emirates +97 31 619 9028 (Bahrain nbr) USA - Alpharetta +1 770 871 3050 USA - Arizona +1 480 588 3748 USA - Atlanta +1 404 236 4550 USA - Atlanta Notheast +1 678 317 3165 USA - Austin/Round Rock +1 512 600 2027 USA - Belleville +1 973 547 7982 USA - Boca Raton +1 561 910 2843 USA - Boston +1 617 963 8320 (PRIMARY) or +1 781 993 4850 USA - Burlington +1 781 993 4850 USA - Calabasas +1 818 914 0215 USA - Canoga Park +1 818 914 0215 USA - Cary +1 919 655 1388 USA - Chelmsford/Littleton +1 978 679 0233 USA - Chicago +1 773 303 4710 USA - Dallas +1 214 269 7626 USA - Dallas/Fort Worth +1 214 270 0352 USA - Greenville, NC +1 252 329 1677 USA - Herndon +1 703 483 4485 USA - Johnson City +1 423 952 1545 USA - Kirkland +1 425 242 3113 USA - Miami +1 786 388 4150 or +1 786 329 7177 USA - Naperville +1 630 596 2203 USA - New Brunswick +1 732 579 6483 USA - New Century, KS +1 913 254 5900 USA - New York White Plains +1 914 368 0650 USA - New York Peekskill, White Plains +1 914 293 1885 USA - Palo Alto +1 650 644 1349 USA - Redmond +1 425 242 3113 USA - San Diego +1 858 769 5309 or +1 619 330 9699 USA - Sunnyvale +1 408 419 1750 USA - Washington D.C +1 202 552 4781 Vietnam +84 4 3724 6110 Yemen +97 31 619 9028 (Bahrain nbr) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 10667 bytes Desc: not available URL: From lorant.farkas at nsn.com Wed Feb 8 08:53:19 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Wed, 8 Feb 2012 09:53:19 +0200 Subject: [Fiware-iot] NGSI 9 and Exposure Interface explanation In-Reply-To: <8755F290097BD941865DC4245B335D2D08B99B7B@PALLENE.office.hd> References: <8755F290097BD941865DC4245B335D2D08B99B7B@PALLENE.office.hd> Message-ID: <93D28BDF64839C468B848D14227151A203135A0D@FIESEXC014.nsn-intra.net> Dear Martin, Tobias, The question for the thing level API was rather the clarification of the role of this GE than the clarification of what the thing level API does. In the architecture we have the interfaces between thing level API and configuration management, observation handler and publish/subscribe broker and thing level API and publish/subscribe broker, so the role of the thing level API GE is a question. In the meeting we guessed that the thing level API GE could have a role of some kind of message broker towards these other GE-s. This should be clarified. Another topic to clarify is the pub/sub broker from Ricardo: a component part of a GE, which one, a standalone GE - then we need an update in the tracker, "materializing..." wiki etc because it is a new GE. Third topic is the merger of the 2 GE-s in resource management to one GE, this should be reflected in the tracker (features, work items, user stories repositioned for this one GE), "materializing..." wiki etc. I can create a work item for every item mentioned above and the progress can be reported there. Thanks & Br, Lorant From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of ext Tobias Jacobs Sent: Tuesday, February 07, 2012 11:43 AM To: fiware-iot at lists.fi-ware.eu; jhierro at tid.es Cc: Salvatore Longo Subject: [Fiware-iot] NGSI 9 and Exposure Interface explanation Dear Juanjo, all, please find an answer from NEC side to the two points raised in yesterday's WP sync meeting. Should we write the information into the wiki as well? And if yes, which one? ;) Best regards Martin Bauer and Tobias Jacobs Role of Thing-level API in task Process Automation --------------------------------------------------------------------- Without the Thing-level API in the Process Automation subchapter, Applications can obtain Thing-level information from IoT by first going to the "Things/Resources Management GE" to retrieve the Resources that provide the values of the attributes they are interested in. In case that the "Things/Resources Management GE" provides complete resource descriptions, the applications can then go and query directly the relevant resources. In case that the "Things/Resources Management GE" only returns resource identifiers, the applications has to retrieve the corresponding resource description from the "Things/Resources Management GE" in a second step, and access the corresponding resources in the third step. The process described in the preceding paragraph is a natural candidate for automation, and this is what we are planning to do in Task 5.4. The role of the NGSI-10 interface here is to receive requests on the thing level from applications and deploy the process just described on behalf of the application. On the capability of NGSI-9 to discover associations between Things and Resources ------------------------------------------------------------------------ -------------------------------------- NGSI-9 is for exchanging information about the availability of context information - and it is based on the assumption that all context information can be retrieved from some resource using NGSI-10. Let us, for example, consider the operation DiscoverContextAvailability. In the request, the Context Consumer specifies a list of EntityIDs and Attributes, possibly including patterns, type specifications, etc. The answer from the Context Management Component is a list of ContextRegistrationResponse objects. Each ContextRegistrationResponse contains Entity identifiers, Attribute identifiers, Metadata and - importantly - the ProvidingApplication URI (note that this URI is NOT optional). In other words, A ContextRegistrationResponse states "the value of these entity/attribute combinations can be retrieved at ". As already mentioned earlier, the implicit assumption is that the values are provided by the ProvidingApplication via NGSI 10. However, in FI-WARE the assumption that everything is provided via NGSI-10 is not generally valid, because information will be provided by ETSI M2M resources as well. This is why we were skeptical if NGSI-9 is the right interface for doing resolution. From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Farkas, Lorant (NSN - HU/Budapest) Sent: Montag, 6. Februar 2012 10:54 To: fiware-iot at lists.fi-ware.eu; jhierro at tid.es Subject: [Fiware-iot] IoT meeting minutes Dear All, Please find under this link the minutes of our bi-weekly WP sync. https://forge.fi-ware.eu/docman/view.php/11/782/IoT-coordinator-sync-Min utes-Telco-06022012.docx Dear IoT team, we created some action items to some of you, if there are unclarities please ask. Thanks & Br, Lorant -------------- next part -------------- An HTML attachment was scrubbed... URL: From rheras at tid.es Wed Feb 8 09:19:19 2012 From: rheras at tid.es (Ricardo de las Heras) Date: Wed, 08 Feb 2012 09:19:19 +0100 Subject: [Fiware-iot] NGSI 9 and Exposure Interface explanation In-Reply-To: <93D28BDF64839C468B848D14227151A203135A0D@FIESEXC014.nsn-intra.net> References: <8755F290097BD941865DC4245B335D2D08B99B7B@PALLENE.office.hd> <93D28BDF64839C468B848D14227151A203135A0D@FIESEXC014.nsn-intra.net> Message-ID: <4F323007.3080104@tid.es> An HTML attachment was scrubbed... URL: From lorant.farkas at nsn.com Wed Feb 8 09:27:33 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Wed, 8 Feb 2012 10:27:33 +0200 Subject: [Fiware-iot] NGSI 9 and Exposure Interface explanation In-Reply-To: <4F323007.3080104@tid.es> References: <8755F290097BD941865DC4245B335D2D08B99B7B@PALLENE.office.hd> <93D28BDF64839C468B848D14227151A203135A0D@FIESEXC014.nsn-intra.net> <4F323007.3080104@tid.es> Message-ID: <93D28BDF64839C468B848D14227151A203135A6C@FIESEXC014.nsn-intra.net> Hi Ricardo, Thanks for the clarification. 1. So I guess when you describe pub/sub broker in your figure, you mention the one from the DCM chapter, right? 2. Martin, Salvatore, your clarifications should find a place in this Wiki page, IMHO. I would not create a task for you do do this, I believe you will do it even without that J Thanks & Br, Lorant From: ext Ricardo de las Heras [mailto:rheras at tid.es] Sent: Wednesday, February 08, 2012 9:19 AM To: Farkas, Lorant (NSN - HU/Budapest) Cc: ext Tobias Jacobs; fiware-iot at lists.fi-ware.eu; JUAN JOSE HIERRO SUREDA; Salvatore Longo Subject: Re: [Fiware-iot] NGSI 9 and Exposure Interface explanation Dear Lorant, all, we can discuss it later on the phc, I recommend you anyway to read the current description of D2.3 at https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/FIWARE.OpenSpecification.IoT.Backend.ThingsAndResourcesManagement Thing level API provides information to the Applications through NGSI-9 regarding the Things/Resources, their associations and properties. Publish/Subscribe broker provides basically information about the observations collected from the Resources using NGSI-10. You are right, we need to update the tracker with these components, br, Ricardo. Farkas, Lorant (NSN - HU/Budapest) wrote: Dear Martin, Tobias, The question for the thing level API was rather the clarification of the role of this GE than the clarification of what the thing level API does. In the architecture we have the interfaces between thing level API and configuration management, observation handler and publish/subscribe broker and thing level API and publish/subscribe broker, so the role of the thing level API GE is a question. In the meeting we guessed that the thing level API GE could have a role of some kind of message broker towards these other GE-s. This should be clarified. Another topic to clarify is the pub/sub broker from Ricardo: a component part of a GE, which one, a standalone GE - then we need an update in the tracker, "materializing..." wiki etc because it is a new GE. Third topic is the merger of the 2 GE-s in resource management to one GE, this should be reflected in the tracker (features, work items, user stories repositioned for this one GE), "materializing..." wiki etc. I can create a work item for every item mentioned above and the progress can be reported there. Thanks & Br, Lorant From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of ext Tobias Jacobs Sent: Tuesday, February 07, 2012 11:43 AM To: fiware-iot at lists.fi-ware.eu; jhierro at tid.es Cc: Salvatore Longo Subject: [Fiware-iot] NGSI 9 and Exposure Interface explanation Dear Juanjo, all, please find an answer from NEC side to the two points raised in yesterday's WP sync meeting. Should we write the information into the wiki as well? And if yes, which one? ;) Best regards Martin Bauer and Tobias Jacobs Role of Thing-level API in task Process Automation --------------------------------------------------------------------- Without the Thing-level API in the Process Automation subchapter, Applications can obtain Thing-level information from IoT by first going to the "Things/Resources Management GE" to retrieve the Resources that provide the values of the attributes they are interested in. In case that the "Things/Resources Management GE" provides complete resource descriptions, the applications can then go and query directly the relevant resources. In case that the "Things/Resources Management GE" only returns resource identifiers, the applications has to retrieve the corresponding resource description from the "Things/Resources Management GE" in a second step, and access the corresponding resources in the third step. The process described in the preceding paragraph is a natural candidate for automation, and this is what we are planning to do in Task 5.4. The role of the NGSI-10 interface here is to receive requests on the thing level from applications and deploy the process just described on behalf of the application. On the capability of NGSI-9 to discover associations between Things and Resources -------------------------------------------------------------------------------------------------------------- NGSI-9 is for exchanging information about the availability of context information - and it is based on the assumption that all context information can be retrieved from some resource using NGSI-10. Let us, for example, consider the operation DiscoverContextAvailability. In the request, the Context Consumer specifies a list of EntityIDs and Attributes, possibly including patterns, type specifications, etc. The answer from the Context Management Component is a list of ContextRegistrationResponse objects. Each ContextRegistrationResponse contains Entity identifiers, Attribute identifiers, Metadata and - importantly - the ProvidingApplication URI (note that this URI is NOT optional). In other words, A ContextRegistrationResponse states "the value of these entity/attribute combinations can be retrieved at ". As already mentioned earlier, the implicit assumption is that the values are provided by the ProvidingApplication via NGSI 10. However, in FI-WARE the assumption that everything is provided via NGSI-10 is not generally valid, because information will be provided by ETSI M2M resources as well. This is why we were skeptical if NGSI-9 is the right interface for doing resolution. From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Farkas, Lorant (NSN - HU/Budapest) Sent: Montag, 6. Februar 2012 10:54 To: fiware-iot at lists.fi-ware.eu; jhierro at tid.es Subject: [Fiware-iot] IoT meeting minutes Dear All, Please find under this link the minutes of our bi-weekly WP sync. https://forge.fi-ware.eu/docman/view.php/11/782/IoT-coordinator-sync-Minutes-Telco-06022012.docx Dear IoT team, we created some action items to some of you, if there are unclarities please ask. Thanks & Br, Lorant -- ------------------------------------------- Ricardo de las Heras Technological Specialist Enabling Platforms E-mail: rheras at tid.es Phone1: (+34) 983 367625 Phone2 OCS: (+34) 91 31 29511 Telef?nica Digital ------------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorant.farkas at nsn.com Wed Feb 8 14:34:08 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Wed, 8 Feb 2012 15:34:08 +0200 Subject: [Fiware-iot] IoT weekly minutes Message-ID: <93D28BDF64839C468B848D14227151A20317AD03@FIESEXC014.nsn-intra.net> Dear All, Please find the minutes of our weekly call under the following link: https://forge.fi-ware.eu/docman/view.php/11/797/IoT-Minutes-Telco-080220 12.docx Thanks & Br, Lorant -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorant.farkas at nsn.com Wed Feb 8 14:37:28 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Wed, 8 Feb 2012 15:37:28 +0200 Subject: [Fiware-iot] WP5 level standardization contribution Message-ID: <93D28BDF64839C468B848D14227151A20317AD09@FIESEXC014.nsn-intra.net> Dear All, Please find attached the WP5 level contribution for standardization put together by D?nes and Thierry (look for the text under chapters labelled WP5...). <> Comments are welcome, the deadline is passed, but we can still submit modifications in case. Br, Lorant -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FI-WARE_Standardisation_Plan_20120207.docx Type: application/octet-stream Size: 531686 bytes Desc: FI-WARE_Standardisation_Plan_20120207.docx URL: From Ernoe.Kovacs at neclab.eu Thu Feb 9 09:27:46 2012 From: Ernoe.Kovacs at neclab.eu (Ernoe Kovacs) Date: Thu, 9 Feb 2012 08:27:46 +0000 Subject: [Fiware-iot] WP5 level standardization contribution In-Reply-To: <93D28BDF64839C468B848D14227151A20317AD09@FIESEXC014.nsn-intra.net> References: <93D28BDF64839C468B848D14227151A20317AD09@FIESEXC014.nsn-intra.net> Message-ID: <8152E2132B13FB488CFD1947E2DEF19C24F8B79A@PALLENE.office.hd> Lorant, all, please be aware that in ETSI M2M we have already started a work item on "Semantic Support for M2M Data". This is coming from IoT-A and FIWare. Martin and Tobias have done a lot of the work. So we are already influencing the standard. We actually had a presentation at the Q4/2011 ETSI M2M workshop on this. ? Suggest to add this to the contribution. Makes our activities stronger... - Ern? From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Farkas, Lorant (NSN - HU/Budapest) Sent: Mittwoch, 8. Februar 2012 14:37 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] WP5 level standardization contribution Dear All, Please find attached the WP5 level contribution for standardization put together by D?nes and Thierry (look for the text under chapters labelled WP5...). <> Comments are welcome, the deadline is passed, but we can still submit modifications in case. Br, Lorant -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorant.farkas at nsn.com Thu Feb 9 12:28:49 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Thu, 9 Feb 2012 13:28:49 +0200 Subject: [Fiware-iot] SVN access bug Message-ID: <93D28BDF64839C468B848D14227151A20317B26A@FIESEXC014.nsn-intra.net> Dear All, Only admin members of the IoT project can access the SVN. There is a bug report on this since beginning of December. As a workaround, if you want to access SVN, please let me and D?nes know, we will upgrade your account to admin temporarily and downgrade back when you finished working with the SVN. Apologies for the inconvenience. Br, Lorant -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorant.farkas at nsn.com Tue Feb 14 09:08:04 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Tue, 14 Feb 2012 10:08:04 +0200 Subject: [Fiware-iot] IoT weekly meeting Message-ID: <93D28BDF64839C468B848D14227151A2031B28E0@FIESEXC014.nsn-intra.net> When: 2012. febru?r 15. 10:00-11:30 (GMT+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague. Where: telco/webex Note: The GMT offset above does not reflect daylight saving time adjustments. *~*~*~*~*~*~*~*~*~* Dear All, We propose the following topics for tomorrow: 1. Architecture specifications: -discuss on the progress, -what to include/leave out, -IoT specificity -how to put in standards information, when we utilize standards (ETSI M2M, NGSI) 2. Security action item: I've been told we had some content in Madrid which should be digged out, developed further and contributed ASAP to Pascal Bisson 3. Standardization: contribution by Ern? - decide whether to include or not, Ern? to propose a way of inclusion in the doc 4. Technical roadmap: a deliverable for the end of the week, fortunately a short one, WPA/WPL will try to dig out more info It seems I have to take a day off, so most probably Thierry will host this and D?nes will take minutes Thanks & Br, Lorant Dear All, Let's resume our weekly meeting starting from next week in the usual day/time, which is Wednesday, 10:00 AM (CET) to 11:30. Either WPL or WPA will be present to host the meeting. In case we find good reason to skip the meeting, then we will skip it, but I propose not to deviate from this slot. Thanks & Br, Lorant Topic: IOT WP weekly Date: Every Wednesday, from Wednesday, 10 August 2011 to Wednesday, 26 March 2014 Time: 10:00, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 709 472 921 Meeting Password: FI-WARE ------------------------------------------------------- To join the online meeting ------------------------------------------------------- 1. Go to https://nsn.webex.com/nsn/j.php?ED=175018962&UID=0&PW=NYzEzYWM0ZTNk&RT=MTgjMjM%3D 2. Enter your name and email address. 3. Enter the meeting password: FI-WARE 4. Click "Join Now". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://nsn.webex.com/nsn/j.php?ED=175018962&UID=0&PW=NYzEzYWM0ZTNk&ORT=MTgjMjM%3D ------------------------------------------------------- NSN Voice Conference information Conference ID: 58465 New PIN: 1628 Making a conference call * from the office: 8071870 (in Finland and Germany) * from out of office: +358 7180 71870 (in Finland) and +49 89 5159 43800 (in Germany) All out-of-office conference access numbers are listed in page https://inside.nokiasiemensnetworks.com/global/MyServices/IT/Infrastructure_Services/RealTimeCommunication/VoiceService/NSNVoiceConference/MakingaCall/LocalAccessNumbers/Pages/Outofofficenumbers.aspx. Please check and prioritize them. If there is no access number for your country then please use access numbers of the area where to the calling costs are lowest. ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://nsn.webex.com/nsn/mc 2. On the left navigation bar, click "Support". You can contact me at: lorant.farkas at nsn.com Argentina - Buenos Aires +54 11 5983 9400 (PRIMARY) or +54 11 4814 9373 Argentina - Cordoba +54 35 1568 2208 Australia - Sydney +61 28 014 7189 (PRIMARY) or +61 29 429 9664 Australia - Melbourne +61 38 739 4333 Austria +43 72 088 0245 Bahrain +97 31 619 9028 Belgium - Generic +32 1448 0116 Belgium - Diegem-Machelen +32 2710 3300 Brazil - Belo Horizonte +55 31 3956 0546 Brazil - Brazil +55 61 3717 2043 Brazil - Curitiba +55 41 3906 0826 Brazil - Manaus +55 92 3652 7576 Brazil - Rio De Janeiro +55 21 3958 0804 (PRIMARY) or +55 21 3431 1999 Brazil - Salvador +55 71 3717 5351 Brazil - Sao Paolo +55 11 5508 0630 Bulgaria +359 2491 7085 Canada - Ajax +1 90 5619 4346 Canada - Burnaby +1 60 4456 5897 Canada - Hamilton +1 905 581 0212 Canada - Mississauga +1 289 360 3950 Canada - Montreal +1 51 4789 9125 Canada - Ottawa +1 61 3800 0568 Chile - Santiago +56 2350 6485 China - Mainland +86 10 8405 5000 ext 1870 China - Beijing +86 10 8405 5000 ext 1870 China - Chengdu +86 28 8689 0188 ext 1870 China - Dongguan +86 0769 2240 2844 ext 1870 China - Guangzhou +86 20 8755 6190 ext 1870 China - Hangzhou +86 571 8722 0877 ext 1870 China - Hong Kong +852 259 70220 ext 1870 China - Kunming +86 871 362 2880 ext 1870 China - Shanghai +86 21 6101 1870 ext 1870 China - ShenZhen +86 755 8613 3688 ext 1870 China - Suzhou +86 512 6761 6166 ext 1870 China - Zhengzhou +86 371 6566 9768 ext 1870 Colombia +57 1640 7979 ext 444 Croatia +38 51 777 6122 Czech Republic +42 02 460 19300 Denmark +45 699 18450 (PRIMARY) or +45 3329 2882 Egypt +97 31 619 9028 (Bahrain nbr) Estonia +37 266 67297 Finland +358 7180 71870 France +33 17 061 7813 (PRIMARY) or +33 14 915 1553 Germany +49 89 5159 43800 Greece +30 21 1176 8207 (PRIMARY) or +30 21 1120 3677 Hungary - Budapest +36 17 009 888 Hungary - Kom?rom +36 20 884 2499 India 000 800 100 7777 Indonesia - Jakarta (Menara Mulia/Plaza Kuningan +62 21 2557 9102 Indonesia - Bandung +62 22 8427 5992 Indonesia - Medan +62 61 3001 2702 Indonesia - Semarang +62 24 3300 0702 Ireland +353 1526 2862 Israel +97 29 775 1700 Italy - Milan +39 024 004 2007 Italy - Rome +39 069 481 6656 Japan +81 3 4578 0230 (PRIMARY) or +81 3 5474 7979 Kuwait +97 31 619 9028 (Bahrain nbr) Latvia +37 16 765 2510 Lithuania +37 0 5205 8994 Luxembourg +352 2088 0106 Malaysia +60 323 029 009 Mexico - Mexico City +52 55 3686 9759 (PRIMARY) or +52 55 5261 7245 Mexico - Reynosa +52 89 9909 1555 Netherlands +31 79 346 5225 New Zealand +64 9306 6933 Norway - Oslo +47 21 548 223 Oman +97 31 619 9028 (Bahrain nbr) Pakistan +92 512 092 444 Panama +507 832 7981 Peru +51 1708 5370 (PRIMARY) or +51 1215 7650 Philippines +63 2754 1700 Poland - Warsaw +48 22 398 8116 Poland - Wroclaw +48 71 718 1215 Portugal +351 21 044 4698 Qatar +97 31 619 9028 (Bahrain nbr) Romania +40 36 440 3799 Russia +74 95 725 2706 Saudi Arabia +97 31 619 9028 (Bahrain nbr) Singapore +65 3103 1065 (PRIMARY) or +65 6723 2582 Slovakia +42 12 3300 6924 Slovenia +38 61 600 2713 South Africa - Johannesburg +27 1 0500 2221 South Africa - Pretoria +27 1 2004 2334 South Korea - Masan +82 5 5290 7690 South Korea - Seoul +82 2 2186 5088 Spain +349 1187 5929 Sweden +46 85 250 0862 (PRIMARY), +46 84 100 9299 Switzerland +41 44 279 7943 Taiwan +88 62 8175 9298 Thailand +66 2762 6750 Turkey +90 216 570 2345 Ukraine +38 044 520 2272 UK +44 12 5275 8334 UK - Camberley +44 12 5286 5849 UK - Church Crookham +44 12 5261 1100 UK - Huntingdon +44 14 8087 8220 (PRIMARY), +44 14 8044 4206 UK - London +44 20 3318 1924 United Arab Emirates +97 31 619 9028 (Bahrain nbr) USA - Alpharetta +1 770 871 3050 USA - Arizona +1 480 588 3748 USA - Atlanta +1 404 236 4550 USA - Atlanta Notheast +1 678 317 3165 USA - Austin/Round Rock +1 512 600 2027 USA - Belleville +1 973 547 7982 USA - Boca Raton +1 561 910 2843 USA - Boston +1 617 963 8320 (PRIMARY) or +1 781 993 4850 USA - Burlington +1 781 993 4850 USA - Calabasas +1 818 914 0215 USA - Canoga Park +1 818 914 0215 USA - Cary +1 919 655 1388 USA - Chelmsford/Littleton +1 978 679 0233 USA - Chicago +1 773 303 4710 USA - Dallas +1 214 269 7626 USA - Dallas/Fort Worth +1 214 270 0352 USA - Greenville, NC +1 252 329 1677 USA - Herndon +1 703 483 4485 USA - Johnson City +1 423 952 1545 USA - Kirkland +1 425 242 3113 USA - Miami +1 786 388 4150 or +1 786 329 7177 USA - Naperville +1 630 596 2203 USA - New Brunswick +1 732 579 6483 USA - New Century, KS +1 913 254 5900 USA - New York White Plains +1 914 368 0650 USA - New York Peekskill, White Plains +1 914 293 1885 USA - Palo Alto +1 650 644 1349 USA - Redmond +1 425 242 3113 USA - San Diego +1 858 769 5309 or +1 619 330 9699 USA - Sunnyvale +1 408 419 1750 USA - Washington D.C +1 202 552 4781 Vietnam +84 4 3724 6110 Yemen +97 31 619 9028 (Bahrain nbr) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 11019 bytes Desc: not available URL: From Ernoe.Kovacs at neclab.eu Tue Feb 14 09:18:13 2012 From: Ernoe.Kovacs at neclab.eu (Ernoe Kovacs) Date: Tue, 14 Feb 2012 08:18:13 +0000 Subject: [Fiware-iot] FW: Note taken on 26.01.12. In-Reply-To: <51328AB3-568C-438D-90B6-D0F2551E9FEF@googlemail.com> References: <51328AB3-568C-438D-90B6-D0F2551E9FEF@googlemail.com> Message-ID: <8152E2132B13FB488CFD1947E2DEF19C24F968AB@PALLENE.office.hd> Hi all, please find attached the pictures from the whiteboard as discussed in Madrid. Kind regards Ern? -----Original Message----- From: Ern? Kovacs [mailto:ernoekovacs at googlemail.com] Sent: Freitag, 10. Februar 2012 11:31 To: ernoe.kovacs at nw.neclab.eu Subject: Note taken on 26.01.12. Created with JotNot. http://itunes.apple.com/us/app/jotnot-scanner/id307868751?mt=8 -------------- next part -------------- A non-text attachment was scrubbed... Name: Doc-24.01.12 1409-page-3.pdf Type: application/pdf Size: 334517 bytes Desc: Doc-24.01.12 1409-page-3.pdf URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From Tobias.Jacobs at neclab.eu Tue Feb 14 13:53:23 2012 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Tue, 14 Feb 2012 12:53:23 +0000 Subject: [Fiware-iot] IoT Architecture Discussion Message-ID: <8755F290097BD941865DC4245B335D2D08B9A6B6@PALLENE.office.hd> Dear Juanjo, dear all, In order to reach a conclusion in our discussion about the role of the Thing-Level interface, we propose a slightly modified architecture picture, see appendix. The changes are - The component responsible for translating NGSI requests into resource requests and performing those requests on behalf of the application is now called "request handler". It resides in the "Thing-Level API". - The Observation Handler now resides in the Thing-Level API as well. This is because its functionality is complementary to the request handler and therefore should reside in the same GE. Another reason for moving the Observation Handler is that it deals both with data and with resources and therefore does fit into task 5.4 better than into 5.2. - The Publish/Subscribe Broker now resides on top of the whole backend. Its single point of contact to the IoT Backend is the Observation Handler, which publishes events into it. We hope that we can come to a final agreement in tomorrow's phone conference. Best regards Martin and Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IoT-Complete_tj_2011-02-14.graphml Type: application/octet-stream Size: 232023 bytes Desc: IoT-Complete_tj_2011-02-14.graphml URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IoT-Complete_tj_2011-02-14.pdf Type: application/pdf Size: 1230069 bytes Desc: IoT-Complete_tj_2011-02-14.pdf URL: From denes.bisztray at nsn.com Wed Feb 15 09:02:11 2012 From: denes.bisztray at nsn.com (Bisztray, Denes (NSN - HU/Budapest)) Date: Wed, 15 Feb 2012 09:02:11 +0100 Subject: [Fiware-iot] IoT Architecture Discussion In-Reply-To: <8755F290097BD941865DC4245B335D2D08B9A6B6@PALLENE.office.hd> References: <8755F290097BD941865DC4245B335D2D08B9A6B6@PALLENE.office.hd> Message-ID: <3F4C11BC54A36642BFB5875D599F47BD058AF22A@DEMUEXC013.nsn-intra.net> Dear Martin and Tobias, Can you please upload this to the wiki? Best, D?nes From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of ext Tobias Jacobs Sent: Tuesday, February 14, 2012 1:53 PM To: fiware-iot at lists.fi-ware.eu; jhierro at tid.es Cc: Salvatore Longo Subject: Re: [Fiware-iot] IoT Architecture Discussion Dear Juanjo, dear all, In order to reach a conclusion in our discussion about the role of the Thing-Level interface, we propose a slightly modified architecture picture, see appendix. The changes are - The component responsible for translating NGSI requests into resource requests and performing those requests on behalf of the application is now called "request handler". It resides in the "Thing-Level API". - The Observation Handler now resides in the Thing-Level API as well. This is because its functionality is complementary to the request handler and therefore should reside in the same GE. Another reason for moving the Observation Handler is that it deals both with data and with resources and therefore does fit into task 5.4 better than into 5.2. - The Publish/Subscribe Broker now resides on top of the whole backend. Its single point of contact to the IoT Backend is the Observation Handler, which publishes events into it. We hope that we can come to a final agreement in tomorrow's phone conference. Best regards Martin and Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Bauer at neclab.eu Wed Feb 15 14:47:38 2012 From: Martin.Bauer at neclab.eu (Martin Bauer) Date: Wed, 15 Feb 2012 13:47:38 +0000 Subject: [Fiware-iot] Review Comments FiwareDeliverable D2.3 IoT - ThingsAndResourcesManagement Message-ID: Hi Ricardo and T5.2 people, I finally had time to look at the ThingsAndResourcesManagement GE Description in D2.3 and I have the comments and corrections listed below: FIWARE.ArchitectureDescription.IoT.Backend.ThingsAndResourcesManagement - "Overview": "Additionally this GE dynamically maintains associations between Things and IoT RESOURCES." - "Overview": "Therefore the IoT Resource Management describes the functional components of a scalable distributed architecture for resolution, discovery and event processing". I do not really understand why "event processing" is mentioned. (Complex) event processing is typically used to combine and derive more high level events. I don't see that as part of the ThingsAndResourcesManagement GE functionality. - "Basic Concepts - Information Data Model": "a Thing denotes a physical object in the real world, being characterized by several properties that represents its state along the time described by couples of value-timeStamp." I think you mean "pair" (as in "key-value pair") instead of "couple". - The alignment of the Thing/Resource Data Model and the NGSI Information Model is not done in a very detailed way and there are inconsistencies. The NGSI data model does not have value-timestamp pairs. Rather you have a more complex structure and the timestamp may be one of the pieces of information that are attached to a value as Meta-Data. - "Northbound Interfaces": "There are two kind of interfaces, one for context information discovery, another one for context information query/update." "subscription" is missing as an important functionality of the latter. - "Northbound Interfaces - NGSI-9": "NGSI-9 manages the simple concept of 'Entities and Properties' " - here the Thing and IoT Resources data model and the NGSI data model are mixed. If we talk about NGSI I think we should stick to the latter. - "Northbound Interfaces - NGSI-9": So, it deals with metadata, i.e. the configuration, management aspects, allowing queries and to trigger events when a new entity or property appear, or the value of a property has changed, ... " The last point is wrong - NGSI-9 cannot be used to subscribe for values, only what information is generally available, so values can be retrieved using NGSI-10. - "Northbound Interfaces - NGSI-9": "IT is important to remark here that a question to analySe is whether we should go for extending NGSI-9 and fast-track results of such extension to OMA (for define associations between Things and Resources), because these type of definitions are not currently supported by the NGSI-9 API." - Even though the NGSI-9 interface does not have the concept of "associations", most of the information can anyway encoded there. However, NGSI-9 assumes that the "associations" always refer to NGSI-10 components, so only a reference (URI) pointing to the NGSI-10 interface of the component that can provide the information is included in the "association". This is insufficient for general IoT Resources that may have arbitrary interfaces. - "Northbound Interfaces - NGSI-10": "When observations are captured by IoT resources (software) running at IoT devices, they have to be notified to the Things Management Layer." - We at NEC do not believe that this should always be / have to be the case. This is not a suitable assumption for a number of IoT scenarios where we are dealing with resource-constraint devices, especially battery-powered devices. Always pushing out notifications without applications currently being interested can unnecessarily drain the energy of these devices. - "Northbound Interfaces - NGSI-10": The subscription operation is missing, which is an important part of the NGSI-10 interface. - "Southbound Interfaces - ETSI M2M": "Using ETSI-M2M resources can send registrations and observations, fully supporting the requirements as means to register resources and send observations". This sounds like ETSI M2M supports automatically sending observations to the infrastructure (Observation Handler?). ETSI M2M has a concept of REST Resources, so there always needs to be an "application component (from the ETSI M2M point of view)" that first explicitly subscribes for this information. It is not clear how this is supposed to be done. - "Things and Resources Management Architecture -Event Repository": The Event Repository does not appear in the Architecture (Figure 5.2.3). We at NEC do not think that such a component should be part of the "Things and Resource Management GE". - "Things and Resources Management Architecture -User Portal": We think there should be a differentiation between the interface for registering the entities (which may be used by system components as well as user application components) and the way a user can interact with this. A Web Interface is just one option for user interaction. - "Things and Resources Management Architecture -Observation Handler" - again there is a reference to the Event Repository, which is not part of the architecture figure. Such a component should be part of data handling T5.3. As the "Observation Handler" deals with both T5.2 and T5.3 components, we think it fits better into the T5.4 Exposure GE -->see NEC's changed architecture proposal - "Things and Resources Management Architecture - Subscribing to creation/updates/deletion of Entities (Things or IoT Resources)" - I do not agree with the use of the term entity as a super type of things AND IoT Resources. IoT Resources are functional components that implement interfaces. These need to be properly described and matched. NGSI-9 only provides information about what entities and attributes can be provided, but not any values - so at most an insufficient amount of information about a resource can be encoded (e.g. as EntityType), which based on a subscription could lead to a huge amount of notifications (e.g. EntityType=temperature resource) and the Resource Description itself anyway would have to be requested in an additional step. Best regards, Martin ------------------------------------------ Dr. Martin Bauer Senior Researcher NEC Europe Ltd. NEC Laboratories Europe Software & Services Research Division Kurf?rsten-Anlage 36 D-69115 Heidelberg Tel: +49/ (0)6221/4342-168 Fax: +49/ (0)6221/4342-155 E-Mail: Martin.Bauer at neclab.eu http://www.nw.neclab.eu ************************************************************* NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 -------------- next part -------------- An HTML attachment was scrubbed... URL: From denes.bisztray at nsn.com Wed Feb 15 14:53:10 2012 From: denes.bisztray at nsn.com (Bisztray, Denes (NSN - HU/Budapest)) Date: Wed, 15 Feb 2012 14:53:10 +0100 Subject: [Fiware-iot] IoT Weekly Minutes 15.02.2012 Message-ID: <3F4C11BC54A36642BFB5875D599F47BD058AF6A3@DEMUEXC013.nsn-intra.net> Dear All, Please find the minutes of our weekly call under the following link: https://forge.fi-ware.eu/docman/view.php/11/807/IoT-Minutes-Telco-15022012.docx Best, D?nes -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tobias.Jacobs at neclab.eu Wed Feb 15 15:17:44 2012 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Wed, 15 Feb 2012 14:17:44 +0000 Subject: [Fiware-iot] Architecture modification implemented Message-ID: <8755F290097BD941865DC4245B335D2D08BA3527@DAPHNIS.office.hd> Dear IoT, This is just a short notification that I implemented the architecture change proposed yesterday in the wiki. This includes moving the Observation Handler from Things/Resources Management GE https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/FIWARE.ArchitectureDescription.IoT.Backend.ThingsAndResourcesManagement to Exposure GE https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/FIWARE.ArchitectureDescription.IoT.Backend.Exposure. By the way, does somebody feel responsible to describe the Device-Level API, the Process Handler, and the Semantic Handler in the Exposure GE? Best regards Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From denes.bisztray at nsn.com Wed Feb 15 15:35:00 2012 From: denes.bisztray at nsn.com (Bisztray, Denes (NSN - HU/Budapest)) Date: Wed, 15 Feb 2012 15:35:00 +0100 Subject: [Fiware-iot] Architecture modification implemented In-Reply-To: <8755F290097BD941865DC4245B335D2D08BA3527@DAPHNIS.office.hd> References: <8755F290097BD941865DC4245B335D2D08BA3527@DAPHNIS.office.hd> Message-ID: <3F4C11BC54A36642BFB5875D599F47BD058AF73E@DEMUEXC013.nsn-intra.net> The Device-level API should have the same description that the one on the Gateway. Once TI finishes the description on the Gateway, I'll adapt it to the backend. The Semantic Handler and Process Handler will be covered later, (with UoS and SAP respectively), but not for this release. These are exactly those components that we have to take note of but not describe because it won't be delivered. From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of ext Tobias Jacobs Sent: Wednesday, February 15, 2012 3:18 PM To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Architecture modification implemented Dear IoT, This is just a short notification that I implemented the architecture change proposed yesterday in the wiki. This includes moving the Observation Handler from Things/Resources Management GE https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.ph p/FIWARE.ArchitectureDescription.IoT.Backend.ThingsAndResourcesManagemen t to Exposure GE https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.ph p/FIWARE.ArchitectureDescription.IoT.Backend.Exposure. By the way, does somebody feel responsible to describe the Device-Level API, the Process Handler, and the Semantic Handler in the Exposure GE? Best regards Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From gianpiero.fici at telecomitalia.it Wed Feb 15 18:53:41 2012 From: gianpiero.fici at telecomitalia.it (Fici Gian Piero) Date: Wed, 15 Feb 2012 18:53:41 +0100 Subject: [Fiware-iot] R: Architecture modification implemented In-Reply-To: <3F4C11BC54A36642BFB5875D599F47BD058AF73E@DEMUEXC013.nsn-intra.net> References: <8755F290097BD941865DC4245B335D2D08BA3527@DAPHNIS.office.hd> <3F4C11BC54A36642BFB5875D599F47BD058AF73E@DEMUEXC013.nsn-intra.net> Message-ID: Hi D?nes, I agree that the two descriptions of the Device Level API component, at Backend and at Gateway level, should be the same. The description of the Exposure GE is completed, unless there are any comments or request for modification, so you can use it. If anybody has any comment please let us know and we will include them in the description. Ciao, Gian Piero Da: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] Per conto di Bisztray, Denes (NSN - HU/Budapest) Inviato: mercoled? 15 febbraio 2012 15:35 A: ext Tobias Jacobs; fiware-iot at lists.fi-ware.eu Oggetto: Re: [Fiware-iot] Architecture modification implemented The Device-level API should have the same description that the one on the Gateway. Once TI finishes the description on the Gateway, I'll adapt it to the backend. The Semantic Handler and Process Handler will be covered later, (with UoS and SAP respectively), but not for this release. These are exactly those components that we have to take note of but not describe because it won't be delivered. From:< 0pt;font-family:"Tahoma","sans-serif"'> fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of ext Tobias Jacobs Sent: Wednesday, February 15, 2012 3:18 PM To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Architecture modification implemented Dear IoT, This is just a short notification that I implemented the architecture change proposed yesterday in the wiki. This includes moving the Observation Handler from Things/Resources Management GE https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/FIWARE.ArchitectureDescription.IoT.Backend.Thi to Exposure GE https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/FIWARE.ArchitectureDescription.IoT.Backend.Exposure. By the way, does somebody feel responsible to describe the Device-Level API, the Process Handler, and the Semantic Handler in the Exposure GE? Best regards Tobias Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:00000000000000000000000000000001 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia.jpg URL: From stephan.haller at sap.com Thu Feb 16 11:20:44 2012 From: stephan.haller at sap.com (Haller, Stephan) Date: Thu, 16 Feb 2012 11:20:44 +0100 Subject: [Fiware-iot] Review Comments FiwareDeliverable D2.3 IoT - ThingsAndResourcesManagement In-Reply-To: References: Message-ID: <0D2446AEB6CAED48BB046223733964A54CA47F0BFB@DEWDFECCR01.wdf.sap.corp> All, I agree with the comments from Martin. In addition: On the Information Data Model: ? The definition of resource is wrong ("A Resource is a physical component (hardware)"). A resource is a software component, as defined in the FI-WARE high-level description: "Computational elements (software) that provide the technical means to perform sensing and/or actuation on the device". *DONE* ? The properties (attributes) of a Thing are NOT equal to the union of the observation values of all associated resources. A Thing might have additional properties that are not measured by any sensors. Simple example: The Thing "strawberry yoghurt" has an expiration date, a list of ingredients etc. *DONE* ? The relationship between Figures 5.2.1 and 5.2.2 is unclear. Do I understand this correctly that both Things as well as Resources are modeled as Context Elements? ? What are attribute domains? I cannot find this in Figure 5.2.2 As time is running short, I have taken the liberty to make some corrections directly in the Wiki (plus some editorial changes). I have marked the points I corrected with "*DONE*". Regards, -Stephan From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Martin Bauer Sent: Mittwoch, 15. Februar 2012 14:48 To: Ricardo de las Heras (rheras at tid.es) Cc: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Review Comments FiwareDeliverable D2.3 IoT - ThingsAndResourcesManagement Hi Ricardo and T5.2 people, I finally had time to look at the ThingsAndResourcesManagement GE Description in D2.3 and I have the comments and corrections listed below: FIWARE.ArchitectureDescription.IoT.Backend.ThingsAndResourcesManagement - "Overview": "Additionally this GE dynamically maintains associations between Things and IoT RESOURCES." *DONE* - "Overview": "Therefore the IoT Resource Management describes the functional components of a scalable distributed architecture for resolution, discovery and event processing". I do not really understand why "event processing" is mentioned. (Complex) event processing is typically used to combine and derive more high level events. I don't see that as part of the ThingsAndResourcesManagement GE functionality. *DONE* - "Basic Concepts - Information Data Model": "a Thing denotes a physical object in the real world, being characterized by several properties that represents its state along the time described by couples of value-timeStamp." I think you mean "pair" (as in "key-value pair") instead of "couple". *DONE* - The alignment of the Thing/Resource Data Model and the NGSI Information Model is not done in a very detailed way and there are inconsistencies. The NGSI data model does not have value-timestamp pairs. Rather you have a more complex structure and the timestamp may be one of the pieces of information that are attached to a value as Meta-Data. - "Northbound Interfaces": "There are two kind of interfaces, one for context information discovery, another one for context information query/update." "subscription" is missing as an important functionality of the latter. - "Northbound Interfaces - NGSI-9": "NGSI-9 manages the simple concept of 'Entities and Properties' " - here the Thing and IoT Resources data model and the NGSI data model are mixed. If we talk about NGSI I think we should stick to the latter. - "Northbound Interfaces - NGSI-9": So, it deals with metadata, i.e. the configuration, management aspects, allowing queries and to trigger events when a new entity or property appear, or the value of a property has changed, ... " The last point is wrong - NGSI-9 cannot be used to subscribe for values, only what information is generally available, so values can be retrieved using NGSI-10. - "Northbound Interfaces - NGSI-9": "IT is important to remark here that a question to analySe is whether we should go for extending NGSI-9 and fast-track results of such extension to OMA (for define associations between Things and Resources), because these type of definitions are not currently supported by the NGSI-9 API." - Even though the NGSI-9 interface does not have the concept of "associations", most of the information can anyway encoded there. However, NGSI-9 assumes that the "associations" always refer to NGSI-10 components, so only a reference (URI) pointing to the NGSI-10 interface of the component that can provide the information is included in the "association". This is insufficient for general IoT Resources that may have arbitrary interfaces. - "Northbound Interfaces - NGSI-10": "When observations are captured by IoT resources (software) running at IoT devices, they have to be notified to the Things Management Layer." - We at NEC do not believe that this should always be / have to be the case. This is not a suitable assumption for a number of IoT scenarios where we are dealing with resource-constraint devices, especially battery-powered devices. Always pushing out notifications without applications currently being interested can unnecessarily drain the energy of these devices. - "Northbound Interfaces - NGSI-10": The subscription operation is missing, which is an important part of the NGSI-10 interface. - "Southbound Interfaces - ETSI M2M": "Using ETSI-M2M resources can send registrations and observations, fully supporting the requirements as means to register resources and send observations". This sounds like ETSI M2M supports automatically sending observations to the infrastructure (Observation Handler?). ETSI M2M has a concept of REST Resources, so there always needs to be an "application component (from the ETSI M2M point of view)" that first explicitly subscribes for this information. It is not clear how this is supposed to be done. - "Things and Resources Management Architecture -Event Repository": The Event Repository does not appear in the Architecture (Figure 5.2.3). We at NEC do not think that such a component should be part of the "Things and Resource Management GE". - "Things and Resources Management Architecture -User Portal": We think there should be a differentiation between the interface for registering the entities (which may be used by system components as well as user application components) and the way a user can interact with this. A Web Interface is just one option for user interaction. - "Things and Resources Management Architecture -Observation Handler" - again there is a reference to the Event Repository, which is not part of the architecture figure. Such a component should be part of data handling T5.3. As the "Observation Handler" deals with both T5.2 and T5.3 components, we think it fits better into the T5.4 Exposure GE -->see NEC's changed architecture proposal - "Things and Resources Management Architecture - Subscribing to creation/updates/deletion of Entities (Things or IoT Resources)" - I do not agree with the use of the term entity as a super type of things AND IoT Resources. IoT Resources are functional components that implement interfaces. These need to be properly described and matched. NGSI-9 only provides information about what entities and attributes can be provided, but not any values - so at most an insufficient amount of information about a resource can be encoded (e.g. as EntityType), which based on a subscription could lead to a huge amount of notifications (e.g. EntityType=temperature resource) and the Resource Description itself anyway would have to be requested in an additional step. Best regards, Martin ------------------------------------------ Dr. Martin Bauer Senior Researcher NEC Europe Ltd. NEC Laboratories Europe Software & Services Research Division Kurf?rsten-Anlage 36 D-69115 Heidelberg Tel: +49/ (0)6221/4342-168 Fax: +49/ (0)6221/4342-155 E-Mail: Martin.Bauer at neclab.eu http://www.nw.neclab.eu ************************************************************* NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 -------------- next part -------------- An HTML attachment was scrubbed... URL: From denes.bisztray at nsn.com Thu Feb 16 15:13:17 2012 From: denes.bisztray at nsn.com (Bisztray, Denes (NSN - HU/Budapest)) Date: Thu, 16 Feb 2012 15:13:17 +0100 Subject: [Fiware-iot] Arch Description Problems Message-ID: <3F4C11BC54A36642BFB5875D599F47BD058EFE0F@DEMUEXC013.nsn-intra.net> Dear All, There are some problems with the description of most of the GEs. 1st group: There is absolutely no change compared to my initial sketch: * FIWARE.ArchitectureDescription.IoT.Backend.ConnectivityManagement * FIWARE.ArchitectureDescription.IoT.Backend.ServiceControl * FIWARE.ArchitectureDescription.IoT.Backend.DeviceFrontend * FIWARE.ArchitectureDescription.IoT.Gateway.DataPooling * FIWARE.ArchitectureDescription.IoT.Gateway.DataAccessPolicy * FIWARE.ArchitectureDescription.IoT.Gateway.LocalStorage This is a LOT! As far as I understand, the Gateway GEs are Telecom Italia's and Ericssons' responsibility. The three Communication GEs on the backend should be also done by the IoT Communication Chapter, which also falls to Telecom Italia. 2nd group: Minimal description: - FIWARE.ArchitectureDescription.IoT.Gateway.Exposure - FIWARE.ArchitectureDescription.IoT.Gateway.ConnectivityManagement - FIWARE.ArchitectureDescription.IoT.Gateway.DeviceFrontend These GEs are described in a minimalistic manner. Also they hardy follow the template. The template is clear, Overview with possible architecture description. Basic Concepts and then Interactions. Most of these GEs mix these things up AND/OR does not describe elementary concepts that needed in order to understand the description (i.e. the SCL is not defined anywhere but used a lot), also there are no information model in most cases . 3rd group: Missing elements: - FIWARE.ArchitectureDescription.IoT.Gateway.DataHandling The Main Interactions section is completely missing. 3rd group: Missing GE. - Service Control GE from the Gateway. Although it was not in my initial FMC model, Gian Piero asked to have it in the Gateway. It is missing currently. Please, we have only half day before the deadline, and this is seriously a lot of work. For examples please have a look at these: - FIWARE.ArchitectureDescription.IoT.Backend.Exposure - FIWARE.ArchitectureDescription.IoT.Backend.ThingsAndResourcesManagement I'm sorry if I sound desperate, but 2 out of 12 GEs are finished in a reasonably good manner one day before the deadline. Please don't count on the WPA this time to fill the missing gaps. Best, D?nes -------------- next part -------------- An HTML attachment was scrubbed... URL: From gianpiero.fici at telecomitalia.it Thu Feb 16 18:37:11 2012 From: gianpiero.fici at telecomitalia.it (Fici Gian Piero) Date: Thu, 16 Feb 2012 18:37:11 +0100 Subject: [Fiware-iot] R: Arch Description Problems In-Reply-To: <3F4C11BC54A36642BFB5875D599F47BD058EFE0F@DEMUEXC013.nsn-intra.net> References: <3F4C11BC54A36642BFB5875D599F47BD058EFE0F@DEMUEXC013.nsn-intra.net> Message-ID: Hi Denes, here are our answers to your questions. 1st group (There is absolutely no change compared to my initial sketch) Gateway Data Pooling - just added to the wiki Gateway Data Access Policy - we understood that in the Architecture Description for tomorrow we should include just what we will have in the April 2012 release, and we agreed with Ericsson that it would be not realistic to include the Data Access Policy GE, so either we delete this entry from the list, or we write as a description that the GE will not be included in the April 2012 release (for the same reason we made some simplification in the other GE we described at gateway level) Gateway Local Storage - Ericsson is working on that Backend Connectivity Management Backend Service Control Backend Device Frontend - I know that TI is currently responsible for IoT Communication, but when we got the assignment to work on the Gateway with Ericsson we assumed that someone else would have dealt with the GEs at Backend level. Otherwise out of 11 GEs (13-2 that will not be included in the April release) we have to work on 6 of them, that is more than 50% of the work. It looks quite unfair. 2nd group (Minimal description) Gateway Exposure Gateway Connectivity Management Gateway Device Frontend - actually we started from Ricardo's Things and Resources Management GE description, that was indicated as a good example of the GE descriptions and in all these GEs description there is an overview, a list of basic concepts in the form of the interfaces included in the GE, an architecture of the GE in FMC with the description of the component, and the main interactions with a list of operations on the different interfaces. Following your comments I moved the short ETSI M2M description in the Gateway Exposure GE from the overview into the basic concepts section, I also get rid of the SCL references that were actually not described correctly. The information model is only included in the Connectivity Management GE (we are working on that), because it contains a store, the Connected Device List, while the other GEs does not have any store so we not included any information model. The descriptions are not really complex because we and Ericsson are really describing the content for the April release, so we simplified the components in these GEs in order to be realistic. 3rd group (Missing elements): Gateway Data Handling - By the way there is the Gateway Data Handling GE that was described but we do not know who is the author of this description. It looks like this is a long term description and does not much an April release in our opinion (TI and Ericsson). Maybe we need to talk about this with the author of the description (engaging him in the actual discussion between us and Ericsson) in order to have an agreed view at gateway level. Gateway Service Control - :) Yes, I actually asked to add the Service Control at gateway level for the symmetry of the system, but that was for the long term architectural view, not for the April release, so I added it to the list in the wiki, but it is one of those GEs that will not be included in the April release and we have to decide if leaving them with a note, or delete them. In conclusion, we have 5 GEs available on the gateway (Exposure, Data Pooling, Local Storage, Connectivity Management, and Device Frontend), there is one that is not harmonized with the others (Data Handling), and there are 2 that will not be included in the April 2012 release so are not described (Data Access Policy, and Service Control). I took care to introduce some modifications to some GEs descriptions following your comments and I tried to explain the reasoning behind these descriptions. Please let me know if you have any other comment or you disagree on my positions. About the Backend the situation is more complex since I really do not know how we could complete the work at platform level too. Best regards, Gian Piero Da: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] Per conto di Bisztray, Denes (NSN - HU/Budapest) Inviato: gioved? 16 febbraio 2012 15:13 A: fiware-iot at lists.fi-ware.eu Oggetto: [Fiware-iot] Arch Description Problems Dear All, There are some problems with the description of most of the GEs. 1st group: There is absolutely no change compared to my initial sketch: * FIWARE.ArchitectureDescription.IoT.Backend.ConnectivityManagement * FIWARE.ArchitectureDescription.IoT.Backend.ServiceControl * FIWARE.ArchitectureDescription.IoT.Backend.DeviceFrontend * FIWARE.ArchitectureDescription.IoT.Gateway.DataPooling * FIWARE.ArchitectureDescription.IoT.Gateway.DataAccessPolicy * FIWARE.ArchitectureDescription.IoT.Gateway.LocalStorage This is a LOT! As far as I understand, the Gateway GEs are Telecom Italia's and Ericssons' responsibility. The three Communication GEs on the backend should be also done by the IoT Communication Chapter, which also falls to Telecom Italia. 2nd group: Minimal description: - FIWARE.ArchitectureDescription.IoT.Gateway.Exposure - FIWARE.ArchitectureDescription.IoT.Gateway.ConnectivityManagement - FIWARE.ArchitectureDescription.IoT.Gateway.DeviceFrontend These GEs are described in a minimalistic manner. Also they hardy follow the template. The template is clear, Overview with possible architecture description. Basic Concepts and then Interactions. Most of these GEs mix these things up AND/OR does not describe elementary concepts that needed in order to understand the description (i.e. the SCL is not defined anywhere but used a lot), also there are no information model in most cases . 3rd group: Missing elements: - FIWARE.ArchitectureDescription.IoT.Gateway.DataHandling The Main Interactions section is completely missing. 3rd group: Missing GE. - Service Control GE from the Gateway. Although it was not in my initial FMC model, Gian Piero asked to have it in the Gateway. It is missing currently. Please, we have only half day before the deadline, and this is seriously a lot of work. For examples please have a look at these: - FIWARE.ArchitectureDescription.IoT.Backend.Exposure - FIWARE.ArchitectureDescription.IoT.Backend.ThingsAndResourcesManagement I'm sorry if I sound desperate, but 2 out of 12 GEs are finished in a reasonably good manner one day before the deadline. Please don't count on the WPA this time to fill the missing gaps. Best, D?nes Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:00000000000000000000000000000001 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia.jpg URL: From denes.bisztray at nsn.com Fri Feb 17 07:24:19 2012 From: denes.bisztray at nsn.com (Bisztray, Denes (NSN - HU/Budapest)) Date: Fri, 17 Feb 2012 07:24:19 +0100 Subject: [Fiware-iot] Arch Description Problems In-Reply-To: References: <3F4C11BC54A36642BFB5875D599F47BD058EFE0F@DEMUEXC013.nsn-intra.net> Message-ID: <3F4C11BC54A36642BFB5875D599F47BD058EFFF1@DEMUEXC013.nsn-intra.net> Hi Gian Piero, I'll look after the Backend communication GEs. Best, D?nes From: ext Fici Gian Piero [mailto:gianpiero.fici at telecomitalia.it] Sent: Thursday, February 16, 2012 6:37 PM To: Bisztray, Denes (NSN - HU/Budapest); fiware-iot at lists.fi-ware.eu Subject: R: Arch Description Problems Hi Denes, here are our answers to your questions. 1st group (There is absolutely no change compared to my initial sketch) Gateway Data Pooling - just added to the wiki Gateway Data Access Policy - we understood that in the Architecture Description for tomorrow we should include just what we will have in the April 2012 release, and we agreed with Ericsson that it would be not realistic to include the Data Access Policy GE, so either we delete this entry from the list, or we write as a description that the GE will not be included in the April 2012 release (for the same reason we made some simplification in the other GE we described at gateway level) Gateway Local Storage - Ericsson is working on that Backend Connectivity Management Backend Service Control Backend Device Frontend - I know that TI is currently responsible for IoT Communication, but when we got the assignment to work on the Gateway with Ericsson we assumed that someone else would have dealt with the GEs at Backend level. Otherwise out of 11 GEs (13-2 that will not be included in the April release) we have to work on 6 of them, that is more than 50% of the work. It looks quite unfair. 2nd group (Minimal description) Gateway Exposure Gateway Connectivity Management Gateway Device Frontend - actually we started from Ricardo's Things and Resources Management GE description, that was indicated as a good example of the GE descriptions and in all these GEs description there is an overview, a list of basic concepts in the form of the interfaces included in the GE, an architecture of the GE in FMC with the description of the component, and the main interactions with a list of operations on the different interfaces. Following your comments I moved the short ETSI M2M description in the Gateway Exposure GE from the overview into the basic concepts section, I also get rid of the SCL references that were actually not described correctly. The information model is only included in the Connectivity Management GE (we are working on that), because it contains a store, the Connected Device List, while the other GEs does not have any store so we not included any information model. The descriptions are not really complex because we and Ericsson are really describing the content for the April release, so we simplified the components in these GEs in order to be realistic. 3rd group (Missing elements): Gateway Data Handling - By the way there is the Gateway Data Handling GE that was described but we do not know who is the author of this description. It looks like this is a long term description and does not much an April release in our opinion (TI and Ericsson). Maybe we need to talk about this with the author of the description (engaging him in the actual discussion between us and Ericsson) in order to have an agreed view at gateway level. Gateway Service Control - J Yes, I actually asked to add the Service Control at gateway level for the symmetry of the system, but that was for the long term architectural view, not for the April release, so I added it to the list in the wiki, but it is one of those GEs that will not be included in the April release and we have to decide if leaving them with a note, or delete them. In conclusion, we have 5 GEs available on the gateway (Exposure, Data Pooling, Local Storage, Connectivity Management, and Device Frontend), there is one that is not harmonized with the others (Data Handling), and there are 2 that will not be included in the April 2012 release so are not described (Data Access Policy, and Service Control). I took care to introduce some modifications to some GEs descriptions following your comments and I tried to explain the reasoning behind these descriptions. Please let me know if you have any other comment or you disagree on my positions. About the Backend the situation is more complex since I really do not know how we could complete the work at platform level too. Best regards, Gian Piero Da: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] Per conto di Bisztray, Denes (NSN - HU/Budapest) Inviato: gioved? 16 febbraio 2012 15:13 A: fiware-iot at lists.fi-ware.eu Oggetto: [Fiware-iot] Arch Description Problems Dear All, There are some problems with the description of most of the GEs. 1st group: There is absolutely no change compared to my initial sketch: ? FIWARE.ArchitectureDescription.IoT.Backend.ConnectivityManagement ? FIWARE.ArchitectureDescription.IoT.Backend.ServiceControl ? FIWARE.ArchitectureDescription.IoT.Backend.DeviceFrontend ? FIWARE.ArchitectureDescription.IoT.Gateway.DataPooling ? FIWARE.ArchitectureDescription.IoT.Gateway.DataAccessPolicy ? FIWARE.ArchitectureDescription.IoT.Gateway.LocalStorage This is a LOT! As far as I understand, the Gateway GEs are Telecom Italia's and Ericssons' responsibility. The three Communication GEs on the backend should be also done by the IoT Communication Chapter, which also falls to Telecom Italia. 2nd group: Minimal description: - FIWARE.ArchitectureDescription.IoT.Gateway.Exposure - FIWARE.ArchitectureDescription.IoT.Gateway.ConnectivityManagement - FIWARE.ArchitectureDescription.IoT.Gateway.DeviceFrontend These GEs are described in a minimalistic manner. Also they hardy follow the template. The template is clear, Overview with possible architecture description. Basic Concepts and then Interactions. Most of these GEs mix these things up AND/OR does not describe elementary concepts that needed in order to understand the description (i.e. the SCL is not defined anywhere but used a lot), also there are no information model in most cases . 3rd group: Missing elements: - FIWARE.ArchitectureDescription.IoT.Gateway.DataHandling The Main Interactions section is completely missing. 3rd group: Missing GE. - Service Control GE from the Gateway. Although it was not in my initial FMC model, Gian Piero asked to have it in the Gateway. It is missing currently. Please, we have only half day before the deadline, and this is seriously a lot of work. For examples please have a look at these: - FIWARE.ArchitectureDescription.IoT.Backend.Exposure - FIWARE.ArchitectureDescription.IoT.Backend.ThingsAndResourcesManagement I'm sorry if I sound desperate, but 2 out of 12 GEs are finished in a reasonably good manner one day before the deadline. Please don't count on the WPA this time to fill the missing gaps. Best, D?nes Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 677 bytes Desc: image001.gif URL: From sabrina.guerra at telecomitalia.it Fri Feb 17 09:44:29 2012 From: sabrina.guerra at telecomitalia.it (Guerra Sabrina) Date: Fri, 17 Feb 2012 09:44:29 +0100 Subject: [Fiware-iot] out of office next week In-Reply-To: <36A93B31228D3B49B691AD31652BCAE9A594A2985A@GRFMBX702BA020.griffon.local> References: <93D28BDF64839C468B848D14227151A202B19448@FIESEXC014.nsn-intra.net> <36A93B31228D3B49B691AD31652BCAE9A564BA61D3@GRFMBX702BA020.griffon.local> <36A93B31228D3B49B691AD31652BCAE9A594A2985A@GRFMBX702BA020.griffon.local> Message-ID: <36A93B31228D3B49B691AD31652BCAE9A596D80155@GRFMBX702BA020.griffon.local> Hi all, the next week I will be on holiday. Best regards, Sabrina Guerra __________________________________ Telecom Italia S.p.a. Strategia e Innovazione, Research & Trends Telefono +39 011 228 8359 Cellulare +39 331 600 1349 ________________________________ Da: Guerra Sabrina Inviato: Thursday, December 29, 2011 12:57 PM A: 'Farkas, Lorant (NSN - HU/Budapest)'; 'Bisztray, Denes (NSN - HU/Budapest)' Cc: Fici Gian Piero Oggetto: R: IoT weekly meeting Hi all, The first week of January I and Gian Piero will be on holiday, so if there will be a conference call on Wednesday unfortunately we will not be able to participate. Best regards, Sabrina Sabrina Guerra __________________________________ Telecom Italia S.p.a. Strategia e Innovazione, Research & Trends Telefono +39 011 228 8359 Cellulare +39 331 600 1349 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:00000000000000000000000000000001 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia.jpg URL: From jhierro at tid.es Fri Feb 17 14:26:05 2012 From: jhierro at tid.es (Juanjo Hierro) Date: Fri, 17 Feb 2012 14:26:05 +0100 Subject: [Fiware-iot] About Exposure GE in IoT Chapter Message-ID: <4F3E556D.3030306@tid.es> Hi all, I just want to anticipate to you that I see several issues in the description of the Exposure GE. I will sent you a detailed analysis later this evening or tomorrow. Unfortunately, I cannot do it earlier. Best regards, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Chief Architect You can follow FI-WARE at: website: http://www.fi-ware.eu facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 twitter: http://twitter.com/FIware linkedIn: http://www.linkedin.com/groups/FIWARE-4239932 Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx From denes.bisztray at nsn.com Fri Feb 17 16:01:25 2012 From: denes.bisztray at nsn.com (Bisztray, Denes (NSN - HU/Budapest)) Date: Fri, 17 Feb 2012 16:01:25 +0100 Subject: [Fiware-iot] ETSI M2M RESTful binding for the mId Message-ID: <3F4C11BC54A36642BFB5875D599F47BD058F0501@DEMUEXC013.nsn-intra.net> Dear all, I just created a proposal for the RESTful binding on the mId interface with the minimal set of resources that we should implement for the April release. It is uploaded to the IoT SVM under this link: https://forge.fi-ware.eu/scmrepos/svn/iot/trunk/documents/FIWARE-ETSI-M2M-RESTful-binding.docx Also if someone does not have the access right, I attached to this email. Best, D?nes -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FIWARE-ETSI-M2M-RESTful-binding.docx Type: application/octet-stream Size: 37015 bytes Desc: FIWARE-ETSI-M2M-RESTful-binding.docx URL: From jhierro at tid.es Mon Feb 20 08:45:56 2012 From: jhierro at tid.es (Juanjo Hierro) Date: Mon, 20 Feb 2012 08:45:56 +0100 Subject: [Fiware-iot] Comments on Exposure GE in IoT Chapter In-Reply-To: <4F3E556D.3030306@tid.es> References: <4F3E556D.3030306@tid.es> Message-ID: <4F41FA34.6030607@tid.es> Hi all, Please find below my comments on the Exposure GE. === (note 1: whenever I use the term "FI-WARE NGSI" I refer to the spec based on OMA NGSI we are going to support in FI-WARE which may differ from the OMA spec for good documented reasons. We will intend to fast-track the adoption of changes into OMA to generate an update of those specs that finally aligns with FI-WARE NGSI specs. "OMA NGSI" will be used to refer to the NGSI interface as currently specified in OMA. Whenever I use the term NGSI, without qualifying it, it is because it is in a statement that would apply both to OMA NGSI and FI-WARE NGSI. Note that a clarification like this should be introduced in the Architecture Description.) (note 2: In the FI-WARE Product Vision we introduced the term "IoT resource" an used it with preference to "device" which could mean many things and may lead to misinterpretation ... However, the current IoT Service Enablement Chapter Architecture uses the term "device" prominently ... Below, I use the term "IoT resource" rather than "device".) There is no need to define two cascade layers of the FI-WARE NGSI-10 interface, one exported by the "Thing-level API" part of the "exposure GE" and another one exported by the "Publish/Subscribe Broker GE" (no matter whether the reference implementation of this last GE is provided by Telecom Italia or not), making both "cascading layers" visible to applications. As far as I understand, NEC argued that such "cascading" would be necessary mostly because the OMA specifications didn't consider the possibility that the (Publish/Subscribe) broker exporting a OMA NGSI-10 interface implements the "query" operation so that it can, in turn, invoque a query, on a context producer. NEC pointed out this might be an issue in scenarios where it is more sensible to query IoT resources at device level instead of letting them be constantly notifying observations. However, the fact that such operation is not considered in OMA NGSI-10 specs may be consider a major usability gap of OMA specs and we don't need to feel constrained (trying to find an artificial workaround) whenever we face a gap in the specs as we have mentioned several times. We may simply decide that the FI-WARE NGSI-10 specification will include a "query" operation that a Publish/Subscribe Broker can invoke on Context Producers, provided such Context Producers have registered as exporting such operation. Interestingly enough, I have found out that Telecom Italia's implementation of NGSI includes this extension, probably because real-life applications have proven to request this (I guess for scenarios similar to those described by NEC when it raised the issue). On the other hand, as already explained a couple of times, there is no need to wrap access to the Things/Resource Configuration Management GE in order to provide the FI-WARE NGSI-9 interface. It can expose this directly to applications. This would be because entities handled at FI-WARE NGSI level may be either Things or IoT resources (at device-level). You may discover the existence of an entity that refers to an IoT resource and then deal directly with the interface exported by that IoT resource using the ETSI M2M API. Is anything wrong there ? Based on the comments above, a figure that may describe a target reference architecture for the backend may look as shown below. I have renamed the "Exposure GE" as "ETSI M2M Handler" because it wouldn't deal with exposing the NGSI APIs but indeed it would act as a bridge between the NGSI and M2M worlds (besides supporting Process Handling which probably would require further discussion). Indeed, I would be in favour of splitting the GE into two, so that the "Observation Handler", "Request Handler", "Process Handler" and "Semantic Handler" components are on one side, being part of the "ETSI M2M Handler GE", and the "Device-level API" component goes apart so that, together with the "Service Control GE" and the "Device Control GE", become a GE dealing with implementation of the ETSI M2M API. Note that the channel in red represents the "query" request that is missing in the OMA NGSI-10 spec and we should include in FI-WARE NGSI-10 specs [cid:part1.00030207.03000807 at tid.es] Besides the above, I believe that a component dealing with self-registration of IoT resources may be required (I'm not sure if the ETSI M2M model supports that). Such component would deal with reception of messages from lower layers (IoT gateway or IoT resources at device-level) using ETSI M2M APIs linked to registration of IoT resources. ==== Best regards, -- Juanjo On 17/02/12 14:26, Juanjo Hierro wrote: Hi all, I just want to anticipate to you that I see several issues in the description of the Exposure GE. I will sent you a detailed analysis later this evening or tomorrow. Unfortunately, I cannot do it earlier. Best regards, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Chief Architect You can follow FI-WARE at: website: http://www.fi-ware.eu facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 twitter: http://twitter.com/FIware linkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hfcibjgg.png Type: image/png Size: 133941 bytes Desc: not available URL: From denes.bisztray at nsn.com Mon Feb 20 10:45:07 2012 From: denes.bisztray at nsn.com (Bisztray, Denes (NSN - HU/Budapest)) Date: Mon, 20 Feb 2012 10:45:07 +0100 Subject: [Fiware-iot] Discontinuous connectivity Message-ID: <3F4C11BC54A36642BFB5875D599F47BD058F088F@DEMUEXC013.nsn-intra.net> Dear All, Reviewing the architecture, I found a little inconsistency with the management of disconnected device. There are two points that needs further refinement. 1. Workflow of commands from the northbound Currently there are two versions in this topic. Telecom Italia version: - The device command from the exposure GE is forwarded to the discontinuous connectivity management GE, if the device is online then the discontinuous connectivity GE forwards it to the abstract protocol layer on the southbound. NSN and NEC version - The exposure GE probes the discontinuous connectivity GE if the device is online or not. If it is, then it sends the command directly to the abstract protocol layer. In case the device is offline, then goes to the discontinuous connectivity GE, which stores it in the connectivity cache. I would be good we could resolve this issue as soon as possible. In the TI version the discontinuous connectivity GE suffers from a higher load as all commands goes through it, also the checkConnection function becomes reasonably unnecessary as all commands directly goes to the discontinuous connectivity management GE which does an internal check. 2. Device goes offline or becomes online again. Although it is not explicitely stated, I assume it is the abstract protocol layer is responsible for noticing that a device disappeared or reapperad again. In the simple setup, I assume it notifies the discontinuous connectivity management GE that a device is appeared again. However this is not written down anywhere. In fact the whole device-level resource management GE is missing on the gateway. I understand that currently the mobility management component is not implemented, and since we don't have thing-level management, this is not an extremely important component. Still, it would be nice to take a note about the component. Best, D?nes -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhierro at tid.es Mon Feb 20 13:02:00 2012 From: jhierro at tid.es (Juanjo Hierro) Date: Mon, 20 Feb 2012 13:02:00 +0100 Subject: [Fiware-iot] Comment on IoT Architecture Description Message-ID: <4F423638.406@tid.es> Hi all, Please find my comments to the IoT chapter. I have found some major issues to resolve prior going public. And they are not just "formal". * We have to fix the issues I have already mentioned regarding the "Exposure GE" * There is a missmatch on interpretation about the meaning of the NGSI-9 interface in different parts of the Architecture. I will elaborate on this matter in a separate email I will send to the NGSI mailing list. We have to fix it. * It is unclear to me why we should have a common "Service Execution Layer" wrapping access to southbound APIs (see detailed comments below). Below, the detailed comments: ==== (note: whenever I use the term "FI-WARE NGSI" I refer to the spec based on OMA NGSI we are going to support in FI-WARE which may differ from the OMA spec for good documented reasons. We will intend to fast-track the adoption of changes into OMA to generate an update of those specs that finally aligns with FI-WARE NGSI specs. "OMA NGSI" will be used to refer to the NGSI interface as currently specified in OMA. Whenever I use the term NGSI, without qualifying it, it is because it is in a statement that would apply both to OMA NGSI and FI-WARE NGSI. Note that a clarification like this should be introduced in the Architecture Description.) 1. Major comments 1.1 Chapter overall description * In the FI-WARE Product Vision we introduced the term "IoT resource" an used it with preference to "device" which could mean many things and may lead to misinterpretation ... Why aren't we here consistent with that and use "IoT resource" rather than "device" ? * Saying "It has two northbound APIs: a device level and a thing-level" when talking about the IoT Backend is not accurate. The FI-WARE NGSI interfaces will allow to get events (as context element data structures) generated from IoT resources (i.e., device-level). Note that both things and "IoT resources" will be represented as entities in NGSI. I would say something like "it supports access at both device and thing-level" (or "it supports access at both IoT resource and thing-level" if we consider the previous comment). 1.2 Exposure GE architecture Please check mail on "Comments on Exposure GE in IoT Chapter" for the most relevant comments, content-wise, for this section. These comments should be tackled in the first place. The Main Interaction section doesn't strictly follow the reference example provided in the guidelines. Reference to name of interfaces and operations in the descriptions are missing. UML sequence diagrams would be helpful as well. Change OMA NGSI to FI-WARE NGSI where appropriate. 1.3 Things/Resource Configuration Management GE Again, as described above, we should use the term "IoT resource" to be consistent with the terms and definitions we introduced in the FI-WARE Product Vision (otherwise, review it). Sometimes the text may lead to misinterpretation. Entities, as defined in FI-WARE NGSI may represent either Things or IoT resources. Sometimes the text is clear about that, but sometimes it is not. As an example, it is said "using the NGSI-9 interface exported by the "Things/Resource Configuration Management" component, applications are able to register and discover Things in the system" ... when the fact is that using the NGSI-9 interface they would be able to register IoT resources too. Please review it. The repository of events does not need to be a part of this GE. I believe it should be assumed that storage of events would be handled by the Publish/Subscribe Broker GE. Some of the descriptions of Main Interactions should be revised. English writing should be polished. We should refer to names of operations in the NGSI-9 interface whenever possible while describing Main Interactions (for example, interaction regarding registering of Things, IoT resources and associations. Regarding interaction with GEs related to Data Handling, the described interaction is only in push mode (the Observation Handler receives an event from lower layers) while we should also cover the pull mode (the Request Handler receives a query request from the Publish/Subscribe Broker GE and handles it issuing a request to the lower layers, see comments on Exposure GE). Change OMA NGSI to FI-WARE NGSI where appropriate. 1.4 Device FrontEnd GE Probably some of the contents need to reviewed at the light of comments to the Exposure GE. Again, I would recommend using "IoT resource" rather than "Resource" ... There is a missmatch about the interpretation about semantics of NGSI-9 interfaces here and in the Things/Resource Configuration Management GE. This should be fixed prior to publication. Description of main interactions do not follow the reference example provided in the guidelines. 1.5 Service Control GE We should at least provide a high-level description (one paragraph) of this GE. We currently just say that it won't be supported in the first release of FI-WARE ... 1.5 Connectivity Management GE The relationship with the ETSI M2M APIs or the southbound NGSI APIs is not clear ... Are the operations listed in "Main interaction" just wrappers of ETSI M2M operations which support "cache" of requests/responses data in case of lack of connectivity ? If so, ... how does connectivity management work together with NGSI interfaces when used southbound ? The section on "Main Interactions" do not follow the reference example provided in the guidelines. Actually, it would be rather helpful to elaborate on interactions describing how this Connectivity Management GE would intermediate messages exchanged with lower layers either through the ETSI M2M interface or through NGSI interfaces (I assume, based on the high-level picture provided for the whole chapter, that interaction between backend and gateway may be based on any of the two interfaces). Illustrating the description with some UML sequence diagrams would definitively help. 1.6 Device Front-End GE (Backend side) It's not clear what is the role of the "Service Execution Layer" component ... Is it intending to be some sort of common wrapper for both NGSI and ETSI M2M APIs ? If so, I would think it twice prior defining it as part of the architecture ... I would be much more in favor of describing that the "Observation Handler" or "Request Handler", for instance, would make usage of southbound ETSI M2M APIs or NGSI APIs ... 1.7 Local Storage GE (gateway) GEs are, by nature, replaceble ... Do we intend to make this element replaceble ? One thing is that the Publish/Subscribe Broker GE running on a gateway, for example, obviously needs to rely on a local storage repository and another thing is that such component would be replaceble ? I would go for dropping it and mention local storage capacities when required. 1.8 Data Access Policy GE The Architecture Description for this GE is too short. It is not described how it would interact with other GEs or the description lacks of the necessary details ... Why isn't this GE also present in the Backend ? 2. Minor comments (some editorial): 2.1 Chapter overall description * I would not use the term "component" when referring to the full backend, IoT gateway Device parts of the Architecture ... "Layers" ? (not sure this one is best) * "Devices can further be categorized into IoT compliant" ... I would say "Devices can further be categorized into ETSI M2M compliant" ... stating that "IoT complaint" equeals to "supporting the ETSI M2M model and APIs" is way too much * For the same reason when (at Backend description) we say: "The backend can be connected southbound to IoT compliant devices" we should say "... to ETSI M2M compliant devices" * When talking about Gateways we state: "taking into consideration the local constraints of devices" ... to avoid confusion with the devices the IoT gateway is interfacing to I would say "taking into consideration the local constraints of gateway devices" * In Exposure GE Architecture Description: I would suggest renaming "Northbound interfaces" in "Main Interactions" as "Northbound Interactions", in line with the other section within "Main Interactions" ==== Best regards, -- Juanjo Hierro ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Chief Architect You can follow FI-WARE at: website: http://www.fi-ware.eu facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 twitter: http://twitter.com/FIware linkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From wafa.soubra at orange.com Mon Feb 20 17:04:31 2012 From: wafa.soubra at orange.com (wafa.soubra at orange.com) Date: Mon, 20 Feb 2012 17:04:31 +0100 Subject: [Fiware-iot] ETSI M2M RESTful binding for the mId In-Reply-To: <3F4C11BC54A36642BFB5875D599F47BD058F0501@DEMUEXC013.nsn-intra.net> References: <3F4C11BC54A36642BFB5875D599F47BD058F0501@DEMUEXC013.nsn-intra.net> Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620233C7EC@ftrdmel0.rd.francetelecom.fr> Hello everyone, Thank you Denes for your document. As far as I understand, this proposed subset of the API should be implemented for the first release of FIWARE in April 2012. Therefore, I have questions about some points if you could clarify that for me : - To be compliant with the ETSI M2M, we 'll have 2 kind of devices in FIWARE : either the device has its own SCL (i.e it contains the depicted resource structure) and that means that the device will use the mld interface to communicate with the centralized backend; or the device doesn't contain an SCL, and in that case cannot use the mld interface and must communicate with its gateway via the dIa interface. Is that what you mean in your introduction ? - Could we keep the same notation as in the ETSI M2M Release 1 ? I think it will be easier and more homogeneous for the mapping ( instead of {container}, keep the name of the primitive "containersRetrieveRequestIndication" to GET the list of child containers, ...) - The mld interface is between 2 SCL (device <--> backend or gateway <--> backend): some arguments are missing from the input message like targetID, PrimitiveType which are mandatory. Any reasons for that ? - In the Data Structure of a Container, the "searchStrings" and "announceTo" attributes are missing. Why? - Just to be sure of my understanding, implementing this subset in the architecture that would amount to implement it in the Device, in the Gateway (IOT API) and in the Backend (Device Level API)? Thanks in advance for your answers. If you'd like, I can also update the document. Did you get the XSD files for the ETSI M2M? Best Regards, Wafa. De : Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com] Envoy? : vendredi 17 f?vrier 2012 16:01 ? : fiware-etsim2m at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Cc : NAGELLEN Thierry RD-BIZZ-SOP; SOUBRA Wafa RD-BIZZ-SOP Objet : ETSI M2M RESTful binding for the mId Dear all, I just created a proposal for the RESTful binding on the mId interface with the minimal set of resources that we should implement for the April release. It is uploaded to the IoT SVM under this link: https://forge.fi-ware.eu/scmrepos/svn/iot/trunk/documents/FIWARE-ETSI-M2M-RESTful-binding.docx Also if someone does not have the access right, I attached to this email. Best, D?nes -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tobias.Jacobs at neclab.eu Mon Feb 20 17:40:32 2012 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Mon, 20 Feb 2012 16:40:32 +0000 Subject: [Fiware-iot] Comments on Exposure GE in IoT Chapter In-Reply-To: <4F41FA34.6030607@tid.es> References: <4F3E556D.3030306@tid.es> <4F41FA34.6030607@tid.es> Message-ID: <8755F290097BD941865DC4245B335D2D08BA8D8E@DAPHNIS.office.hd> Dear Juanjo, all, Please find our answer to your comments on the Exposure GE below. 1) Our concerns about the role of the Pub/Sub Broker are purely architectural and have nothing to do with the NGSI interfaces. The interface issues are a separate discussion. The following points are independent from what NGSI does support and what not. 2) The IoT Chapter agreed that IoT GEs exposes a number of different interfaces, including information access on thing and resource level, actuation and processing interfaces (for integration into business processes, SAP). The discussion here focuses on the Thing-level information interface to applications, and the proposal by TID is to use the pub/sub broker GE as this Thing-level interface. However, based on the specification of the pub/sub broker GE we are convinced that it is not suitable for that role. The reasons are as follows. 2a) As the production of context information can be expensive, IoT systems should be silent when there are no requests from applications, and not constantly produce data. The pub/sub-broker, however, is not able to pass subscriptions of applications down to IoT resources, so it cannot handle subscriptions unless all context information is constantly published into it. Alternatively, the pub/sub-broker has to poll the IoT resources, which leads to efficiency problems. 2b) The pub/sub broker GE requires that all entities existing in the IoT system are registered in the pub/sub broker, if the pub/sub broker should be able to query for the respective information. This effectuates a duplication of all information, because the entities are already registered in the Things and Resources Management GE. Plus it means that all changes to the set of entities need to be propagated to the Pub/Sub broker. Respective IoT research projects have tried to avoid centralizing this information and keep changes in the entity sets as local as possible, e.g. through distributed repositories and queries. 2c) The IoT GE information access interface defines sophisticated usage of NSGI-type scopes (e.g. for limiting queries to certain geographic areas or to certain subsystems). This seems not be part of the Pub/Sub GE. 3) We agree that the IoT chapter should have a single thing-level interface exposed towards applications, but for the reasons mentioned above this interface is functionally (!) NOT identical to the pub/sub broker interface. Please be aware the syntactical similar interfaces can have very different functionalities implemented with it. Our argumentation is about functionalities and not syntax. We therefore propose to use a dedicated "thing-level interface" as it can be seen in our architecture proposal from last week. Additionally putting a pub/sub broker GE on top of this "thing-level interface" might be a compromise. This GE would be an application from the IoT point of view. Best regards Ernoe, Martin, Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Juanjo Hierro Sent: Montag, 20. Februar 2012 08:46 To: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] Comments on Exposure GE in IoT Chapter Hi all, Please find below my comments on the Exposure GE. === (note 1: whenever I use the term "FI-WARE NGSI" I refer to the spec based on OMA NGSI we are going to support in FI-WARE which may differ from the OMA spec for good documented reasons. We will intend to fast-track the adoption of changes into OMA to generate an update of those specs that finally aligns with FI-WARE NGSI specs. "OMA NGSI" will be used to refer to the NGSI interface as currently specified in OMA. Whenever I use the term NGSI, without qualifying it, it is because it is in a statement that would apply both to OMA NGSI and FI-WARE NGSI. Note that a clarification like this should be introduced in the Architecture Description.) (note 2: In the FI-WARE Product Vision we introduced the term "IoT resource" an used it with preference to "device" which could mean many things and may lead to misinterpretation ... However, the current IoT Service Enablement Chapter Architecture uses the term "device" prominently ... Below, I use the term "IoT resource" rather than "device".) There is no need to define two cascade layers of the FI-WARE NGSI-10 interface, one exported by the "Thing-level API" part of the "exposure GE" and another one exported by the "Publish/Subscribe Broker GE" (no matter whether the reference implementation of this last GE is provided by Telecom Italia or not), making both "cascading layers" visible to applications. As far as I understand, NEC argued that such "cascading" would be necessary mostly because the OMA specifications didn't consider the possibility that the (Publish/Subscribe) broker exporting a OMA NGSI-10 interface implements the "query" operation so that it can, in turn, invoque a query, on a context producer. NEC pointed out this might be an issue in scenarios where it is more sensible to query IoT resources at device level instead of letting them be constantly notifying observations. However, the fact that such operation is not considered in OMA NGSI-10 specs may be consider a major usability gap of OMA specs and we don't need to feel constrained (trying to find an artificial workaround) whenever we face a gap in the specs as we have mentioned several times. We may simply decide that the FI-WARE NGSI-10 specification will include a "query" operation that a Publish/Subscribe Broker can invoke on Context Producers, provided such Context Producers have registered as exporting such operation. Interestingly enough, I have found out that Telecom Italia's implementation of NGSI includes this extension, probably because real-life applications have proven to request this (I guess for scenarios similar to those described by NEC when it raised the issue). On the other hand, as already explained a couple of times, there is no need to wrap access to the Things/Resource Configuration Management GE in order to provide the FI-WARE NGSI-9 interface. It can expose this directly to applications. This would be because entities handled at FI-WARE NGSI level may be either Things or IoT resources (at device-level). You may discover the existence of an entity that refers to an IoT resource and then deal directly with the interface exported by that IoT resource using the ETSI M2M API. Is anything wrong there ? Based on the comments above, a figure that may describe a target reference architecture for the backend may look as shown below. I have renamed the "Exposure GE" as "ETSI M2M Handler" because it wouldn't deal with exposing the NGSI APIs but indeed it would act as a bridge between the NGSI and M2M worlds (besides supporting Process Handling which probably would require further discussion). Indeed, I would be in favour of splitting the GE into two, so that the "Observation Handler", "Request Handler", "Process Handler" and "Semantic Handler" components are on one side, being part of the "ETSI M2M Handler GE", and the "Device-level API" component goes apart so that, together with the "Service Control GE" and the "Device Control GE", become a GE dealing with implementation of the ETSI M2M API. Note that the channel in red represents the "query" request that is missing in the OMA NGSI-10 spec and we should include in FI-WARE NGSI-10 specs [cid:image001.png at 01CCEFF6.5770DF30] Besides the above, I believe that a component dealing with self-registration of IoT resources may be required (I'm not sure if the ETSI M2M model supports that). Such component would deal with reception of messages from lower layers (IoT gateway or IoT resources at device-level) using ETSI M2M APIs linked to registration of IoT resources. ==== Best regards, -- Juanjo On 17/02/12 14:26, Juanjo Hierro wrote: Hi all, I just want to anticipate to you that I see several issues in the description of the Exposure GE. I will sent you a detailed analysis later this evening or tomorrow. Unfortunately, I cannot do it earlier. Best regards, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Chief Architect You can follow FI-WARE at: website: http://www.fi-ware.eu facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 twitter: http://twitter.com/FIware linkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 133941 bytes Desc: image001.png URL: From denes.bisztray at nsn.com Tue Feb 21 08:13:05 2012 From: denes.bisztray at nsn.com (Bisztray, Denes (NSN - HU/Budapest)) Date: Tue, 21 Feb 2012 08:13:05 +0100 Subject: [Fiware-iot] ETSI M2M RESTful binding for the mId In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C4620233C7EC@ftrdmel0.rd.francetelecom.fr> References: <3F4C11BC54A36642BFB5875D599F47BD058F0501@DEMUEXC013.nsn-intra.net> <843DA8228A1BA74CA31FB4E111A5C4620233C7EC@ftrdmel0.rd.francetelecom.fr> Message-ID: <3F4C11BC54A36642BFB5875D599F47BD0592D92D@DEMUEXC013.nsn-intra.net> Hi Wafa, Please find my answers inline. - To be compliant with the ETSI M2M, we 'll have 2 kind of devices in FIWARE : either the device has its own SCL (i.e it contains the depicted resource structure) and that means that the device will use the mld interface to communicate with the centralized backend; or the device doesn't contain an SCL, and in that case cannot use the mld interface and must communicate with its gateway via the dIa interface. Is that what you mean in your introduction ? I want to introduce a resource structure and set of interactions based on the ETSI M2M standard that can be exposed by and ETSI M2M compliant device. I'm a bit skeptic with the concept of SCL in ETSI M2M. It turned out that the service capabilities are just ideas that are not connected to the actual resource structure. I'm also a bit puzzled by the difference between device-gateway mId and device-gateway dIa. What is the exact difference there? What difference does the SCL make there? - Could we keep the same notation as in the ETSI M2M Release 1 ? I think it will be easier and more homogeneous for the mapping ( instead of {container}, keep the name of the primitive "containersRetrieveRequestIndication" to GET the list of child containers, ...) The notation of can be used I agree, I just wanted to use the same notation as the NGSI-10. The primitive name was omitted indeed, I found no reason to include it, however it can be done. I'll do it possibly today. - The mld interface is between 2 SCL (device <--> backend or gateway <--> backend): some arguments are missing from the input message like targetID, PrimitiveType which are mandatory. Any reasons for that ? There is a supplementary document called Annex C: HTTP Mapping. It states that the HTTP URI should be derived from the targetID attribute, ie. the targetID is basically the URI, thus I omitted it. The primitivetype is omitted with the same justification: the HTTP method makes it clear what we want to do with the resource, so the field is not necessary. - In the Data Structure of a Container, the "searchStrings" and "announceTo" attributes are missing. Why? This supposed to be a minimal set of resources on the device. The "searchStrings" attribute is used for discovery that I don't want to provide in the first release. The "announceTo" makes sense on a gateway, and I had the device in mind. - Just to be sure of my understanding, implementing this subset in the architecture that would amount to implement it in the Device, in the Gateway (IOT API) and in the Backend (Device Level API)? Only on the device. I need some help to define the dIa and the mId on the gateway. Did you get the XSD files for the ETSI M2M? No, Gian Piero did not send it to me. However, I found it from other sources. Best, D?nes De : Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com] Envoy? : vendredi 17 f?vrier 2012 16:01 ? : fiware-etsim2m at lists.fi-ware.eu; fiware-iot at lists.fi-ware.eu Cc : NAGELLEN Thierry RD-BIZZ-SOP; SOUBRA Wafa RD-BIZZ-SOP Objet : ETSI M2M RESTful binding for the mId Dear all, I just created a proposal for the RESTful binding on the mId interface with the minimal set of resources that we should implement for the April release. It is uploaded to the IoT SVM under this link: https://forge.fi-ware.eu/scmrepos/svn/iot/trunk/documents/FIWARE-ETSI-M2M-RESTful-binding.docx Also if someone does not have the access right, I attached to this email. Best, D?nes -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorant.farkas at nsn.com Tue Feb 21 09:11:08 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Tue, 21 Feb 2012 10:11:08 +0200 Subject: [Fiware-iot] MEETING TIME CHANGE - FEEDBACK NEEDED Message-ID: <93D28BDF64839C468B848D14227151A20323C2CD@FIESEXC014.nsn-intra.net> Dear All, Juanjo asked to postpone the IoT weekly meeting from Wednesday to Thursday as he would also like to participate, but cannot do it on Wednesday. Please let me know by EOB today if 10 o'clock Thursday is a suitable timeslot for you. Thanks & Br, Lorant -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.holler at ericsson.com Tue Feb 21 12:19:53 2012 From: jan.holler at ericsson.com (=?Windows-1252?Q?Jan_H=F6ller?=) Date: Tue, 21 Feb 2012 12:19:53 +0100 Subject: [Fiware-iot] MEETING TIME CHANGE - FEEDBACK NEEDED In-Reply-To: <93D28BDF64839C468B848D14227151A20323C2CD@FIESEXC014.nsn-intra.net> Message-ID: Hello Lorant, 10:00 is not doable for me, but 10:30 is fine on Thursday. Jan From: "Farkas, Lorant (NSN - HU/Budapest)" > Date: Tue, 21 Feb 2012 09:11:08 +0100 To: "fiware-iot at lists.fi-ware.eu" > Subject: [Fiware-iot] MEETING TIME CHANGE - FEEDBACK NEEDED Dear All, Juanjo asked to postpone the IoT weekly meeting from Wednesday to Thursday as he would also like to participate, but cannot do it on Wednesday. Please let me know by EOB today if 10 o?clock Thursday is a suitable timeslot for you. Thanks & Br, Lorant From lorant.farkas at nsn.com Wed Feb 22 09:34:48 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Wed, 22 Feb 2012 10:34:48 +0200 Subject: [Fiware-iot] IoT weekly meeting Message-ID: <93D28BDF64839C468B848D14227151A20323C907@FIESEXC014.nsn-intra.net> When: 2012. febru?r 23. 10:30-12:00 (GMT+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague. Where: telco/webex Note: The GMT offset above does not reflect daylight saving time adjustments. *~*~*~*~*~*~*~*~*~* Dear All, I received 3 positive feedbacks for changing the date/time of our meeting, out of which one requests shifting it with half an hour. I guess silence from the other partners means approval, so here is the new invitation. Proposed agenda topics: -architecture specifications: here we would discuss the status, todos according to received comments, in general -the NGSI topic: we would address here the particular topic of NGSI interface, implications on the architecture, role of the GE-s dealing with that -the ETSI M2M topic: the recent decision of TI not to contribute their ETSI M2M asset, the implications and measures we should take (who could implement something, who has resources etc) Thanks & Br, Lorant Dear All, Let's resume our weekly meeting starting from next week in the usual day/time, which is Wednesday, 10:00 AM (CET) to 11:30. Either WPL or WPA will be present to host the meeting. In case we find good reason to skip the meeting, then we will skip it, but I propose not to deviate from this slot. Thanks & Br, Lorant Topic: IOT WP weekly Date: Every Wednesday, from Wednesday, 10 August 2011 to Wednesday, 26 March 2014 Time: 10:00, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 709 472 921 Meeting Password: FI-WARE ------------------------------------------------------- To join the online meeting ------------------------------------------------------- 1. Go to https://nsn.webex.com/nsn/j.php?ED=175018962&UID=0&PW=NYzEzYWM0ZTNk&RT=MTgjMjM%3D 2. Enter your name and email address. 3. Enter the meeting password: FI-WARE 4. Click "Join Now". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://nsn.webex.com/nsn/j.php?ED=175018962&UID=0&PW=NYzEzYWM0ZTNk&ORT=MTgjMjM%3D ------------------------------------------------------- NSN Voice Conference information Conference ID: 58465 New PIN: 1628 Making a conference call * from the office: 8071870 (in Finland and Germany) * from out of office: +358 7180 71870 (in Finland) and +49 89 5159 43800 (in Germany) All out-of-office conference access numbers are listed in page https://inside.nokiasiemensnetworks.com/global/MyServices/IT/Infrastructure_Services/RealTimeCommunication/VoiceService/NSNVoiceConference/MakingaCall/LocalAccessNumbers/Pages/Outofofficenumbers.aspx. Please check and prioritize them. If there is no access number for your country then please use access numbers of the area where to the calling costs are lowest. ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://nsn.webex.com/nsn/mc 2. On the left navigation bar, click "Support". You can contact me at: lorant.farkas at nsn.com Argentina - Buenos Aires +54 11 5983 9400 (PRIMARY) or +54 11 4814 9373 Argentina - Cordoba +54 35 1568 2208 Australia - Sydney +61 28 014 7189 (PRIMARY) or +61 29 429 9664 Australia - Melbourne +61 38 739 4333 Austria +43 72 088 0245 Bahrain +97 31 619 9028 Belgium - Generic +32 1448 0116 Belgium - Diegem-Machelen +32 2710 3300 Brazil - Belo Horizonte +55 31 3956 0546 Brazil - Brazil +55 61 3717 2043 Brazil - Curitiba +55 41 3906 0826 Brazil - Manaus +55 92 3652 7576 Brazil - Rio De Janeiro +55 21 3958 0804 (PRIMARY) or +55 21 3431 1999 Brazil - Salvador +55 71 3717 5351 Brazil - Sao Paolo +55 11 5508 0630 Bulgaria +359 2491 7085 Canada - Ajax +1 90 5619 4346 Canada - Burnaby +1 60 4456 5897 Canada - Hamilton +1 905 581 0212 Canada - Mississauga +1 289 360 3950 Canada - Montreal +1 51 4789 9125 Canada - Ottawa +1 61 3800 0568 Chile - Santiago +56 2350 6485 China - Mainland +86 10 8405 5000 ext 1870 China - Beijing +86 10 8405 5000 ext 1870 China - Chengdu +86 28 8689 0188 ext 1870 China - Dongguan +86 0769 2240 2844 ext 1870 China - Guangzhou +86 20 8755 6190 ext 1870 China - Hangzhou +86 571 8722 0877 ext 1870 China - Hong Kong +852 259 70220 ext 1870 China - Kunming +86 871 362 2880 ext 1870 China - Shanghai +86 21 6101 1870 ext 1870 China - ShenZhen +86 755 8613 3688 ext 1870 China - Suzhou +86 512 6761 6166 ext 1870 China - Zhengzhou +86 371 6566 9768 ext 1870 Colombia +57 1640 7979 ext 444 Croatia +38 51 777 6122 Czech Republic +42 02 460 19300 Denmark +45 699 18450 (PRIMARY) or +45 3329 2882 Egypt +97 31 619 9028 (Bahrain nbr) Estonia +37 266 67297 Finland +358 7180 71870 France +33 17 061 7813 (PRIMARY) or +33 14 915 1553 Germany +49 89 5159 43800 Greece +30 21 1176 8207 (PRIMARY) or +30 21 1120 3677 Hungary - Budapest +36 17 009 888 Hungary - Kom?rom +36 20 884 2499 India 000 800 100 7777 Indonesia - Jakarta (Menara Mulia/Plaza Kuningan +62 21 2557 9102 Indonesia - Bandung +62 22 8427 5992 Indonesia - Medan +62 61 3001 2702 Indonesia - Semarang +62 24 3300 0702 Ireland +353 1526 2862 Israel +97 29 775 1700 Italy - Milan +39 024 004 2007 Italy - Rome +39 069 481 6656 Japan +81 3 4578 0230 (PRIMARY) or +81 3 5474 7979 Kuwait +97 31 619 9028 (Bahrain nbr) Latvia +37 16 765 2510 Lithuania +37 0 5205 8994 Luxembourg +352 2088 0106 Malaysia +60 323 029 009 Mexico - Mexico City +52 55 3686 9759 (PRIMARY) or +52 55 5261 7245 Mexico - Reynosa +52 89 9909 1555 Netherlands +31 79 346 5225 New Zealand +64 9306 6933 Norway - Oslo +47 21 548 223 Oman +97 31 619 9028 (Bahrain nbr) Pakistan +92 512 092 444 Panama +507 832 7981 Peru +51 1708 5370 (PRIMARY) or +51 1215 7650 Philippines +63 2754 1700 Poland - Warsaw +48 22 398 8116 Poland - Wroclaw +48 71 718 1215 Portugal +351 21 044 4698 Qatar +97 31 619 9028 (Bahrain nbr) Romania +40 36 440 3799 Russia +74 95 725 2706 Saudi Arabia +97 31 619 9028 (Bahrain nbr) Singapore +65 3103 1065 (PRIMARY) or +65 6723 2582 Slovakia +42 12 3300 6924 Slovenia +38 61 600 2713 South Africa - Johannesburg +27 1 0500 2221 South Africa - Pretoria +27 1 2004 2334 South Korea - Masan +82 5 5290 7690 South Korea - Seoul +82 2 2186 5088 Spain +349 1187 5929 Sweden +46 85 250 0862 (PRIMARY), +46 84 100 9299 Switzerland +41 44 279 7943 Taiwan +88 62 8175 9298 Thailand +66 2762 6750 Turkey +90 216 570 2345 Ukraine +38 044 520 2272 UK +44 12 5275 8334 UK - Camberley +44 12 5286 5849 UK - Church Crookham +44 12 5261 1100 UK - Huntingdon +44 14 8087 8220 (PRIMARY), +44 14 8044 4206 UK - London +44 20 3318 1924 United Arab Emirates +97 31 619 9028 (Bahrain nbr) USA - Alpharetta +1 770 871 3050 USA - Arizona +1 480 588 3748 USA - Atlanta +1 404 236 4550 USA - Atlanta Notheast +1 678 317 3165 USA - Austin/Round Rock +1 512 600 2027 USA - Belleville +1 973 547 7982 USA - Boca Raton +1 561 910 2843 USA - Boston +1 617 963 8320 (PRIMARY) or +1 781 993 4850 USA - Burlington +1 781 993 4850 USA - Calabasas +1 818 914 0215 USA - Canoga Park +1 818 914 0215 USA - Cary +1 919 655 1388 USA - Chelmsford/Littleton +1 978 679 0233 USA - Chicago +1 773 303 4710 USA - Dallas +1 214 269 7626 USA - Dallas/Fort Worth +1 214 270 0352 USA - Greenville, NC +1 252 329 1677 USA - Herndon +1 703 483 4485 USA - Johnson City +1 423 952 1545 USA - Kirkland +1 425 242 3113 USA - Miami +1 786 388 4150 or +1 786 329 7177 USA - Naperville +1 630 596 2203 USA - New Brunswick +1 732 579 6483 USA - New Century, KS +1 913 254 5900 USA - New York White Plains +1 914 368 0650 USA - New York Peekskill, White Plains +1 914 293 1885 USA - Palo Alto +1 650 644 1349 USA - Redmond +1 425 242 3113 USA - San Diego +1 858 769 5309 or +1 619 330 9699 USA - Sunnyvale +1 408 419 1750 USA - Washington D.C +1 202 552 4781 Vietnam +84 4 3724 6110 Yemen +97 31 619 9028 (Bahrain nbr) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 10955 bytes Desc: not available URL: From Ernoe.Kovacs at neclab.eu Thu Feb 23 10:30:59 2012 From: Ernoe.Kovacs at neclab.eu (Ernoe Kovacs) Date: Thu, 23 Feb 2012 09:30:59 +0000 Subject: [Fiware-iot] IoT WP5 meeting: presentation for Discussion Message-ID: <8152E2132B13FB488CFD1947E2DEF19C24FCD647@DAPHNIS.office.hd> Hi all, please find a short presentation that tries to point out a few aspects for the discussion in the WP5 meeting... - Ern? ========================================================== Dr. Ern? Kovacs Senior Manager Internet Services NEC Europe Ltd. NEC Laboratories Europe Kurf?rsten-Anlage 36 D-69115 Heidelberg, Germany Phone: +49 (6221) 4342 - 131 Fax: +49 (6221) 4342 - 155 Mobile: +49 (163) 2086046 EMail: ernoe.kovacs at nw.neclab.eu http://www.netlab.nec.de ========================================================== Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK Registered in England, No. 2832014 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2012-02-23 FI-WARE-Discussion.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 371489 bytes Desc: 2012-02-23 FI-WARE-Discussion.pptx URL: From gianpiero.fici at telecomitalia.it Thu Feb 23 10:40:22 2012 From: gianpiero.fici at telecomitalia.it (Fici Gian Piero) Date: Thu, 23 Feb 2012 10:40:22 +0100 Subject: [Fiware-iot] ETSI M2M stage 3 specification: XSDs for REST and annexes Message-ID: Hi everybody, I completely forgot to forward the missing parts of the ETSI M2M specification to the mailing list. These missing parts are the annexes to the stage 3 documentation (TS 102 921) and the XSDs for the REST definition. Here they are, sorry for being so late. Ciao, Gian Piero P.S. Please note that the included documents, even if they are versioned 0.9.4 have actually the same content of the official 1.0.0 release that was announced by ETSI on the 20th February. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:00000000000000000000000000000003 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia2.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia2.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Draft TS 102 921v094_clean_ANNEXES.zip Type: application/x-zip-compressed Size: 983533 bytes Desc: Draft TS 102 921v094_clean_ANNEXES.zip URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: XSD.zip Type: application/x-zip-compressed Size: 39629 bytes Desc: XSD.zip URL: From gianpiero.fici at telecomitalia.it Thu Feb 23 19:11:55 2012 From: gianpiero.fici at telecomitalia.it (Fici Gian Piero) Date: Thu, 23 Feb 2012 19:11:55 +0100 Subject: [Fiware-iot] Architecture Description updates Message-ID: Hi all, here it is a list of the changes I made in the Architecture Description wiki (I provide this list in order to make easier the check of the modifications in the GEs descriptions and further comments on them): Connectivity Management GE * Changed all the occurrence of "Device" in "IoT Resource" (Juanjo's comment) * Replaced the lists of operations in the Main Interactions section with 4 figures depicting the call flows when a message coming from the Backend have to be forwarded to an IoT Resource or when a message coming from an IoT Resource have to be forwarded to the Backend. The pattern is the one where the Discontinuous Connectivity Management component is central (it gets all the messages to be forwarded and then decides if forwarding or storing them). * Modified the Basic Concepts section, in particular for the Internal Interfaces description. The general approach of the section (a list of general information about the GE and descriptions of its components) has remained the same since Juanjo's comment was favorable to this kind of content. Exposure GE * Changed all the occurrence of "Device" in "IoT Resource" (Juanjo's comment) * Added a more detailed description of ETSI M2M standard in the Basic Concepts section (following Juanjo's suggestion I used the presentation I made in Madrid GA). * Modified also the Internal Interfaces in the Basic Concepts section. * Replaced the lists of operations in the Main Interactions section with 4 figures depicting the call flows for messages coming from the Backend or routed to the Backend. Service Control GE * Added a description of the Service Control GE even if it is not included in the April release (Juanjo's comment) Unfortunately I am not able to modify the Data Pooling GE today, but I will make similar changes to this GE description too. Please let me know if you agree with these changes and if I understood correctly your comments. :) Ciao, Gian Piero Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. [cid:00000000000000000000000000000003 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non ? necessario. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo Ambiente_foglia2.jpg Type: image/jpeg Size: 677 bytes Desc: logo Ambiente_foglia2.jpg URL: From lorant.farkas at nsn.com Fri Feb 24 07:43:57 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Fri, 24 Feb 2012 08:43:57 +0200 Subject: [Fiware-iot] IoT weekly minutes Message-ID: <93D28BDF64839C468B848D14227151A20327B0F3@FIESEXC014.nsn-intra.net> Dear All, Please find the minutes of our weekly call under the following link: https://forge.fi-ware.eu/docman/view.php/11/826/IoT-Minutes-Telco-230220 12.docx Thanks & Br, Lorant -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ernoe.Kovacs at neclab.eu Fri Feb 24 15:23:57 2012 From: Ernoe.Kovacs at neclab.eu (Ernoe Kovacs) Date: Fri, 24 Feb 2012 14:23:57 +0000 Subject: [Fiware-iot] Update to D11.4.a: Standardisation Plan Message-ID: <8152E2132B13FB488CFD1947E2DEF19C24FCFB91@DAPHNIS.office.hd> Hi Thierry, Denes, Lorant, hi FI-Ware IoT chapter, we did an update to the standardization plan document D11.4.a to highlight the start of the ETSI M2M study group on "Semantic Support for M2M Data". This is a direct action from Fi-Ware and IoT-A and we like to see this reflected in the standardization plan. Thierry, Denes, Lorant, can you please approve this changes to Lindsay so that he can sleep assured this changes are agreed by WP5. - Ern? ========================================================== Dr. Ern? Kovacs Senior Manager Internet Services NEC Europe Ltd. NEC Laboratories Europe Kurf?rsten-Anlage 36 D-69115 Heidelberg, Germany Phone: +49 (6221) 4342 - 131 Fax: +49 (6221) 4342 - 155 Mobile: +49 (163) 2086046 EMail: ernoe.kovacs at nw.neclab.eu http://www.netlab.nec.de ========================================================== Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK Registered in England, No. 2832014 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FI-WARE_Standardisation_Plan_201202024_EPK.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 599697 bytes Desc: FI-WARE_Standardisation_Plan_201202024_EPK.docx URL: From lorant.farkas at nsn.com Mon Feb 27 12:32:34 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Mon, 27 Feb 2012 13:32:34 +0200 Subject: [Fiware-iot] WPL/WPA meeting minutes Message-ID: <93D28BDF64839C468B848D14227151A20327B955@FIESEXC014.nsn-intra.net> Dear All, Please find under this link the minutes of the weekly WPL/WPA call. https://docs.google.com/document/d/1gkEUTMfUizrYxt9y24jOWdT3fvFpv5nKQJch 1_3sVAc/edit Will share these with you directly from now on. Thanks & Br, Lorant -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorant.farkas at nsn.com Tue Feb 28 09:05:00 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Tue, 28 Feb 2012 10:05:00 +0200 Subject: [Fiware-iot] IoT weekly meeting Message-ID: <93D28BDF64839C468B848D14227151A2032BF69E@FIESEXC014.nsn-intra.net> When: 2012. febru?r 29. 10:00-11:30 (GMT+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague. Where: telco/webex Note: The GMT offset above does not reflect daylight saving time adjustments. *~*~*~*~*~*~*~*~*~* Dear All, Tomorrow we propose to discuss about the following topics: 1. Architecture specifications: review the pending issues before the publication (tomorrow - backend part, 6th of March - also gateway part) 2. Technical roadmap: this is a 2 pages deliverable we have to produce by the end of the week, we will receive guidelines how to do it today EOB, which I will forward to you as soon as I get it 3. Implementation/integration work: we should have a round table on which partner started to implement concretely what and which are the plans, in order to have a global view of what we will provide by April which should then correctly be reflected in the backlog Thanks & Br, Lorant Dear All, Let's resume our weekly meeting starting from next week in the usual day/time, which is Wednesday, 10:00 AM (CET) to 11:30. Either WPL or WPA will be present to host the meeting. In case we find good reason to skip the meeting, then we will skip it, but I propose not to deviate from this slot. Thanks & Br, Lorant Topic: IOT WP weekly Date: Every Wednesday, from Wednesday, 10 August 2011 to Wednesday, 26 March 2014 Time: 10:00, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 709 472 921 Meeting Password: FI-WARE ------------------------------------------------------- To join the online meeting ------------------------------------------------------- 1. Go to https://nsn.webex.com/nsn/j.php?ED=175018962&UID=0&PW=NYzEzYWM0ZTNk&RT=MTgjMjM%3D 2. Enter your name and email address. 3. Enter the meeting password: FI-WARE 4. Click "Join Now". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://nsn.webex.com/nsn/j.php?ED=175018962&UID=0&PW=NYzEzYWM0ZTNk&ORT=MTgjMjM%3D ------------------------------------------------------- NSN Voice Conference information Conference ID: 58465 New PIN: 1628 Making a conference call * from the office: 8071870 (in Finland and Germany) * from out of office: +358 7180 71870 (in Finland) and +49 89 5159 43800 (in Germany) All out-of-office conference access numbers are listed in page https://inside.nokiasiemensnetworks.com/global/MyServices/IT/Infrastructure_Services/RealTimeCommunication/VoiceService/NSNVoiceConference/MakingaCall/LocalAccessNumbers/Pages/Outofofficenumbers.aspx. Please check and prioritize them. If there is no access number for your country then please use access numbers of the area where to the calling costs are lowest. ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://nsn.webex.com/nsn/mc 2. On the left navigation bar, click "Support". You can contact me at: lorant.farkas at nsn.com Argentina - Buenos Aires +54 11 5983 9400 (PRIMARY) or +54 11 4814 9373 Argentina - Cordoba +54 35 1568 2208 Australia - Sydney +61 28 014 7189 (PRIMARY) or +61 29 429 9664 Australia - Melbourne +61 38 739 4333 Austria +43 72 088 0245 Bahrain +97 31 619 9028 Belgium - Generic +32 1448 0116 Belgium - Diegem-Machelen +32 2710 3300 Brazil - Belo Horizonte +55 31 3956 0546 Brazil - Brazil +55 61 3717 2043 Brazil - Curitiba +55 41 3906 0826 Brazil - Manaus +55 92 3652 7576 Brazil - Rio De Janeiro +55 21 3958 0804 (PRIMARY) or +55 21 3431 1999 Brazil - Salvador +55 71 3717 5351 Brazil - Sao Paolo +55 11 5508 0630 Bulgaria +359 2491 7085 Canada - Ajax +1 90 5619 4346 Canada - Burnaby +1 60 4456 5897 Canada - Hamilton +1 905 581 0212 Canada - Mississauga +1 289 360 3950 Canada - Montreal +1 51 4789 9125 Canada - Ottawa +1 61 3800 0568 Chile - Santiago +56 2350 6485 China - Mainland +86 10 8405 5000 ext 1870 China - Beijing +86 10 8405 5000 ext 1870 China - Chengdu +86 28 8689 0188 ext 1870 China - Dongguan +86 0769 2240 2844 ext 1870 China - Guangzhou +86 20 8755 6190 ext 1870 China - Hangzhou +86 571 8722 0877 ext 1870 China - Hong Kong +852 259 70220 ext 1870 China - Kunming +86 871 362 2880 ext 1870 China - Shanghai +86 21 6101 1870 ext 1870 China - ShenZhen +86 755 8613 3688 ext 1870 China - Suzhou +86 512 6761 6166 ext 1870 China - Zhengzhou +86 371 6566 9768 ext 1870 Colombia +57 1640 7979 ext 444 Croatia +38 51 777 6122 Czech Republic +42 02 460 19300 Denmark +45 699 18450 (PRIMARY) or +45 3329 2882 Egypt +97 31 619 9028 (Bahrain nbr) Estonia +37 266 67297 Finland +358 7180 71870 France +33 17 061 7813 (PRIMARY) or +33 14 915 1553 Germany +49 89 5159 43800 Greece +30 21 1176 8207 (PRIMARY) or +30 21 1120 3677 Hungary - Budapest +36 17 009 888 Hungary - Kom?rom +36 20 884 2499 India 000 800 100 7777 Indonesia - Jakarta (Menara Mulia/Plaza Kuningan +62 21 2557 9102 Indonesia - Bandung +62 22 8427 5992 Indonesia - Medan +62 61 3001 2702 Indonesia - Semarang +62 24 3300 0702 Ireland +353 1526 2862 Israel +97 29 775 1700 Italy - Milan +39 024 004 2007 Italy - Rome +39 069 481 6656 Japan +81 3 4578 0230 (PRIMARY) or +81 3 5474 7979 Kuwait +97 31 619 9028 (Bahrain nbr) Latvia +37 16 765 2510 Lithuania +37 0 5205 8994 Luxembourg +352 2088 0106 Malaysia +60 323 029 009 Mexico - Mexico City +52 55 3686 9759 (PRIMARY) or +52 55 5261 7245 Mexico - Reynosa +52 89 9909 1555 Netherlands +31 79 346 5225 New Zealand +64 9306 6933 Norway - Oslo +47 21 548 223 Oman +97 31 619 9028 (Bahrain nbr) Pakistan +92 512 092 444 Panama +507 832 7981 Peru +51 1708 5370 (PRIMARY) or +51 1215 7650 Philippines +63 2754 1700 Poland - Warsaw +48 22 398 8116 Poland - Wroclaw +48 71 718 1215 Portugal +351 21 044 4698 Qatar +97 31 619 9028 (Bahrain nbr) Romania +40 36 440 3799 Russia +74 95 725 2706 Saudi Arabia +97 31 619 9028 (Bahrain nbr) Singapore +65 3103 1065 (PRIMARY) or +65 6723 2582 Slovakia +42 12 3300 6924 Slovenia +38 61 600 2713 South Africa - Johannesburg +27 1 0500 2221 South Africa - Pretoria +27 1 2004 2334 South Korea - Masan +82 5 5290 7690 South Korea - Seoul +82 2 2186 5088 Spain +349 1187 5929 Sweden +46 85 250 0862 (PRIMARY), +46 84 100 9299 Switzerland +41 44 279 7943 Taiwan +88 62 8175 9298 Thailand +66 2762 6750 Turkey +90 216 570 2345 Ukraine +38 044 520 2272 UK +44 12 5275 8334 UK - Camberley +44 12 5286 5849 UK - Church Crookham +44 12 5261 1100 UK - Huntingdon +44 14 8087 8220 (PRIMARY), +44 14 8044 4206 UK - London +44 20 3318 1924 United Arab Emirates +97 31 619 9028 (Bahrain nbr) USA - Alpharetta +1 770 871 3050 USA - Arizona +1 480 588 3748 USA - Atlanta +1 404 236 4550 USA - Atlanta Notheast +1 678 317 3165 USA - Austin/Round Rock +1 512 600 2027 USA - Belleville +1 973 547 7982 USA - Boca Raton +1 561 910 2843 USA - Boston +1 617 963 8320 (PRIMARY) or +1 781 993 4850 USA - Burlington +1 781 993 4850 USA - Calabasas +1 818 914 0215 USA - Canoga Park +1 818 914 0215 USA - Cary +1 919 655 1388 USA - Chelmsford/Littleton +1 978 679 0233 USA - Chicago +1 773 303 4710 USA - Dallas +1 214 269 7626 USA - Dallas/Fort Worth +1 214 270 0352 USA - Greenville, NC +1 252 329 1677 USA - Herndon +1 703 483 4485 USA - Johnson City +1 423 952 1545 USA - Kirkland +1 425 242 3113 USA - Miami +1 786 388 4150 or +1 786 329 7177 USA - Naperville +1 630 596 2203 USA - New Brunswick +1 732 579 6483 USA - New Century, KS +1 913 254 5900 USA - New York White Plains +1 914 368 0650 USA - New York Peekskill, White Plains +1 914 293 1885 USA - Palo Alto +1 650 644 1349 USA - Redmond +1 425 242 3113 USA - San Diego +1 858 769 5309 or +1 619 330 9699 USA - Sunnyvale +1 408 419 1750 USA - Washington D.C +1 202 552 4781 Vietnam +84 4 3724 6110 Yemen +97 31 619 9028 (Bahrain nbr) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 10912 bytes Desc: not available URL: From lorant.farkas at nsn.com Tue Feb 28 09:44:01 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Tue, 28 Feb 2012 10:44:01 +0200 Subject: [Fiware-iot] "architecture specification" diagrams to Forge Message-ID: <93D28BDF64839C468B848D14227151A2032BF706@FIESEXC014.nsn-intra.net> Dear All, Because of the problems encountered with SVN I created in Forge a folder structure under "D2.3 Architecture Specification" with the subfolders DataModel, FMC, Interaction, Other and pdf. The 1st three are clear, I put Other for the case where there are diagrams not matching any of the 1st three categories and in the pdf folder we would store snapshots of the exported wiki. I would like to ask you to upload in the appropriate subfolder in the original format the diagrams you have uploaded as a png to wiki so that we can polish them if needed. Please don't forget to mark them private. Thanks & Br, Lorant -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorant.farkas at nsn.com Tue Feb 28 10:55:53 2012 From: lorant.farkas at nsn.com (Farkas, Lorant (NSN - HU/Budapest)) Date: Tue, 28 Feb 2012 11:55:53 +0200 Subject: [Fiware-iot] T5.2 FMC model Message-ID: <93D28BDF64839C468B848D14227151A2032BF7AD@FIESEXC014.nsn-intra.net> Dear All, I would replace T5.2 FMC with this to harmonize with the general architecture, please comment possibly before noon. <> <> Thanks & Br, Lorant -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IoT-BackendThingsAndResourcesManagementGE.png Type: image/png Size: 21315 bytes Desc: IoT-BackendThingsAndResourcesManagementGE.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IoT-BackendThingsAndResourcesManagementGE.graphml Type: application/octet-stream Size: 31460 bytes Desc: IoT-BackendThingsAndResourcesManagementGE.graphml URL: From Tobias.Jacobs at neclab.eu Tue Feb 28 11:42:57 2012 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Tue, 28 Feb 2012 10:42:57 +0000 Subject: [Fiware-iot] T5.2 FMC model In-Reply-To: <93D28BDF64839C468B848D14227151A2032BF7AD@FIESEXC014.nsn-intra.net> References: <93D28BDF64839C468B848D14227151A2032BF7AD@FIESEXC014.nsn-intra.net> Message-ID: <8755F290097BD941865DC4245B335D2D08BA9EC5@DAPHNIS.office.hd> Hi Lorant, Thanks for the modifications, and sorry, it would have been partially my job to do it when I moved the Observation Handler into the Exposure. Best Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Farkas, Lorant (NSN - HU/Budapest) Sent: Dienstag, 28. Februar 2012 10:56 To: ext Ricardo de las Heras Cc: fiware-iot at lists.fi-ware.eu Subject: [Fiware-iot] T5.2 FMC model Dear All, I would replace T5.2 FMC with this to harmonize with the general architecture, please comment possibly before noon. <> <> Thanks & Br, Lorant -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhierro at tid.es Tue Feb 28 17:04:01 2012 From: jhierro at tid.es (Juanjo Hierro) Date: Tue, 28 Feb 2012 17:04:01 +0100 Subject: [Fiware-iot] Necessary updates on IoT Chapter Architecture Description prior to publication Message-ID: <4F4CFAF1.8030507@tid.es> Hi all, I have carried out a revision of the new text regarding the description of the Exposure GE in the IoT Chapter Description and here you are the comments that I believe we should incorporate prior publication of the IoT Chapter Architecture Description. Some comments may be labeled as editorial but others are not. However, I believe (or at least hope :-) there shouldn't be so much controversial ... 1. What we refer as "exposure GE" should be renamed to avoid misinterpretations. What is there within the boundaries of the so called "exposure GE" do not comprise the APIs exposed to the final applications. The FI-WARE NGSI-10 interface that applications will use will be implemented by the Publish/Subscribe Broker GE, while the FI-WARE NGSI-9 interface that applications will use to query or get notified about IoT entities registered in the system (IoT resources or abstract things) will be implemented by the Things/Resource Configuration Management GE. It is true that the Observation and Request Handlers will implement the NGSI-10 interface (partly, see comment below) as well as use some operations of the NGSI-9 and NGSI-10 interfaces to interact with the Publish/Subscribe Broker GE and the Things/Resource Configuration Management GE, but this is not because we intend that those interfaces be exposed to applications but because we wish that the interfaces between the GE embracing the Observation and Request Handler and the other two GEs be standard (therefore, the implementation of the three be truly replaceble). Regarding what name is therefore more appropriate for this box/GE, I refer to point 3 below. 2. What is a GE within the "exposure GE". GEs are by nature "replaceable" and, therefore: * we should put the boundaries of GEs where we intend to make this replacement "feasible" * we should keep withing the box of a GE those functions elements we believe may probably come closely coupled together in a given implementation. Given said this, I don't think it's a good idea that people infer that the implementation of the "device-level API" component is coupled with the implementation of the components named as "Thing-level API". They should be both two separate GEs. About the name to give to those GEs, I definitively don't like and I rather believe it is wrong to name a GE as " API" ... APIs are what GEs expose but a GE is not an API. Some people believe this kind of issues are not rather important but I believe that the more rigorous we are, the more professional our work will look like. While I do not have a good candidate name for the "device-level API" GE ("IoT device handler" ?) I believe that the "Thing-level" API should be renamed as "NGSI-M2M bridge" or "NGSI-IoT bridge" if we want to keep it more generic since its mission is actually to deal with the bridging between the "Pub/Sub Broker" GE and the "IoT device handler" GE (if we call it that way) 3. Do we really need to give an entity to what has been called as "exposure GE" ? Based on 1 and 2, I would rather propose to drop the "exposure GE" as an GE embracing two GEs, the "NGSI-IoT bridge" GE and the "IoT device handler" GE. It's true that we may use the notion of nested GEs, therefore defining a GE as the grouping of two related GEs ... but then ... why aren't we grouping the Things/Resources Configuration Management GE within the same group ? or grouping the "IoT device handler" and the "Publish/Subscribe Broker" GE together ? Note that the "IoT device handler" GE (named as "device-level API" in the current figure) plus the "Publish/Subscribe Broker" GE and the "Things/Resources Configuration Management" GE altogether implement the APIs that are exposed as northbound interfaces to the applications so, if we believe it is important to have a "exposure GE" grouping those GEs implementing exposed APIs, it should be embracing these three, and not the "NGSI-IoT bridge" GE (named as "Thing-level API" in the current figure) I would kindly ask you to implement these changes prior to publication. There are a couple of further comments regarding the interaction between the Request and Observation Handler components and the Publish/Subscribe Broker GE that I will forward on a separate email. Best regards, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Chief Architect You can follow FI-WARE at: website: http://www.fi-ware.eu facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 twitter: http://twitter.com/FIware linkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhierro at tid.es Wed Feb 29 07:24:03 2012 From: jhierro at tid.es (Juanjo Hierro) Date: Wed, 29 Feb 2012 07:24:03 +0100 Subject: [Fiware-iot] Necessary updates on IoT Chapter Architecture Description prior to publication In-Reply-To: <4F4CFAF1.8030507@tid.es> References: <4F4CFAF1.8030507@tid.es> Message-ID: <4F4DC483.2070707@tid.es> Hi all, Please proceed uploading the contents of the IoT chapter once you incorporate the comments I provided. If you don't agree with them, please let's discuss. I believe that the pending comments regarding interaction between the Observation/Request Handler and the Publish/Subscribe Broker GE are comments we can deal with before the final release by March 6 so we don't need to delay uploading of contents because of them. I remind you that we agreed to upload now contents linked to the backend part. Uploading of contents linked to the gateway part can be planned for March 6. This will give you enough time to fix whatever needs still to be fixed. Best regards, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Chief Architect You can follow FI-WARE at: website: http://www.fi-ware.eu facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 twitter: http://twitter.com/FIware linkedIn: http://www.linkedin.com/groups/FIWARE-4239932 On 28/02/12 17:04, Juanjo Hierro wrote: Hi all, I have carried out a revision of the new text regarding the description of the Exposure GE in the IoT Chapter Description and here you are the comments that I believe we should incorporate prior publication of the IoT Chapter Architecture Description. Some comments may be labeled as editorial but others are not. However, I believe (or at least hope :-) there shouldn't be so much controversial ... 1. What we refer as "exposure GE" should be renamed to avoid misinterpretations. What is there within the boundaries of the so called "exposure GE" do not comprise the APIs exposed to the final applications. The FI-WARE NGSI-10 interface that applications will use will be implemented by the Publish/Subscribe Broker GE, while the FI-WARE NGSI-9 interface that applications will use to query or get notified about IoT entities registered in the system (IoT resources or abstract things) will be implemented by the Things/Resource Configuration Management GE. It is true that the Observation and Request Handlers will implement the NGSI-10 interface (partly, see comment below) as well as use some operations of the NGSI-9 and NGSI-10 interfaces to interact with the Publish/Subscribe Broker GE and the Things/Resource Configuration Management GE, but this is not because we intend that those interfaces be exposed to applications but because we wish that the interfaces between the GE embracing the Observation and Request Handler and the other two GEs be standard (therefore, the implementation of the three be truly replaceble). Regarding what name is therefore more appropriate for this box/GE, I refer to point 3 below. 2. What is a GE within the "exposure GE". GEs are by nature "replaceable" and, therefore: * we should put the boundaries of GEs where we intend to make this replacement "feasible" * we should keep withing the box of a GE those functions elements we believe may probably come closely coupled together in a given implementation. Given said this, I don't think it's a good idea that people infer that the implementation of the "device-level API" component is coupled with the implementation of the components named as "Thing-level API". They should be both two separate GEs. About the name to give to those GEs, I definitively don't like and I rather believe it is wrong to name a GE as " API" ... APIs are what GEs expose but a GE is not an API. Some people believe this kind of issues are not rather important but I believe that the more rigorous we are, the more professional our work will look like. While I do not have a good candidate name for the "device-level API" GE ("IoT device handler" ?) I believe that the "Thing-level" API should be renamed as "NGSI-M2M bridge" or "NGSI-IoT bridge" if we want to keep it more generic since its mission is actually to deal with the bridging between the "Pub/Sub Broker" GE and the "IoT device handler" GE (if we call it that way) 3. Do we really need to give an entity to what has been called as "exposure GE" ? Based on 1 and 2, I would rather propose to drop the "exposure GE" as an GE embracing two GEs, the "NGSI-IoT bridge" GE and the "IoT device handler" GE. It's true that we may use the notion of nested GEs, therefore defining a GE as the grouping of two related GEs ... but then ... why aren't we grouping the Things/Resources Configuration Management GE within the same group ? or grouping the "IoT device handler" and the "Publish/Subscribe Broker" GE together ? Note that the "IoT device handler" GE (named as "device-level API" in the current figure) plus the "Publish/Subscribe Broker" GE and the "Things/Resources Configuration Management" GE altogether implement the APIs that are exposed as northbound interfaces to the applications so, if we believe it is important to have a "exposure GE" grouping those GEs implementing exposed APIs, it should be embracing these three, and not the "NGSI-IoT bridge" GE (named as "Thing-level API" in the current figure) I would kindly ask you to implement these changes prior to publication. There are a couple of further comments regarding the interaction between the Request and Observation Handler components and the Publish/Subscribe Broker GE that I will forward on a separate email. Best regards, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Chief Architect You can follow FI-WARE at: website: http://www.fi-ware.eu facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 twitter: http://twitter.com/FIware linkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tobias.Jacobs at neclab.eu Wed Feb 29 10:28:33 2012 From: Tobias.Jacobs at neclab.eu (Tobias Jacobs) Date: Wed, 29 Feb 2012 09:28:33 +0000 Subject: [Fiware-iot] Necessary updates on IoT Chapter Architecture Description prior to publication In-Reply-To: <4F4DC483.2070707@tid.es> References: <4F4CFAF1.8030507@tid.es> <4F4DC483.2070707@tid.es> Message-ID: <8755F290097BD941865DC4245B335D2D08BAA0F2@DAPHNIS.office.hd> Hi Juanjo, all, We agree in principle with your proposal, except that we think that the name "IoT Broker GE" describes the functionality of the Observation+Request handler better than "NGSI-IoT bridge" does. Best Tobias From: fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] On Behalf Of Juanjo Hierro Sent: Mittwoch, 29. Februar 2012 07:24 To: fiware-iot at lists.fi-ware.eu Subject: Re: [Fiware-iot] Necessary updates on IoT Chapter Architecture Description prior to publication Hi all, Please proceed uploading the contents of the IoT chapter once you incorporate the comments I provided. If you don't agree with them, please let's discuss. I believe that the pending comments regarding interaction between the Observation/Request Handler and the Publish/Subscribe Broker GE are comments we can deal with before the final release by March 6 so we don't need to delay uploading of contents because of them. I remind you that we agreed to upload now contents linked to the backend part. Uploading of contents linked to the gateway part can be planned for March 6. This will give you enough time to fix whatever needs still to be fixed. Best regards, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Chief Architect You can follow FI-WARE at: website: http://www.fi-ware.eu facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 twitter: http://twitter.com/FIware linkedIn: http://www.linkedin.com/groups/FIWARE-4239932 On 28/02/12 17:04, Juanjo Hierro wrote: Hi all, I have carried out a revision of the new text regarding the description of the Exposure GE in the IoT Chapter Description and here you are the comments that I believe we should incorporate prior publication of the IoT Chapter Architecture Description. Some comments may be labeled as editorial but others are not. However, I believe (or at least hope :-) there shouldn't be so much controversial ... 1. What we refer as "exposure GE" should be renamed to avoid misinterpretations. What is there within the boundaries of the so called "exposure GE" do not comprise the APIs exposed to the final applications. The FI-WARE NGSI-10 interface that applications will use will be implemented by the Publish/Subscribe Broker GE, while the FI-WARE NGSI-9 interface that applications will use to query or get notified about IoT entities registered in the system (IoT resources or abstract things) will be implemented by the Things/Resource Configuration Management GE. It is true that the Observation and Request Handlers will implement the NGSI-10 interface (partly, see comment below) as well as use some operations of the NGSI-9 and NGSI-10 interfaces to interact with the Publish/Subscribe Broker GE and the Things/Resource Configuration Management GE, but this is not because we intend that those interfaces be exposed to applications but because we wish that the interfaces between the GE embracing the Observation and Request Handler and the other two GEs be standard (therefore, the implementation of the three be truly replaceble). Regarding what name is therefore more appropriate for this box/GE, I refer to point 3 below. 2. What is a GE within the "exposure GE". GEs are by nature "replaceable" and, therefore: * we should put the boundaries of GEs where we intend to make this replacement "feasible" * we should keep withing the box of a GE those functions elements we believe may probably come closely coupled together in a given implementation. Given said this, I don't think it's a good idea that people infer that the implementation of the "device-level API" component is coupled with the implementation of the components named as "Thing-level API". They should be both two separate GEs. About the name to give to those GEs, I definitively don't like and I rather believe it is wrong to name a GE as " API" ... APIs are what GEs expose but a GE is not an API. Some people believe this kind of issues are not rather important but I believe that the more rigorous we are, the more professional our work will look like. While I do not have a good candidate name for the "device-level API" GE ("IoT device handler" ?) I believe that the "Thing-level" API should be renamed as "NGSI-M2M bridge" or "NGSI-IoT bridge" if we want to keep it more generic since its mission is actually to deal with the bridging between the "Pub/Sub Broker" GE and the "IoT device handler" GE (if we call it that way) 3. Do we really need to give an entity to what has been called as "exposure GE" ? Based on 1 and 2, I would rather propose to drop the "exposure GE" as an GE embracing two GEs, the "NGSI-IoT bridge" GE and the "IoT device handler" GE. It's true that we may use the notion of nested GEs, therefore defining a GE as the grouping of two related GEs ... but then ... why aren't we grouping the Things/Resources Configuration Management GE within the same group ? or grouping the "IoT device handler" and the "Publish/Subscribe Broker" GE together ? Note that the "IoT device handler" GE (named as "device-level API" in the current figure) plus the "Publish/Subscribe Broker" GE and the "Things/Resources Configuration Management" GE altogether implement the APIs that are exposed as northbound interfaces to the applications so, if we believe it is important to have a "exposure GE" grouping those GEs implementing exposed APIs, it should be embracing these three, and not the "NGSI-IoT bridge" GE (named as "Thing-level API" in the current figure) I would kindly ask you to implement these changes prior to publication. There are a couple of further comments regarding the interaction between the Request and Observation Handler components and the Publish/Subscribe Broker GE that I will forward on a separate email. Best regards, -- Juanjo ------------- Product Development and Innovation (PDI) - Telefonica Digital website: www.tid.es email: jhierro at tid.es twitter: twitter.com/JuanjoHierro FI-WARE (European Future Internet Core Platform) Chief Architect You can follow FI-WARE at: website: http://www.fi-ware.eu facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 twitter: http://twitter.com/FIware linkedIn: http://www.linkedin.com/groups/FIWARE-4239932 ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: