Architecture for Improving Terrestrial Logistics Based on the Web of Things

Technological advances for improving supply chain efficiency present three key challenges for managing goods: tracking, tracing and monitoring (TTM), in order to satisfy the requirements for products such as perishable goods where the European Legislations requires them to ship within a prescribed temperature range to ensure freshness and suitability for consumption. The proposed system integrates RFID for tracking and tracing through a distributed architecture developed for heavy goods vehicles, and the sensors embedded in the SunSPOT platform for monitoring the goods transported based on the concept of the Internet of Things. This paper presents how the Internet of Things is integrated for improving terrestrial logistics offering a comprehensive and flexible architecture, with high scalability, according to the specific needs for reaching an item-level continuous monitoring solution. The major contribution from this work is the optimization of the Embedded Web Services based on RESTful (Web of Things) for the access to TTM services at any time during the transportation of goods. Specifically, it has been extended the monitoring patterns such as observe and blockwise transfer for the requirements from the continuous conditional monitoring, and for the transfer of full inventories and partial ones based on conditional queries. In definitive, this work presents an evolution of the previous TTM solutions, which were limited to trailer identification and environment monitoring, to a solution which is able to provide an exhaustive item-level monitoring, required for several use cases. This exhaustive monitoring has required new communication capabilities through the Web of Things, which has been optimized with the use and improvement of a set of communications patterns.


Introduction
At present, the continuous development of Information Technology and Communications offers a range of possibilities large and versatile enough to meet the needs of contemporary society in the creation, management, maintenance and dissemination of information. However, new needs appear constantly, for which we must provide solutions that offer to its potential users, a number of services that meet, as far as possible, those needs, while anticipating new requirements that may arise in the future.
In the transportation of goods, there are many products and services offered today, but there is a non-stop appearance of new ideas and solutions through the use of Information Technology and Communications, to facilitate and improve productivity in the work related to the various processes that are encompassed within this sector. So much so, that research in the field of Intelligent Transportation Systems (ITS) has long been one of the booming industries in the sector of informatics and communications, and where a constant investment in its development exists, carried out by numerous companies, government agencies and even states themselves.
In recent years, many of these solutions have been integrated into all types of freight vehicles [1]. In this regard, one of the more popular services among the companies involved in logistics has been the implementation at various levels, of several approaches for fleet management. These systems, based on the use of global positioning technologies and communications, such as Global Positioning System (GPS) and Global System for Mobile Communications/General Packet Radio Service (GSM/GPRS), respectively, are able to indicate the position of each vehicle that a particular fleet has and provide some additional information regarding various aspects relating to vehicles in which communications systems have been installed.
However, the current trend leads to systems which go one step further, allowing the tracking of vehicles, the implementation of intelligent control on the charge status and identifying the products being transported at one point.
In this paper, a proposal based on sensors that integrate next generation connectivity for smart objects or smart things (6LoWPAN, IPv6 Low power Wireless Personal Area Network) and radio frequency identification technology (Radio Frequency Identification-RFID) will be presented. Specifically, the solution lays in using Sun Small Programmable Object Technology (SunSPOT), developed by Sun Labs, currently owned by Oracle, which conveniently has been extended to support RFID integration and access to information through a set of services based on Representational State Transfer (REST), and presents a novel system based on the Internet of Things (IoT) that enables monitoring, tracking, tracing and control of road transportation, with the aim of obtaining high-level management, helping to fulfill the respective legislation on traceability of products, and ensure safe transportation process and being capable of ensuring the good condition and quality of shipped products. However, the use of nomadic devices in the interior of cars and trucks supposes a scalability problem as the number of services grows [2].
Several commercial products and ad hoc solutions have been developed for improving fleet management in logistics companies. As a next step in this frame, the ICT application in the supply chain is extending towards better control not only of vehicles, but also of products. The research world in ITS, electronics and food technologies has worked during the past years on this issue, even overcoming tracking approaches to monitor the product status by means of sensor systems.
Technological advances for improving efficiency should attend to three key challenges for managing goods [3]: tracking, tracing and monitoring (TTM). The most extended one, tracking, focuses on the ability to locate vehicles and freight at any time. Tracing allows logistics companies and even final consumers to know movements of goods from the source to the final destination point. Finally, the most recent challenge is continuous monitoring, which enables logistics companies to assure product quality during transportation. Among the technologies that are being applied in TTM solutions, new short-range wireless communications require special attention. RFID technologies play a key role in the detection of products, by means of a tagging scheme where a reader identifies products at a distance of meters.
The platform presented in this project proposes a comprehensive solution to the problems discussed in the articles above by installing an arch with multiple RFID readers at the loading area of the truck, as proposed in [4]. In this case, pallets, or boxes containing products are marked with RFID tags that integrate technology and incorporate an Electronic Product Code (EPC) associated unambiguously to identify any object to which they are attached, thus an item can be detected when it enters or leaves the loading area of the truck when passed through the arch, allowing comprehensive management of goods. However, the developments described above for these systems, lead not only to control the traceability of products, but also to monitor the load and the surrounding environment. Using the experimental SunSPOT technology, this project examines to meet the needs of monitoring and identifying perishable goods and foodstuffs during transport.
Vaccines, drugs and clinical trials products need to be shipped within a prescribed temperature range to maintain their efficacy as well as food to maintain its freshness. Active RFID allows having a complete history of the temperature exposure of the perishables thus allowing predicting the remaining shelf-life [5]. The pharmaceutical and food industries can use this data to calculate when to replenish perishables and how much product to put on shelves. The benefits of applying RFID and sensors to perishable goods include improved food and drugs safety, longer vaccines and drug efficacy, more efficient product recalls, reduced costs due to less spoilage, lower inventories, more efficient logistics, and improved customer service.
The proposed system integrates secure identification and offers RFID tracking and tracing through a distributed architecture for heavy goods vehicles, while the environment in which the goods are transported is continuously monitored (temperature, humidity and lighting) through the use of active sensors embedded in the SunSPOT nodes, benefiting from the flexibility they offer when it comes to be deployed and configured wirelessly. In addition to the sensors integrated directly into the plate external sensors are used to extend the functionality and versatility of the system. In this regard, it is possible to install new sensors through, on the one hand, digital and analog inputs and outputs, and on the other hand, the serial communication port (USART) integrated in SunSPOT. It is intended, therefore, to develop a tracking, monitoring and traceability system for the transport of goods that meets the following objectives: 1. Develop a comprehensive system that offers a flexible architecture and easy integration, while being scalable according to specific needs. 2. The architecture will be composed of entities that maintain a high level of homogeneity, in order to facilitate the tasks of development, system configuration and deployment in environments with high heterogeneity. 3. Access to services for monitoring, tracking and traceability may be required during the course of goods transportation. To this end, it must not be limited to offering these services only at specified times (loading and unloading of products, beginning or end of route, etc.), but services should be accessible en-route. To this end, a series of developed Web Services through the integration of REST technology will support this functionality. 4. Moreover, in addition to meeting the needs of monitoring, tracking and traceability described above, there is the need to provide appropriate services to carry out an exhaustive item-level monitoring for cases in which the importance of maintaining a certain product within a temperature range, humidity and/or lighting conditions is an important factor. 5. It will be necessary to consider various aspects of security related to identification of products through wireless identification technology, as well as in regard to external communications. 6. Different ways for resource access will be provided, in order to make the system as flexible and versatile as possible. This will offer end users the opportunity to set their own mash-ups for access to information, depending on the role they play in gaining access to it, being also possible to easily configure remote control server applications.

