Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 22.261  Word version:  18.6.1

Top   Top   Up   Prev   None
0…   4…   6…   6.4…   6.8…   6.12…   6.22…   6.26…   6.30…   7…   7.4…   8…   D…   D.3…   F…

 

F  QoS Monitoring |R16|Word‑p. 105

F.1  QoS monitoring for assuranceWord‑p. 105

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
    These state 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.
Reproduction of 3GPP TS 22.261, Fig. F.1-1: QoS assurance by use of QoS monitoring information
Up
The start time and the duration of the QoS monitoring is specified in the parameter observation time interval, which is exchanged between the customer, for instance an application consuming a communication service, and the provider (for instance a private 5G network providing a communication service). The observation time interval is the time interval during which a series of measurements is conducted. In the context of QoS monitoring, these are the measurements necessary for assessing the QoS of communication services, for instance the measurement of end-to-end latencies.
Examples of parameters to be monitored by the provider are given in Annex C in reference [36].
Up

F.2  Network DiagnosticsWord‑p. 106

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.
Up

G  Asset Tracking use cases |R17|Word‑p. 106

G.1  Asset TrackingWord‑p. 106

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 can 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).
Up

G.2  Battery life expectancy and message size to support example use cases for asset trackingWord‑p. 106

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
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 bytes2,500 bytes2421.6 Wh1.4 devices / m³
2Wagons20 years200 bytes2,500 bytes2436 Wh0.3 devices / m²
3Pallets7 years300 bytes300 bytes2412 Wh4 devices/ m²
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

H  Interworking between Network Operators and Application Providers for localized services |R18|Word‑p. 107

This clause illustrates examples of scenarios applicable for interworking between hosting network operators (PLMN or NPN) and data applications based on service agreements for localized services among network operators and application/service providers:
  • Hosting network operator owns the 5G network which provides access and IP connectivity to serving UEs.
  • Network operator owned application layer entities, e.g., including Service Hosting Environment, or IMS network.
  • Application platforms in third party domain can be owned by third party application/service providers, or home/other network operators.
  • The Application platforms could be application servers (e.g., Video on Demand Server, Cloud gaming server, etc.), 3rd party software development platforms, and third party/operator Service Hosting Environments.
The following Figures show the collaborative relationship in three domains including network operators providing access and IP connectivity, network operators providing services via IMS/application platforms, and application/service providers providing services via application platforms or applications. The dashed line between visited hosting network operator and Home network operator is based on service level localized service agreement and the horizontal line represents the demarcation between the network operator domains and the 3rd party domain. In an operator network, the application layer entities can include IMS network, Application platforms, and API Gateway for third party applications developed using APIs (e.g., REST, GSMA OneAPI).
Figure H-1 provides the home operator owned/collaborative interworking scenarios where traffic is routed to home network operator and applications are delivered by the home operator via interworking agreements between network operators.
Copy of original 3GPP image for 3GPP TS 22.261, Fig. H-1: Home Operator owned/collaborative interworking scenario Home Routed
Up
Figure H-2 provides hosting network operator owned and collaborative interworking scenarios between visited hosting network operator and operators in 3rd party domains where traffic is routed to application from the hosting network to 1) hosting network owned application platforms, 2) collaborative home network owned application platforms, and 3) third parties via interworking agreements between visited hosting network operator and home/other network operators, and between hosting network operator and other application/service providers.
Copy of original 3GPP image for 3GPP TS 22.261, Fig. H-2:Hosting Network Operator owned/collaborative interworking scenario Local Breakout
Up
Other interworking scenarios are not excluded.

$  Change historyWord‑p. 109


Up   Top