Tech-invite  3GPPspecsRELsGlossariesSIP

full Contents for  TS 22.261  Word version:   17.2.0

Top   Up   Prev   None
0…   4…   6…   6.4…   6.8…   6.12…   6.22…   6.26…   7…   8…   A   B   C   D…   F…


F  QoS Monitoring [R16]Word-p. 77
F.1  QoS monitoring for assurance
This Clause discusses how QoS monitoring information can be used for assurance purposes. For background information on assurance see [19] and appendix A.3 in [20].
Assurance consists of four major steps (see Figure F.1-1 and [18]):
  • Customer's QoS requirements
  • This states the level of quality required by the customer of a service. This information is divulged to the provider.
  • Service provider's offerings of QoS (or planned/targeted QoS)
  • This is a statement of the level of quality expected to be offered to the customer by the service provider.
  • QoS achieved/delivered
  • This is the level of quality achieved and delivered to the customer. Monitoring information is divulged to the customer.
  • Customer rating of QoS
The customer can compare the QoS achieved by the provider with the QoS requirements (see above) and its own experience of the QoS. This is a crucial step for establishing assurance about the fulfillment of the customer's requirements.
This Figure is based on the trust model in [18].
F.2  Network DiagnosticsWord-p. 78
Network diagnostics helps with scanning, diagnosing and identifying problems within a network. Diagnostics includes gathering data and continuously providing sufficient performance parameters that characterize the quality of the network connection. This includes data of the physical connection as well as of logical links and sub-networks. Exposure of relevant (and possibly aggregated) performance parameters ensures a quick reaction in case of failure as well as identifying network connectivity, performance and other related problems. Network diagnostic should be able to:
  • be proactive (to early detect failures) and not only reactive (to deal with faults that have already occurred).
  • accurately differentiate malfunctions/failures and evaluate their impact on the service/network.
  • provide clear explanations about what happened.
  • suggest corrective actions, and possibly perform them automatically.
Furthermore, specific connectivity information is also of interest as well as usage information (e.g. traffic load) of the node (e.g. RAN).
Network diagnostic information needs to be generated automatically and, in case of a hosted or virtual network deployment, be made available to the tenant of the network via a suitable API.
G  Asset Tracking use cases [R17]
G.1  Asset Tracking
Every organisation owns assets (e.g. machines, medical devices, containers, pallets, trolleys). These assets are often not stationary: they are transported all over the world by different kinds of vehicles; and the assets are also moved inside various kinds of buildings.
The ownership of assets may change many times during the life-cycle of the asset as different stakeholders take possession of the assets and pass them on to other stakeholders along the supply chain and value chain.
So, many stakeholders want to track their assets anytime and anywhere (indoor & outdoor) in a global and multi-modal context (e.g. sea, air, road, rail).
The asset tracking topic implies more than just knowing the location of an asset. Asset tracking includes real time and/or time-stamped monitoring of several asset-related properties depending on the asset and its content (e.g. condition of the asset and changes, environmental factors - temperature, mechanical shock).
The 5G system provides the capability to better support asset tracking in all its aspects in particular in term of coverage (need to support full coverage: e.g. indoor / urban / rural / harsh environments / metallic obstructions on land, sea) with the support of terrestrial and non terrestrial network as well as use of relays when necessary and in term of energy efficiency (15 to 20 years' lifetime of an asset tracking device without changing the battery or the UE).
G.2  Battery life expectancy and message size to support example use cases for asset tracking
For asset tracking it is important to be able to have the asset on the field during a period corresponding to the life of the asset without changing the UE or the battery of the UE.
The battery life expectancy, message size and device density values required to support the potential opportunities in various asset tracking use cases are summarised in Table G.2-1
Battery Life Expectancy (note 1)
Typical Message size
Maximum Message size
Typical Frequency (number of messages per day)
Typical Battery Capacity
Device density

Containers (note 2)
12 years
200 bytes
2500 bytes
21,6 Wh
1,4 devices / m3
20 years
200 bytes
2500 bytes
36 Wh
0,3 devices / m2
7 years
300 bytes
300 bytes
12 Wh
4 devices/ m2

Battery life expectancy is to be assumed in all coverage conditions and is based on typical message size value and typical frequency
A large containership with a mix of 20 ft and 40 ft containers is assumed.
All the values in this table are targeted values and not strict requirements.

H  Change historyWord-p. 79

Up   Top