Related Works
Beyond the simple management of vehicles, which comprise a fleet, at present, certain ways of work are essential, related not only to the management of the vehicle itself, but going a step further, related to goods carried within them. Therefore a new set of technologies is necessary to meet the needs that allow us to be able to offer services that enable monitoring, tracking and traceability of products contained inside the cargo area of vehicles that come into play to implement this new solution.
For the tracking tasks described above, GPS technology has already been well established, by which it is possible to determine the absolute position of a particular vehicle, whose position can be associated with an existing map, obtaining additional information about the path that the vehicle on which the receiver is installed.
With regard to the tasks of traceability and monitoring, there are a variety of open fronts in order to find optimal ways for both the development of a traceability system, which can trace the road made for a certain product during transport at all times and for the implementation of a monitoring system which, through sensors within the cargo areas of vehicles, offers the possibility of knowing the state of environment in which a product is immersed at a precise moment. As mentioned above, one of the main objectives of the proposed solution is to reach a level of comprehensive item monitoring and tracking.
Especially relevant is the intention expressed by the European Union to regulate the transport of goods such as pharmaceuticals, food, animals and dangerous goods [6]. To this end, it is necessary to implement a comprehensive system of traceability in the food and pharmaceutical businesses, together with the services provided by transport companies, able to carry out specific and precise withdrawal of products, or to inform consumers or control officials and avoid further unnecessary disruption in the case of food safety problems and/or care, thus ensuring that in a situation like this, it will be possible to identify the source that supplied the drugs, foods, animal feed or substances that can be incorporated in a food or feed, and to ensure traceability at all stages allowing for an investigation. Furthermore, the support from the European Union is clear, with financing of several actions in the area of ITS such as the ITSSv6 project. The objective of the ITSSv6 project is to develop a reference open-source IPv6 ITS Station stack freely available to European and national third parties (projects, industry and academia) using IPv6 for Internet-based communications in Field Operational Tests (FOTs) of Cooperative Systems. The project aims at further specifying the concept of the ITS Station as standardized by ISO TC204 WG16 (CALM) and ETS TC ITS with brushed up existing and additional IPv6 features required for operational deployment of Cooperative Systems, i.e., enhanced performance, embedded security, remote management of deployed systems and ease of configuration. The project takes as an input the FP6 CVIS core communication software and additional modules developed by FP7 GeoNet and produce an enhanced IPv6 ITS Station stack adapted to operational use in large scale Field Operational Tests. From a specification viewpoint, the IPv6 features are well integrated within the overall ITS Station architecture (particularly ITS Station management and ITS facilities). As a result, the IPv6 software release fits nicely with recommended physical interfaces (802.11p and 3G) and benefit to Cooperative Systems applications (road safety, traffic efficiency and infotainment types of applications which require Internet communications).
Coming back to the technologies involved in ITS solutions, it is clear that the development of different navigation and communication techniques has greatly enriched the solutions for the monitoring of ground transportation and fleet management. In this sense, many works deal with proposals for integrating various technologies in freight systems, and to improving the efficiency of supply chains. Among them, the radio frequency identification technology and wireless sensors (obeying the guidelines of the IEEE protocol 802.15.4) occupy, at present, the areas of greatest interest in research on these issues. In [7] an indoor traceability system for direct application in stores is described. This case study is exploited in [8], and also incorporates a system of decision support for container management in a warehouse. However, with required tasks, either tracing or tracking, RFID by itself is unable to meet the economic requirements and effectiveness, because of the need to deploy a large and expensive infrastructure of readers. Referring to this, in [9] some major challenges to overcome in the global adoption of RFID technology are presented. Related to Wireless Sensor Networks, there are interesting works focused on the implementation of real-time data management protocols as exposed in [10] The evolution of tracking and tracing systems has been directed towards monitoring the freight status [11]. Applying SunSPOT [12], this research examines how to meet the needs of monitoring, identification and control during the transportation process of perishable goods and food products. The system integrates secure RFID identification and traceability in a distributed architecture for trucks while maintaining monitoring of the environment in which those goods are involved (temperature and lighting) based on active sensors that every SunSPOT node implements, taking advantage from the benefits and versatility these motes offer.
In terms of the evolution of communication technologies, in conjunction with the development of new devices such as wireless personal devices, embedded systems and smart objects, mixed together with the innovation of the services with the definition of cloud computing, online services, and ubiquitous access to information, an extension of the capabilities of the current Internet is defined, that make feasible connecting to the Internet all the objects and devices which are found surrounding us, the so-called IoT [13], which is one of the Future Internet foundations. The objective of IoT allows systems to gain total control and access to other systems leading to the provision of ubiquitous communication and computing. Thereby a new generation of smart and small devices, context awareness services and applications can be defined.
The mentioned tremendous increase of the use of Internet, from some 360 million users in 2000 to 1.6 American billion Internet users and 4 American billion mobile users with over 570 million Internet-enabled hand-held devices is only the beginning, since it is estimated that the extension of the Internet to smart things, will reach by 2020 between 50 to 100 billion devices connected to the Internet [14]. This growth have led to the IPv4 address exhaustion at the beginning of 2011 prompting enterprises and academia to begin implementing, integrating and moving to IP Version 6 (IPv6), the next-generation Internet protocol which presents an increase of the Internet capabilities and addressing space. Related to that, some approaches related to this topic, taking advantage of these new capabilities are exposed in [15]. This grows of the Internet presents serious problems for scalability, manageability, addressing/identity, and robustness, and the openness and ubiquity features of the Internet presents problems to offer a suitable support for security, privacy, and secure mobility, especially in cases where the information involved in the process is extremely compromised, such as clinical environments [16]. Therefore a new redesign of the Internet architecture and definition of new security aspects are required to solve the mentioned problems for the Future Internet of Things [17]. For this purpose, several projects from industrial and international collaboration are being carried out to define the Future Internet architecture, which solves the limitations of the current architecture [18].
The Future Internet of Things presents the requirements of managing security and privacy, which present several changes, since on the one hand, the innovative services and solutions considered for the Future Internet require a global interoperability and mobility support, but on the other hand requires a separation between the global networks and from the edge networks, since they are highly constrained in terms of computational capabilities, memory, communication bandwidth, and battery power, which present vulnerabilities for the security and privacy problems addressed in the current Internet [19]. 6LoWPAN offers the Future Internet of Things all the advantages from the Internet Protocol (IPv6) such as scalability, flexibility, ubiquity, openness, and end-to-end connectivity, and it could be also considered ideally that 6LoWPAN devices are powered with the current Internet protocols for management, e.g., Simple Network Management Protocol (SNMP), and security, e.g., IP Security (IPSec). However it is not feasible for the 6LoWPAN devices to be associated with host-based protocols because of the mentioned constrains.
Therefore, with the mentioned constrains and requirements from the Internet of Things for security, privacy, mobility and scalability, an architecture which addresses and solves all these issues is required, incorporating a specific design for solutions and protocols.
In the following sections the solution adopted is exposed, taking into account the needs and considerations determined after a process of analysis of the studies mentioned above, with particular emphasis on what have been the strategies and/or technologies chosen to satisfy the requirements and main objectives of the described problem. In Section 3, the overall architecture is exposed, giving a general explanation of the solution developed, and in the next subsections how the different devices and sensors used have been integrated in order to carry out the work is explained. Section 4 describes the different technologies and approaches considered in order to fulfill all the information access and treatment requirements. Section 5 introduces a specific evaluation for the proposed architecture, in order to show how it meets the requirements and how it is possibly to manage it in a clearly and transparently manner and finally, in Section 6, final conclusions are given.

