Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x
Top   in Index   Prev   Next

TR 22.836
Study on Asset Tracking Use Cases

V17.1.0 (Wzip)  2019/12  14 p.
Rapporteur:
Mr. Berisot, Thierry
NOVAMINT

Content for  TR 22.836  Word version:  17.1.0

Here   Top

1  Scopep. 5

The present document describes asset tracking use cases and identifies new potential service requirements as well as new KPIs to be supported by 5G communication services for asset tracking.

2  Referencesp. 5

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
Up

3  Definitions, symbols and abbreviationsp. 5

3.1  Definitionsp. 5

For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.

3.2  Abbreviationsp. 5

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

4  Overviewp. 5

As every organisation owns assets (machines, medical devices, containers, pallets, trolleys …) and as an asset can be an (extremely) valuable one, the assets tracking represents a huge market (billions of units). These assets are not fixed: they are continuously transported all over the word by different kind of vehicles; and they are continuously moved inside different kinds of buildings.
The ownership of the assets changes many times as different stakeholders take possession of some assets and pass it on to different stakeholders all along a supply chain and any value chain.
The values of these assets are not fixed as it changes all along a supply chain and any value chain. The development of the sharing economy means one asset is used by different people, so increases the need of tracking the asset.
So, every organisation needs to be able to track them anytime and anywhere (Indoor & Outdoor) in a global and multi modal context (sea, air, road, rail…).
Assets tracking includes several very different and distinct use cases such as pallets, trolleys, crates, containers, parcels, security assets but as well luggage, vehicles and even animals (Pets / Farm livestock) tracking.
The assets tracking topic is much more than just location; it includes real time monitoring of several elements or factors depending on the asset and its content if relevant (condition of the asset, environmental factors - temperature, shock detection, events…). It requires low cost IoT approach for which the two paramount requirements are coverage (need to support full coverage: Indoor / Urban/ Rural area/ Harsh environments / Metallic obstructions…) and battery consumption efficiency (designed to cope with 15 years' lifetime without changing the battery or the UE).
Incorporating the support of these new requirements into 5G and mMTC will contribute to improve the 5G system.
Up

5  Use casesp. 6

5.1  Use case for Container Trackingp. 6

5.1.1  Descriptionp. 6

There is no anymore one company in the world that does everything in- house: everyone outsources, offshores, and is a contractor and a subcontractor at the same time. Everybody is integrated in one or many different supply chains, being a local cluster or complex worldwide process.
And it's the container that keeps the supply chain and the world trade moving on.
Improving container tracking and supply-chain management is a top priority.
Technological innovation is seen as the crucial part of supply-chain management and container tracking by 93% of the executives of this business to increase efficiency, lower costs and improve effectiveness. It is therefore critical for the industry to have a total visibility on the cargo for the whole trip and identify what happen, when and where. This could also trigger contingency plan if necessary.
There are different sizes for containers but most of the containers have standardized sizes allowing them to be carried by boat, trucks or railway:
  • either 20 feet (6,058 m) or 40 feet (12,192 m) long
  • 8' (2,438 m) wide
  • 8'6" (2,591 m) tall
Most of the containers are closed and "dry freight" containers made from either aluminium or high-grade, non-corrosive and rust-resistant steel. These types of containers present doors on both ends and are mainly used for dry goods.
Beside there are also other types such as open top, refrigerated or reefer (with a power generator - used for shipment of perishable goods like fruits and vegetables), garmentainer (for clothes), tanks, half height (used especially for goods like coal, stones…), car carriers…
The whole duration of life of a container is generally between 10 and 15 years (12 years in average).
The container tracking is an essential part of the supply chain and logistics to make them more efficient. By monitoring and tracking seamlessly the container in near real-time, it allows to provide all the supply chain players and stakeholders a full traceability and to optimize the transport and the storage of containerized goods.
Any event related to a container is quickly notified and is allowing efficient analytics as well as taking related decision such as new sourcing plans if needed.
This use case describes a typical example of containers embarked in a ship and how future 5G System can help support the tracking of these containers in an efficient energy-saving approach.
Up

5.1.2  Pre-conditionsp. 7

Each container is equipped with a battery-powered IoT type UE including a 5G communication module and embedding a certain number of sensors able to monitor the internal environment of the container (accelerometer, temperature, humidity) as well as to detect critical events (physical shocks, door opening). Depending on its content and its purpose (nature of the goods transported), the container may as well have dedicated sensors (remote from the UE) such as gas detector, inside temperature (reefer).... The 5G communication module can support terrestrial and satellite access networks.
The battery-powered IoT UE should be able to operate for the entire lifetime of the tracked container (12 years) without large capacity battery packs and without being replaced during this period of time.
Depending on the service level required by the owner of the container and the supply chain associated, the container sends regular status update (could very between one message every hour to one message per day). The status update can be based on event (arrival on port for example). Additionally, based on non desired events such as shocks or door opening, the container can send an alarm to inform of the event.
A ship can be equipped with a gateway including a 5G communication module that can communicate to satellite access networks when offshore and travelling on the sea or to terrestrial and satellite access networks when on shore.
A container port or container terminal can as well be equipped with gateways including each a 5G communications module to manage the connectivity with all containers.
The size of the data payload containing the status information related to a container can be up to 2500 Bytes (example: a record of 26 bytes generated each 15 minutes and 1 connection per day). This size depends as well as the service level required by the owner of the container and the type of container and the carried goods (reefer with perishable goods for example are providing more data based on various additional sensors than a container with simple objects).
The 5G system is interfaced to an application server (e.g. Container Tracking Management System). At the beginning of each travel, a travel plan is set up for each container (though the UE) by the Container Tracking Management System depending on the level of service required by the customers of the Container Tracking Management System. The travel plan combined with the environment of the container will allow the container UE to be able to take some decisions such as positioning trigger, alerts/alarms set up, geofencing, key dates…
The payload size and the periodicity by the application are defined according to the context expected.
Up

5.1.3  Service Flowsp. 7

13.000 containers are on a ship and later on on the dock of the container terminal. In each container, the UE collects the data from both embedded sensors and remote sensors and aggregates it in packets to be forwarded.

5.1.4  Post-conditionsp. 7

All containers have provided their data, with minimal impacts on their battery and they are ready for their next travel(s).

5.1.5  Existing features partly or fully covering the use case functionalityp. 7

Reference number Requirement text Comment
5.1.5-1The 5G system shall be able to support an end-to end secured link between the UEs (containers) and the Container Tracking Management System.
5.1.5-2The 5G System shall be able to support the request from the Container Tracking Management System to the UE (container) to provide its status and tracking information periodically with an update rate ranging from one status every [60 minutes] to one status every [24 hours] (i.e. 24 messages to 1 message per day).
5.1.5-3The 5G system shall be able to support terrestrial and non terrestrial (satellite) access networks.
5.1.5-4The 5G system shall be able to support a continuity of the service through network slicing including roaming.
Up

5.1.6  Potential New Requirements needed to support the use casep. 8

Reference number Potential Requirement text Comment
5.1.6-1The 5G system shall be able to support cellular IoT/mMTC type of communications by satellite.
5.1.6-2The UE shall be able to support a payload size up to 2500 bytes per message.
Up

5.1.7  Potential Key Performances Requirementsp. 8

The KPIs attached to this use case are listed below:
Battery Life Expectancy (note 1) Typical Message size Maximum Message size Typical Frequency (number of messages per day) Typical Battery Capacity Device density
12 years200 bytes2500 bytes2421,6 Wh1,4 devices / m3
NOTE 1:
Battery life expectancy is to be assumed in all coverage conditions and is based on typical message size value and typical frequency
NOTE 2:
A large containership with a mix of 20 ft and 40 ft containers is assumed.
NOTE 3:
All the values in this table are example values and not strict requirements.
Up

5.2  Use case for Wagon Trackingp. 8

5.2.1  Descriptionp. 8

Wagon tracking and real time wagon fleet monitoring are essential part in the supply chain management. It contributes to optimize the fleet and maximizing the wagons and rolling stock use by reducing immobilization time and empty backhauling as well as providing better response to delays and stock shortage. It allows as well to design preventive and curative maintenance by measuring for example the full and empty kilometres or detecting shocks.
A freight train is comprised of one or several locomotives and several freight or goods wagons. The freight wagons can be of different variety of wagon types depending of types of goods transported such as open wagons, covered wagons, refrigerated vans, spine cars to carry intermodal containers, tank wagons, special purposes wagons (to carry coal, mineral or sand for example), …
These wagons need to be in a specific order to compose the train for example to avoid to put empties or light loads at the head end and heavy loads on the rear end but also based on different railway operator rules.
Most of the freight trains are running an average speed of 50 to 80 km/h depending on the curves of the tracks, the hills, the cargo and the length of train and usually are not going over a speed of 100 km/h (dependency on the country regulations).
A typical freight train have a length of 700 m to 1 km and are composed with between 50 to 120 freight wagons of 40 feet and some of the wagons can be double stacked. Some freight trains have even reached the length of 7 km and were composed of 600 wagons and 8 locomotives.
Each wagon needs to be monitored and tracked by its owners as well as by the freight railway operator managing the train.
The whole duration of life of a freight wagon varies from 20 years to 30/40 years and even 50 years depending on the type of wagon (and there is no power supply in the freight wagons contrary to passengers' wagons).
This use case describes a typical example of wagons attached together and how future 5G System can help support the tracking of these wagons in an efficient energy-saving approach.
Up

5.2.2  Pre-conditionsp. 9

Each wagon to be tracked is equipped with a battery-powered IoT type UE including a 5G communication module. Depending on its content and its purpose (nature of the goods transported), the wagon is including different sensors and is able to detect critical events (physical shocks, vibrations, temperature, dislocation…) as illustrated in figure 4.
Reproduction of 3GPP TS 22.836, Figure 5-1: Different sensors managed in a wagon
Up
The battery-powered UE should be able to operate for a period of 20 years without large capacity battery packs and without being replaced during this period of time.
Depending on the service level required by the owner of the goods and the supply chain associated, the wagon sends regular status update (could very between one every hour to twice a day - periodicity could even be set up to 1 min). The status update can be based on event (arrival on station for example). Additionally, based on non desired events such as shocks, the wagon can send an alarm to inform of the event. The conductor of the locomotive may need to be informed of such event to trigger right answer.
A locomotive can be equipped with a gateway including a 5G communications module that can communicate to satellite access networks.
The size of the data payload containing the status information related to a wagon can be up to 2500 Bytes. This size depends as well as the service level required by the carried goods (refrigerated vans with perishable goods for example are providing more data based on various additional sensors than a wagon for mineral transportation).
The 5G system is interfaced to an application server (e.g. Wagons Tracking Management System). The payload size and the periodicity by the application are defined according to the context expected.
Up

5.2.3  Service Flowsp. 9

A freight train is composed of 19 freight wagons of different varieties and usages. Each wagon has been tracked individually to be placed in a certain order in order to compose the train. Not all wagons may be equipped with an UE.
One of the main challenges is to communicate the information to the conductor as well with the WAN network on such a length and as the UE attached to the wagon can be in different places depending on the type of wagons. This needs to be done while still optimising the battery level of the UE attached to wagon as well as the fact that part of the train and some of the wagons can be in a tunnel where the propagation of the signal is limited. Another challenge is to communicate the information in a relative short time to allow the conductor as well as the train operator to react appropriately: 15 seconds from the time there is an event detected and the event is communicated to the locomotive.
All the communications need to be secured and only wagons that are part of the train composed are allowed to communicate between them and with the gateway of the locomotive.
Up

5.2.4  Post-conditionsp. 10

All wagons have provided their data, with minimal impacts on their battery and they are ready for their next travel(s).

5.2.5  Existing features partly or fully covering the use case functionalityp. 10

Reference number Requirement text Comment
5.2.5-1The 5G system shall be able to support an end-to end secured link between the UEs (wagons) and the wagon Tracking Management System.
5.2.5-2The 5G System shall be able to support the request from the wagon Tracking Management System to the UE (wagon) to provide its status and tracking information periodically with an update rate ranging from one status every [15 minutes] to one status every [24 hours] (i.e. 96 messages to 1 message per day).
5.2.5-3The 5G system shall be able to support terrestrial and non terrestrial (satellite) access networks.
5.2.5-4The 5G system shall be able to support a continuity of the service in roaming case.
 
Up

5.2.6  Potential New Requirements needed to support the use casep. 10

Note: All new requirements associated to communicating between wagons and usage of wagons as relay will be addressed in TR 22.866 (enhanced Relays for Energy Efficiency and Extensive Coverage).

5.2.7  Potential Key Performances Requirementsp. 10

The KPIs attached to this use case are listed below:
Battery Life Expectancy (note 1) Typical Message size Maximum Message size Typical Frequency (number of messages per day) Typical Battery Capacity Device density
20 years200 bytes2500 bytes2436 Wh0,3 devices / m2
NOTE 1:
Battery life expectancy is to be assumed in all coverage conditions and is based on typical message size value and typical frequency
NOTE 2:
All the values in this table are example values and not strict requirements.
Up

5.3  Use case for Pallet Trackingp. 10

5.3.1  Descriptionp. 10

Reusable pallets (plastic or other material) are now playing an important role in the supply chain and logistics providing a cost-effective solution and long-term return on investment while being environmentally friendly by avoiding scrap pallets and packaging waste.
Such pallets are particularly adapted for in-house flow of goods, closed circuit or cases where there is extensive flow of goods with a small number of distribution sites such as providing goods between a warehouse and several distribution sites and stores. Another strong usage of such pallet is the automotive industry for the transport of accessory and spare parts to the assembling line of a manufacturer for example. Another usage is as well the military.
Reproduction of 3GPP TS 22.836, Figure 7-1: Examples of Reusable pallets
Up
Some of the main challenges associated to the use of such pallets are the retention on site as well as the loss (or theft) of these pallets.
Therefore, tracking of pallets is important for the productivity while providing better inventory control and improved quality and the objective of pallet tracking application is to improve/optimize flow by reducing retention on site and loss or theft and to maximize the duration of use of such pallet.
The service requirements associated to this use case are the following:
  • Flows and stock management - Automatic inventory of each site as well as on transit
  • Tracking and optimization of Pallets flows
    • Per Site - tracking of every pallet per site
    • Per pallets: history of movement, duration of stay on site
    • Following transit - tracking of all pallets in transit and their position
  • Identify Loss and theft and reduce it
  • Identify Retention on site and reduce it
This use case describes a typical example of pallets and how future 5G System can help support the tracking of these pallets.
Up

5.3.2  Pre-conditionsp. 11

Each pallet is equipped with a small size battery-powered IoT type UE including a 5G communication module with a very small non rechargeable battery. For some pallets which are moving towards large area or for critical operation such as military, the 5G communication module should support low power IoT communication by satellite.
The battery-powered IoT UE should be able to operate for the entire lifetime of the reusable pallet (7 years minimum) without large capacity battery packs and without being replaced during this period of time.
The 5G system is interfaced to an application server (e.g. Pallet Tracking Management System) which can track the overall flows of all pallets it is managing.
Up

5.3.3  Service Flowsp. 11

Automotive spare parts and accessories need to be delivered from the supplier to an assembly line of an automotive manufacturer with reusable plastic pallets.
When in movement, each pallet is capturing often its location position. It is not necessary needed to send its location position all the time but it may be needed to store it on a regular basis (to be set up in function of the owner requirements - for example every 5 minutes) then to send on a less regular basis (every hour for example) a status update which include its position or all positions captured regularly since the previous status update as well as its battery status. The status update can be based as well on event (arrival on the distribution site or assembling line for example). A status update message sent every hour and aggregating the positions captured every 5 minutes has a size up to 300 bytes.
When the pallet is on the distribution site, it will continue to send regular update communicating its status and position enabling to inform when a pallet is staying longer than needed on this site or when moving outside of the zone allowed for the pallet. In this case, an alert is sent.
When they are empty (and not used), the pallets are piled up on each other. In some cases (depending on the pallet type), the pile can be composed of 20 to 30 pallets. The pallets may still communicate their status update even when piled up in order for the Pallet Tracking Management System to have an accurate inventory.
Up

5.3.4  Post-conditionsp. 12

All pallets have provided their data, with minimal impacts on their battery and they are back at their warehouse ready for next usage and the retention or loss of pallets have been reduced or limited.

5.3.5  Existing features partly or fully covering the use case functionalityp. 12

N/A

5.3.6  Potential New Requirements needed to support the use casep. 12

5.3.7  Potential Key Performances Requirementsp. 12

The KPIs attached to this use case are listed below:
Battery Life Expectancy (note 1) Typical Message size Maximum Message size Typical Frequency (number of messages per day) Typical Battery Capacity Device density
7 years300 bytes300 bytes2412 Wh4 devices/ m2
NOTE 1:
Battery life expectancy is to be assumed in all coverage conditions and is based on typical message size value and typical frequency
NOTE 2:
All the values in this table are example values and not strict requirements.
 
Up

6  Consolidated potential requirementsp. 12

6.1  Functional Requirementsp. 12

[PR 7.1-1]
The 5G system shall be able to support low power IoT/mMTC type of communications with satellite access.

6.2  Performances Requirementsp. 13

Scenario Battery Life Expectancy (note 1) Typical Message size Maximum Message size Typical Frequency (number of messages per day) Typical Battery Capacity Device density
1Containers (note 2)12 years200 bytes2500 bytes2421,6 Wh1,4 devices / m3
2Wagons20 years200 bytes2500 bytes2436 Wh0,3 devices / m2
3Pallets7 years300 bytes300 bytes2412 Wh4 devices/ m2
NOTE 1:
Battery life expectancy is to be assumed in all coverage conditions and is based on typical message size value and typical frequency
NOTE 2:
A large containership with a mix of 20 ft and 40 ft containers is assumed.
NOTE 3:
All the values in this table are targeted values and not strict requirements.
Up

7  Conclusion and recommendationsp. 13

The current TR provides a number of use cases for Asset Tracking that are significant for the topic (Container, wagon, pallet).
The resulting potential requirements and KPIs reported for each use case identified in this TR have been consolidated and can be considered for the development of normative requirements. It is therefore proposed to consider the inclusion of these requirements and KPIs in existing specifications for 5G services (e.g. TS 22.261).
Up

$  Change historyp. 14


Up   Top