Overall Architecture
The proposed tracking and monitoring architecture, which entirely consists in SunSPOT nodes, and was developed under this project, is presented in Figure 1. It comprises the Trailer Control Unit (TCU), which shows the great homogeneity level achieved by the use of this technology in which lighting and temperature sensors, in addition to the RFID reader rack connected to the node located at the trailer loading door. Different sensors are integrated directly in each monitoring entity compared to other proposed architectures where each sensor could implement a different technology, leading to heterogeneous systems, making deployment and configuration processes more difficult.

Tracking and Monitoring Architecture
The deployed nodes offer IPv6 over IEEE 812.15.4 connectivity allowing direct access through any device with Internet connectivity. Additionally, integrating RFID technology into our system gives us the ability to uniquely identify the products that enter, exit, and that are found inside the truck at any point by reading the Electronic Product Code (EPC) present in the RFID tags attached to them. Thus, the system is able to provide tracking and monitoring services in an efficient manner. As previously mentioned, the architecture also has a dedicated monitoring system, based on active tags tracking the item-level status of the goods with its corresponding UHF dedicated readers for making this task feasible.
In order to make it even more accessible the data recorded by the system, in agreement with the philosophy of Internet of Things, can be accessed through Web Services technology that integrates REST, i.e., the previously mentioned Web of Things Architecture.
REST-style architectures consist of clients and servers. Clients initiate requests to servers; servers process requests and return appropriate responses. Requests and responses are built around the transfer of representations of resources. A resource can be essentially any coherent and meaningful concept that may be addressed. A representation of a resource is typically a document that captures the current or intended state of a resource.
At any particular time, a client can either be in transition between application states or "at rest". A client in a rest state is able to interact with its user, but creates no load and consumes no per-client storage on the servers or on the network. The client begins sending requests when it is ready to make the transition to a new state. While one or more requests are outstanding, the client is considered to be in transition. The representation of each application state contains links that may be used next time when the client chooses to initiate a new state transition.
REST was initially described in the context of HTTP, but it is not limited to that protocol. RESTful architectures can be based on other Application Layer protocols if they already provide a rich and uniform vocabulary for applications based on the transfer of meaningful representational state. RESTful applications maximize the use of the pre-existing, well-defined interface and other built-in capabilities provided by the chosen network protocol, and minimize the addition of new application-specific features on top of them.
The application of this technology manages to offer client-server architecture in which web services are seen as resources and can be identified by their URIs (Uniform Resource Identifiers). Different operators wishing to access these resources can create the data represented the way most convenient to them, accessing them through a series of defined methods that are responsible for providing the required information, while offering the possibility of remotely modifying these data in the event of a necessary operation. Thus we synthesize information so that it can be automatically processed by applications that make use of the offered methods.
External communications will be through the integrated on-board unit in the truck OBU. This module will be responsible for acting as a gateway between the network infrastructure deployed inside the truck and the external data network via GPRS communication module.

SunSPOT Platform
SunSPOT is an embedded platform with the aim of optimizing Java technology applications over Wireless Sensor Networks based on IEEE 802.15.4 ( Figure 2). This present several advantages with respect to the previous nodes and devices found in the market for the development of sensor networks, such as high performance microprocessors based on ARM from Atmel, instead of the usual constrained solutions defined previously in the market, and mainly its extension of the current local communication domain to an IPv6-based global domain.

Sensors 201
Finally, t are the rea other feature hardware an applications written in Ja offers suppo The curre Java VM Sq designed to b The selec has an eSPO USB connec SPOTs (and board with a Figure 3 sho this offers a asons that es and adva nd software is such as ava. In addit ort for Mesh ent configur quawk and be a flexible cted configu OT main boa ction to a h any other I a rechargeab ows the SunS      When ext field), there of data sets see Table 2 Related t nformation Things appr 2, 12

Sensors Integration
The sensorised SunSPOT nodes used in our solution are responsible for regularly recording temperature and lighting values inside the truck. This task is done using the integrated temperature and lighting sensors of each sensorised node.
The Analog Devices ADT7411 ADC integrated in each SunSPOT node, converts analog inputs from the accelerometer, light sensor, and its own internal temperature sensor to digital values that can be read by SPOT applications. The ADC is also available to encode analog inputs from pins A0, A1, A2 and A3. In this way, some other sensors may be attached to the SunSPOT nodes in order to add new functionalities and measurement possibilities to the monitoring system in an easy manner.
Related to the temperature sensor, the ADT7411 ADC contains an internal temperature sensor that is capable of measuring temperatures in the range −40 to +125 degrees Celsius with an accuracy of 0.25 degrees Celsius. Because the temperature sensor is part of the ADT7411 chip, it actually measures the temperature on the chip, which is generally slightly different than the surrounding environment, especially during USB charging. The sensor gives the most accurate temperature readings immediately after the SunSPOT wakes up from deep sleep, when not connected to a USB.
The lighting sensor is mounted on top of the eDemo board. It is a Toshiba TPS851 light to voltage sensor. Output of the sensor is 0.1 V to 4.3 V, dark to light, using an emitter resistor of 4.7 K (R4). This voltage is buffered by op-amp U3 and divided by two resistor dividers R5 and R9. Output of the resistor divider is input to channel 5 of ADC U4 with an effective range of 0.05 V to 2.15 V. Peak sensitivity of the light sensor is 600 nm > 3dB sensitive is about ±45 and switching time is about 30 μsec.

Externally Integrated Sensors
There has been integrated several external sensors through the USART communications port, concretely a light sensor and a temperature and humidity sensors have been used, both described in the following lines.
A TAOS TSL2550 light sensor has been integrated. This is a digital-output light sensor with a two-wire serial communication interface. It combines two photodiodes and an analog-to-digital converter (ADC) on a single CMOS integrated circuit to provide light measurements over an effective 12-bit dynamic range, with a response similar to that of the human eye.
Related to the temperature and humidity sensor, a Sensirion SHT11 single-chip multi-sensor module has been used for measurement of temperature and relative humidity. The device includes two calibrated micro-sensors for temperature and relative humidity, which are coupled to a 14-bit analogue-to-digital converter and a serial interface circuit. Conversion may be programmed with 8-, 12-or 14-bit accuracy, depending on application resolution or speed requirements. Humidity is measurable over 0-100% relative humidity, and temperature over the range −40 °C to 85 °C.

Remote Access and Client Services
Different services and applications have been developed to provide access to information in a manner best suited to the requirements to provide a particular service. In Figure 9, an explanatory chart describing the different technologies used to support these services and applications is shown. The following subsections describe the various technologies used in each part of the architecture and how, through the combination of these, the different services described can be provided.

Embedded Web Services
While the Internet protocol ties together heterogeneous networks into the Internet, the Web is a loosely coupled application layer architecture. Resources are key to the web architecture, which are server-controlled abstractions made available by an application process and identified by URIs. These server controlled resources are accessed by clients in a synchronous request/response fashion using methods such as GET, PUT, POST, and DELETE of HTTP. Resource state is kept only by the server, which allows for the caching, proxy, and redirection of requests and responses. Web resources may contain links to other resources, which create a distributed web between Internet endpoints, resulting in a highly scalable and flexible architecture. These core web concepts are commonly described as Representational State Transfer (REST) [20]. Today, HTTP is almost exclusively used on today's Internet for manipulating web resources, although REST can also be realized with other application protocols.
The web is usually used by humans to access hypertext (HTML) and other media via web browsers; however, more often the web is used for communications between machines. Interoperable communications between machines on the Internet is often achieved using web services. There are two general ways of realizing web services: applying REST for the manipulation of resources using HTTP, or via Remote Procedure Call (RPC) style interactions using, say, the Simple Object Access Protocol (SOAP).
RESTful web services make use of HTTP to access resources, and may be formally described using, for example, the Web Service Description Language (WSDL) or Web Application Description Language (WADL). An HTTP request message is first sent from the client to the server. The client specifies the resource on the server to request in the form of a URI and method (GET, POST, PUT or DELETE). The server responds with a possible response body and a code ( Figure 10). HTTP is able to carry an arbitrary payload using any MIME type and encoding. The body of the HTTP web service message is in a format known by the client and server, often XML following a mutually understood Schema. When designing interoperable communications for constrained embedded devices, the RESTful paradigm has many advantages over RPC style interactions. These include less overhead, less parsing complexity, statelessness, and tighter integration with HTTP. Figure 10. Comparison example between Web Architecture (left) and its mapping to a REST Architecture (right).

Constrained RESTful Environments (CoRE)
CoRE is a recent working group at IETF providing a framework for resource-oriented applications intended to run on constrained IP networks. A constrained IP network has limited packet sizes, may exhibit a high degree of packet loss, and may have a substantial number of devices that may be powered off at any point in time but periodically "wake up" for brief periods of time. These networks and the nodes within them are characterized by severe limits on throughput, available power, and particularly on the complexity that can be supported with limited code size and limited RAM per node. More generally, we speak of constrained networks whenever at least some of the nodes and networks involved exhibit these characteristics. Low Power Wireless Personal Area Networks (LoWPANs) are an example of this type of network. Constrained networks can occur as part of home and building automation, energy management, and the Internet of Things.
The CoRE working group will define a framework for a limited class of applications: those that deal with the manipulation of simple resources on constrained networks. This includes applications to monitor simple sensors (e.g., temperature sensors, light switches, and power meters), to control actuators (e.g., light switches, heating controllers, and door locks), and to manage devices.
The general architecture consists of nodes on the constrained network, denominated "Devices", that are responsible for one or more Resources that may represent sensors, actuators, combinations of values or other information. Devices send messages to change and query resources on other Devices. Devices can send notifications about changed resource values to Devices that have subscribed to receive notification about changes. A Device can also publish or be queried about its resources. Typically a single physical host on the network would have just one Device but a host might represent multiple logical Devices. The specific terminology to be used here is to be decided by the working group. As part of the framework for building these applications, the working group will define a Constrained Application Protocol (CoAP) for the manipulation of Resources on a Device [21].
CoAP will be designed for use between Devices on the same constrained network, between Devices and general nodes on the Internet, and between Devices on different constrained networks both joined by an Internet. CoAP targets the type of operating environments defined in the ROLL and 6LOWPAN working groups, which have additional constraints, compared to normal IP networks, but the CoAP protocol will also operate over traditional IP networks. One view of the CoRE architecture is shown in Figure 11.   The use o Figure 17) of web app he appropri nformation

Block Options
There exist two different configurations for Block options, named Block1 and Block2 options, both of which are present in request and response messages. However, Block1 is used in request payload operations, while Block2 is used in response payload operations.
Said that, Block1 is useful with payload-bearing POST and PUT requests and their respective responses. On the other hand, Block2 is indicated with GET, POST, and PUT requests and their payload-bearing responses.
Whether the Block1 or Block2 options are used or not, there exist three items of information that may need to be transferred in a Block option: the size of the block (SZX), whether more blocks are following (M), and the relative number of the block within a sequence of blocks with the given size (NUM). Such fields are described in deep in the following lines: • NUM field: is a variable-size unsigned integer that indicates the block number being requested or provided. Block number zero indicates the first block of a body.
• M field: if unset, indicates that the payload in the message is the last block in the body, if set, it indicates that there are one or more additional blocks available. In case that is being used a Block2 Option in order to retrieve a specific block number, the M bit must be sent as zero and ignored on reception.
• SZX: Block Size. The block size is a three-bit unsigned integer indicating the size of a block to the power of two within the limitations described above.
The block size (SZX) is conveniently encoded as a 3-bit unsigned integer with possible values between 0 for 2^4 to 6 for 2^10 bytes, so the actual block size is then 2^ (SZX + 4). This field is transferred in the three least significant bits of the option value. The fourth least significant bit represents the M (More) bit, indicating whether the current block-wise transfer is the last block being transferred, or more blocks are following. Finally, the NUM field is the sequence number of the block currently being transferred, starting from zero.
The default value for both options is zero, indicating that the current block is the first and only block of the transfer, however, there is no explicit size implied by this default value.
It could be useful to implement Block when a REST operation is performed and it is expected that the output will be extremely heavy in terms of data transmission. For example, when an INVENTORY request is done, in order to get all the tags detected inside the trailer, the process of transferring al this information through a constrained network environment could be very overwhelming It is shown, how satisfying the structure presented in Section 3.2, finally the payload is very constrained in size so applying even more fragmentation could be even worse. Due to that, in order to avoid operations that could cause fragmentation at network level, with the implementation of a block-wise pattern it is possible to carry the fragmentation from network to application layer, being possible to transmit just the explicitly solicited blocks.
With the application of this design patterns it is possible to implement high-level searching techniques such as memory search approaches, leading to future feasible options for optimizing data recovery processes based on Internet of Things.

Conditional Block-Wise
It is considered interesting to introduce a second, and novel, level of fragmentation in order to improve the efficiency of INVENTORY operations such as requesting all the tags read by the RFID reader, but just those of them that fulfills determined precepts. As an example, sometimes it is necessary to check if the amount of products contained inside the truck, belongs to a concrete range of product identification numbers. For this case, it is possible to request all the products whose EPC belongs to a concrete range of product codes in order to obtain certain information about them. This allows getting a specific family of products (e.g., from a milk products shipment only get the list of a specific kind of yogurts).
This implementation is relevant in scenarios where there could be different types of tags, with different EPC ranges that define different types of packaging methods. In this case, it could be interesting to identify just the pallets inside a truck that are containing an specific type of box/product, or just the boxes inside the cargo area that are containing an specific subset of products (see Figure 20).

Remote Control Server
At the same time as the various resources located in the Nano Application Server running on each node can be accessed through the website developed for this purpose, these resources can also be accessed, consulted and/or modified through the use of platforms such as cURL (Figure 21), which offers the possibility for executing queries in an equally intuitive manner, but also enabling the system to access in a lower level the various resources available in order to support information needs and collection of more detailed data. Thanks to this, it is possible, for example, to carry out the execution of scripts that will be responsible for collecting some information from the various nodes deployed periodically  In the registration step, a client can register its interest in a concrete resource offered by the server by performing a GET operation, including an empty Observe Option. In a successful operation the server should return the response, including an Observe Option as well, notifying in this way that the server has subscribed the client to the local list of observers interested in the value or resource requested, so the client will be, since that moment, notified of every change that takes place over this concrete target.
Notifications are additional responses sent by the server replying an initial GET request. For each notification received, an Observe Option with a concrete sequence number, a Token Option, and a payload of the same media type as the initial response will be included. Notifications can be confirmable or non-confirmable, on this way, if a client could not recognize the token in a notification; it must not acknowledge the message, rejecting it with a RST message. Otherwise, an ACK confirmation message will be send.

Conditional Observe Pattern
As seen, when an observe pattern is used CoAP clients can obtain a notification response whenever the observed resource changes. However, sometimes it could be necessary just to get a response when the resource value varies between defined ranges, or a concrete situation happens about which one wants to be notified. This situation could be achieved using a Conditional Observe Option avoiding irrelevant and unnecessary traffic. On this way, Conditional Observe allows implementing an Observe request where notifications will only sent when the established condition occurs [26].
With this new implementation of Observe, the option includes the desired condition for being notified by the server. Thus, when the resource state changes on the server, before sending the notification directly to all its subscribers, it checks the condition previously established, sending the notification only when it is necessary. In order to offer the Conditional Observe, the server needs to follow the general Observe procedure, as described before, but taking into account the special requirements for the Condition option. Since this option is elective, if the server does not support the Condition Option, it will automatically execute a standard Observe procedure. Condition options could be present more than once, meaning that the client has multiple conditions for notification requirements. The following fields compose a Condition option: • TYPE field: defines the condition type. This type is represented by a 4-bit integer, indicating the type of condition being used in the Observe request. Each number of TYPE, represent the type ID of a specific condition type (See Table 3).   When operating with the simplest approach, based on continuous requests to the sensor, the number of request messages raises to 4,718 with a total amount of 9,436 messages between client and server (i.e., 4,718 requests and their respective replies). In addition, the sensor is continuously sending and receiving data so the battery levels would decrease very fast, reducing the life-time of the sensor due to an ineffective mode of operation. However, in case of using an Observe pattern, the number of necessary requests descends drastically because there is needed only one subscribing operation in order to be informed for future values, keeping in mind that data, will only be send in case that the sensor detects a change in the measured resource. In this this case, there are needed just 612 messages sent by the server in order to notify the client and satisfy its subscribing requirements, meaning a reduction of the network usage (See Figure 30). Furthermore, in the following figures the performance of the system will be shown with different communication protocol implementations, concretely, there are shown the different behaviors when different Conditional Observe options are applied (i.e., Minimum Response Time, Step and Range Options). Note that, a Condition Option, is present together with the standard observe request, representing the condition required by the client. Then, the server needs to follow the general procedure as described for the Observe pattern, but taking into account the Condition Option desired.
In the case of using a Conditional Observe with a Minimum Response Time Option, the number of messages could be reduced or increased proportionally to the time established for sending a notification. Figure 31, shows an example of this implementation, with a Minimum Response Time of 15 seconds, instead of the default sensor configuration, established in 3 seconds.
As shown, it is noticed that the number of necessary messages sent by the server decreases substantially, for the Minimum Response Time established, the total amount of messages sent is 137, and just one from client to server, in order to register its notification conditions.
Regarding to the Step Option, we can define the minimum state change of the desired resource before the server needs to send a notification response. In this case, it has been established a Step Option to 0.5 °C. Figure 32, shows the number of messages sent by the server for this concrete case, having a total amount of nine notifications, with just one necessary request by the client, with the desired options.  Finally, it is shown how thanks to the Conditional Observe, it is possible to reduce even more the number of messages needed, in order to be informed just in case of trespassing critical ranges, reducing the total amount of necessary transactions to the number of 222 (See Figure 33). In this case, two different conditions have been established, in order to be notified when the temperature values are above 19.0 °C or below 17.0 °C. For the same dataset, it is clear how implementing different methods it is possible to reduce the load of the network about an 87% using an Observe pattern, in comparison with an standard continuous request approach, and finally, with the addition of conditional operations it is possible to reduce even more the number of necessary messages, always depending of the concrete configuration and notification requirements. Table 5 shows the behavior of the different protocols summarizing the different approaches discussed when applied to the initial temperature dataset. Considering the results, it is shown how it is possible to adjust the protocol in the more appropriated way in order to be sufficiently informed in different situations, such as a concrete time interval (i.e., Minimum Response Time option), when the value change is greater than a determined step (i.e., Step option), or about desired or critical situations within a range (i.e., Range option), instead of being notified at every value change or irrelevant situations in a continuous manner.

Conclusions
This paper has presented how, involving several technologies from ICT, in conjunction with electronic devices already integrated in the ITS solutions such as GPS/GNSS and GPRS, it is possible to meet the requirements and extend the possibilities of the new-age logistics facilities, offering a wide and versatile enough range of applications and services in order to ensure the quality of the products shipped, making the management tasks and transportation process easier and more efficient.
This project considers the ITS platform defined under the previous works carried out in the frame of the Spanish project SATELITES, where it was built the On-Board Unit of the architecture. Under this work has been designed the Trailer Control Unit, together with the integration of SunSPOT technology. This work has presented the integration of the different sensors and RFID readers in SunSPOT nodes. The system presented fulfills the objectives for reaching a comprehensive and flexible solution that eases integration and deployment processes, in order to make them scalable. Moreover, this offers high homogeneity level entities, facilitating system configuration tasks in environments with high heterogeneity features through IPv6 connectivity and the RESTful embedded Web Services. Thereby, access to traceability, tracking and monitoring services is available anytime during the course of the transportation of goods. With the purpose of achieving even more flexibility, several ways for accessing the information in real time with a series of Web Services RESTful and information accessing methods such as cURL through an implementation of a Nano Application Server running directly on the monitoring nodes allowing consequently both, H2M (Human to Machine) interaction as well as M2M (Machine to Machine) interaction features has been defined.. SATELITES and related works defined a solution focused on environmental monitoring and product identification. Going one step further, with this approach, based on Internet of Things, is it possible to reach an item-level monitoring, when, due to the critical characteristics of concrete products it could be necessary. For this reason there has been considered some design aspects in order to fulfill this new scalability requirements when necessary. An example of that design aspects are the Block-wise, Conditional Block-wise and Observe communication protocols with its different configuration options for the concrete case of Conditional Observe implementations. On this way, novel implementations based on this pattern have been presented and proposed in order to improve communication aspects and adapting the system to the requirements needed in constrained networks, leading to lightweight communication protocols. Moreover, it has been shown that following the guidelines of network usage improvement in terms of efficiency, and network load reduction, it is possible to optimize resources in order to establish and maintain communication processes in a lightweight manner.
The proposed platform based on Internet of Things allows for a new set of different applications that could be defined, taking advantage of the incremental device intelligence and its communication possibilities leading to a full-duplex communication between the monitoring entities and the goods itself without having to rely on other entities, increasing autonomy, and increasing scalability, which is highly required having in consideration the fact that the Future Internet will be composed by every-nature embedded devices with network access, bridging the everyday smaller gap between real and virtual worlds.
However, this process leads into multiple technical issues and requirements that need to meet, especially when constrained environments take part in this. For this reason, it is necessary to reach unified architectural solutions to make every resource accessible in a straightforward and standard manner, obtaining a scalable continuous monitoring system with the use of the new technologies from the Internet of Things. Next steps in our research work pass through an exhaustive analytical and empirical evaluation in order to obtain a reliable performance evaluation process for measuring the different aspects involved in the area of continuous monitoring, tracking and traceability of goods, and the evaluation of the presented patterns over new protocols such as GLoWBAL IPv6 [28], which are defining a new generation for the communications based on IPv6 for Wireless Sensor Networks.