7.2.14 Group Based MTC Features
22.3683GPPRelease 17Service requirements for Machine-Type Communications (MTC)Stage 1TS
7.2.14.1 General
A Group Based MTC Feature is a MTC Feature that applies to an MTC Group.
– The system shall be optimized to handle MTC Groups. The system shall provide a mechanism to associate an MTC Device to a single MTC Group.
– Each Group Based MTC Feature is applicable to all the members of the MTC Group.
– An MTC Group shall be identified uniquely across 3GPP networks.
Note 1: With Group Based MTC Features, each MTC Device is visible from the 3GPP Network perspective.
Note 2: MTC Features that are not Group Based MTC Features can also be applied to MTC Group members.
Note 3: An MTC Device can belong to more than one MTC group, but policy conflicts need to be avoided through administrative means.
7.2.14.2 Group Based Policing
The MTC Feature Group Based Policing is intended for use with a MTC Group for which the network operator wants to enforce a combined QoS policy.
For the Group Based Policing MTC Feature:
– A maximum bit rate for the data that is sent/received by a MTC Group shall be enforced.
Note: Policy control could be static to reduce complexity. In this case, static means that the policy for a specific MTC Group is fixed for the group and does not change due to dynamic conditions.
7.2.14.3 Group Based Addressing
MTC Feature Group Based Addressing is intended for use with a MTC Group for which the network operator wants to optimize the message volume when many MTC Devices need to receive the same message.
For the Group Based Addressing MTC Feature:
– The network shall provide a mechanism to send a broadcast message within a particular geographic area, e.g. to wake up the MTC Devices that are members of that MTC Group; only MTC Devices of the target group configured to receive the broadcast message will recognize it.
Note 1: The geographic area for the broadcast may be a cell sector, a cell or a group of cells.
Note 2: Verification of receipt of a broadcast message is not necessary.
Annex A (informative):
Use cases
Addressing from a centralized entity Use Case
Metering devices are typically monitored and controlled by a centralized entity outside or inside the network operator system. Due to the need for centralized control, the centralized entity will inform or poll the metering device when it needs measurement information rather than the metering device autonomously sending measurements. Depending on the nature of the metering application, low latency responses are sometimes required (metering for high pressure pipelines for example). To accomplish this, the centralized entity will need to inform the metering device when it needs a measurement. Typically due to the limitation of IPv4 address space, the metering terminal is behind a NAT (Network Address Translator) where it is not assigned a routable IPv4 address.
Theft /Vandalism Vulnerable MTC Application Use Case
In contrast to the traditional H2H devices, which are carefully held and protected by a person, MTC Devices are often located in remote areas and ideally are untouched after installation for many years. The remote locations make these devices more susceptible to tampering by unauthorized persons. The tampering of the MTC Device is often accompanied by damage to the metering device. The network has security mechanisms for protection for this type of activity which may not be effective for MTC Devices. The network can not prevent it but can detect it as early as possible in order to deactivate the ME’s service and the related USIM. In addition, often theft/vandalism vulnerable MTC Devices are stationary after initial installation and activation. The stationality of the MTC Device can be utilized to improve the detection of theft. If a known stationary devices moves, it can be concluded that the MTC Device has been stolen and thus the account deactivated.
Time Controlled MTC Application Use Case
For some MTC applications the actual time at which communication takes place is less important, but low communication costs are extremely important. A network operator can offer low communication fees for this type of applications by allowing communication to take place during low traffic time periods only. Possibly the network operator may want to dynamically adjust these time periods based on the actual network traffic load at a specific time.
Radio Network Congestion Use Case
Radio network congestion because of mass concurrent data transmission takes place in some MTC applications. One of the typical applications is the bridge monitoring with a mass of sensors. When a train passes through the bridge, all the sensors transmit the monitoring data almost simultaneously. The same thing happens in hydrology monitoring during the time of heavy rain and in building monitoring when intruders break in. The network should be optimized to enable a mass of MTC Devices in a particular area to transmit data almost simultaneously.
Core Network Congestion Use Case
With many MTC applications, a large number of MTC Devices is affiliated with a single MTC User. These MTC Devices together are part of a MTC Group. The MTC User associated with the MTC Group owns a MTC Server which is connected to the PS network of a mobile network operator via an Access Point Name (APN) using the Gi interface. The MTC Devices in the MTC Group communicate with this MTC Server.
Typically, the MTC Devices in the MTC Group are scattered over the network in such a way that the data simultaneously sent by the MTC Devices in any particular cell is limited and will not cause a radio network overload. Despite this, when a high number of MTC Devices are sending/receiving data simultaneously, data congestion may occur in the mobile core network or on the link between mobile core network and MTC Server where the data traffic related to MTC Group is aggregated. Preferably, a network operator and the MTC User have means to enforce a maximum rate for the data sent/received by the MTC Group.
Figure A-1: Congestion in mobile core network and on the link between mobile core network and MTC Server
Signalling Network Congestion Use Case
Congestion in the signalling network is caused by a high number of MTC Devices trying almost simultaneously: (1) to attach to the network or (2) to activate/modify/deactivate a connection. In a 3GPP system supporting MTC applications such an overload of the network can be caused by e.g. many mobile payment terminals that become active on a national holiday or by high numbers of metering devices becoming active almost simultaneously after a period of power outage. Also some MTC applications generate recurring data transmissions at precisely synchronous time intervals (e.g. precisely every hour or half hour). Preferably, the 3GPP system provides means to the network operator and MTC User to spread the resulting peaks in the signalling traffic.
Figure A-2: Signalling network congestion
Access Control with billing plan Use Case
In some configurations, it may be necessary to restrict the access of a UICC that is dedicated to be used only with machine-type modules associated with a specific billing plan. It should be possible to associate a list of UICC to a list of terminal identity such as IMEISV so that if the UICC is used in an other terminal type, the access will be refused.
See the following configuration:
Figure A-3: Access Control with billing plan
Extra Low Power Consumption Use Case
For high mobility case, tracking MTC devices such as animal tracking MTC devices in natural world with high mobility require extra low power consumption because it is almost impossible to replace the battery or recharge the battery for animal tracking MTC device. Compared to the tracking devices installed in the cars and trucks because cars and trucks could generate electricity by themselves, extra low power consumption for these MTC devices is required.
For cargo tracking, the cargo with a tracking MTC device could move very fast such as on a train or lorry and could stand still such as in the dock before loading or unloading. It is not desired to either change its battery or replace battery during the transport period, so extra low power consumption MTC devices are also required.
For prisoner tracking MTC devices are already used by police, prisoners will not cooperate with police and would wish the MTC devices have flat batteries; therefore, extra low power consumption feature is required for these MTC devices. For the tracking MTC devices of elder people who have memory problem, children or pets, even the batteries of these MTC devices could be replaced or charged, however, considering the worst scenario – if they are missing, it requires the MTC devices with extra low power consumption and long working time in order to find them.
For low mobility case, the gas meter MTC devices must be battery powered. Extra low power consumption for gas MTC devices is much more critical than electricity meters.
Extra Low Power Consumption with Time Controlled MTC Devices Use Case
Time Controlled MTC Devices which send or receive data only at certain pre-defined periods may be operated in one or more modes that minimize power consumption.
An MTC Device may be operated in a mode where it is expected to receive non-periodic messages (e.g. emergency messages or notifications of altered access period as with the MTC Feature Time Controlled outside the time controlled periods. The MTC Device should minimize power consumption while in a mode to support this.
If the application requires the MTC Device to send or receive data within pre-defined periods and receive non-periodic messages outside these periods, operation at the lowest possible power consumption level to extend battery life should be achieved.
End-to-end security for roaming MTC devices
An MTC Application communicates with a large number of MTC Devices that are located globally and may or may not be mobile. Examples of such devices are mobile navigation systems and payment terminals. Connectivity for the MTC Devices is provided by a single network operator that uses its roaming agreements to connect MTC Devices that are not within range of its own network.
From the perspective of the operator of the MTC application its MTC Server and the domain of its network operator are part of a trusted domain. However, the domain of the roaming operator are not seen as part of the trusted domain, as is depicted in the figure below.
Figure A-4: End-to-end security for roaming MTC devices
The operator of the MTC application therefore requires end-to-end security for messages exchanged between MTC application and MTC Devices. The network operator does not have control over the security features in the domain of the roaming operators. Furthermore, for efficiency reasons the roaming operators may decide on a local breakout to for instance the Internet for MTC traffic in which case the information partly travels over the Internet. The network operator needs to satisfy the MTC application owner’s end-to-end security requirement without relying on network security alone.
Annex B (informative):
Examples of MTC applications
Some examples of machine‑type communication applications are listed in the following table. This list is not exhaustive and is intended to be indicative of the scope of machine‑type communication applications.
|
Service Area |
MTC applications |
|
Security |
Surveillance systems Backup for landline Control of physical access (e.g. to buildings) Car/driver security |
|
Tracking & Tracing |
Fleet Management Order Management Pay as you drive Asset Tracking Navigation Traffic information Road tolling Road traffic optimization/steering |
|
Payment |
Point of sales Vending machines Gaming machines |
|
Health |
Monitoring vital signs Supporting the aged or handicapped Web Access Telemedicine points Remote diagnostics |
|
Remote Maintenance/Control |
Sensors Lighting Pumps Valves Elevator control Vending machine control Vehicle diagnostics |
|
Metering |
Power Gas Water Heating Grid control Industrial metering |
|
Consumer Devices |
Digital photo frame Digital camera eBook |
Annex C (informative):
Change history
|
TSG SA# |
SA Doc. |
SA1 Doc |
Spec |
CR |
Rev |
Rel |
Cat |
Subject/Comment |
Old |
New |
WI |
|
SP-47 |
SP-100192 |
– |
22.220 |
– |
– |
– |
– |
Raised from v1.2.2 to v.2.0.0 for approval |
1.2.2 |
2.0.0 |
NIMTC |
|
SP-47 |
– |
– |
22.220 |
– |
– |
– |
– |
Raised from v.2.0.0 to v.10.0.0 after approval of SA#47 |
2.0.0 |
10.0.0 |
NIMTC |
|
SP-48 |
SP-100400 |
S1-101157 |
22.368 |
0001 |
2 |
Rel-10 |
F |
Deletion of section 5.2 |
10.0.0 |
10.1.0 |
NIMTC |
|
SP-48 |
SP-100400 |
S1-101158 |
22.368 |
0003 |
2 |
Rel-10 |
F |
Clarification of PAM |
10.0.0 |
10.1.0 |
NIMTC |
|
SP-48 |
SP-100400 |
S1-101138 |
22.368 |
0005 |
1 |
Rel-10 |
F |
CR to TS22.368 Clarification of Location Specific Trigger |
10.0.0 |
10.1.0 |
NIMTC |
|
SP-48 |
SP-100400 |
S1-101139 |
22.368 |
0006 |
1 |
Rel-10 |
F |
CR to TS22.368 Clarification of Infrequent Transmission |
10.0.0 |
10.1.0 |
NIMTC |
|
SP-48 |
SP-100400 |
S1-101159 |
22.368 |
0009 |
3 |
Rel-10 |
F |
Clarification of Requirements for Time Controlled MTC Feature |
10.0.0 |
10.1.0 |
NIMTC |
|
SP-48 |
SP-100435 |
S1-101143r |
22.368 |
0010 |
2 |
Rel-10 |
F |
Clarification and completion of PAM requirements |
10.0.0 |
10.1.0 |
NIMTC |
|
SP-48 |
SP-100400 |
S1-101142 |
22.368 |
0011 |
1 |
Rel-10 |
F |
Clarification of local network in Time Controlled |
10.0.0 |
10.1.0 |
NIMTC |
|
SP-48 |
SP-100400 |
S1-101077 |
22.368 |
0013 |
– |
Rel-10 |
F |
Correction of missing changes to clause 7.2.2 |
10.0.0 |
10.1.0 |
NIMTC |
|
SP-48 |
SP-100400 |
S1-101078 |
22.368 |
0014 |
– |
Rel-10 |
F |
Correction of terminology |
10.0.0 |
10.1.0 |
NIMTC |
|
SP-48 |
SP-100400 |
S1-101080 |
22.368 |
0015 |
– |
Rel-10 |
F |
Clarification of "may" in clause 7.2.2 |
10.0.0 |
10.1.0 |
NIMTC |
|
SP-48 |
SP-100400 |
S1-101083 |
22.368 |
0017 |
– |
Rel-10 |
F |
Correction of MTC User shall in 7.2.8 |
10.0.0 |
10.1.0 |
NIMTC |
|
SP-49 |
SP-100579 |
S1-102258 |
22.368 |
0023 |
1 |
Rel-10 |
F |
Simplification of Mobile Originated Only feature |
10.1.0 |
10.2.0 |
NIMTC |
|
SP-49 |
SP-100579 |
S1-102259 |
22.368 |
0024 |
1 |
Rel-10 |
F |
Simplification of Infrequent Mobile Terminated feature |
10.1.0 |
10.2.0 |
NIMTC |
|
SP-49 |
SP-100579 |
S1-102260 |
22.368 |
0025 |
1 |
Rel-10 |
F |
Clarification of MTC Monitoring feature |
10.1.0 |
10.2.0 |
NIMTC |
|
SP-49 |
SP-100579 |
S1-102264 |
22.368 |
0029 |
1 |
Rel-10 |
F |
Clarification of Group Based MTC Features |
10.1.0 |
10.2.0 |
NIMTC |
|
SP-49 |
SP-100579 |
S1-102280 |
22.368 |
0038 |
2 |
Rel-10 |
F |
Clarification of subscription |
10.1.0 |
10.2.0 |
NIMTC |
|
SP-49 |
SP-100579 |
S1-102281 |
22.368 |
0018 |
2 |
Rel-10 |
F |
Clarification on MTC Server relationship to network operator |
10.1.0 |
10.2.0 |
NIMTC |
|
SP-49 |
SP-100579 |
S1-102282 |
22.368 |
0027 |
2 |
Rel-10 |
F |
Clarification of Location Specific Trigger |
10.1.0 |
10.2.0 |
NIMTC |
|
SP-49 |
SP-100579 |
S1-102287 |
22.368 |
0034 |
1 |
Rel-10 |
F |
MTC Group Features definition clarification |
10.1.0 |
10.2.0 |
NIMTC |
|
SP-49 |
SP-100579 |
S1-102288 |
22.368 |
0035 |
1 |
Rel-10 |
F |
MTC Infrequent Transmission clarification |
10.1.0 |
10.2.0 |
NIMTC |
|
SP-49 |
SP-100579 |
S1-102289 |
22.368 |
0036 |
1 |
Rel-10 |
F |
MTC Secure Connection |
10.1.0 |
10.2.0 |
NIMTC |
|
SP-49 |
SP-100579 |
S1-102290 |
22.368 |
0037 |
2 |
Rel-10 |
F |
MTC Time Controlled clarification |
10.1.0 |
10.2.0 |
NIMTC |
|
SP-50 |
SP-100798 |
S1-103312 |
22.368 |
0049 |
2 |
Rel-10 |
F |
NIMTC Terminology |
10.2.0 |
10.3.0 |
NIMTC |
|
SP-50 |
SP-100798 |
S1-103311 |
22.368 |
0051 |
2 |
Rel-10 |
B |
Clarification of data delay in case of Overload |
10.2.0 |
10.3.0 |
NIMTC |
|
SP-50 |
SP-100801 |
S1-103209 |
22.368 |
0045 |
1 |
Rel-11 |
C |
Clarification on the requirements of Low Mobility MTC Feature |
10.2.0 |
11.0.0 |
SIMTC |
|
– |
LTE logo changed into LTE Advanced logo |
11.0.0 |
11.0.1 |
– |
|||||||
|
SP-51 |
SP-110162 |
S1-110427 |
22.368 |
0069 |
2 |
Rel-11 |
A |
MTC charging requirements in Rel-11 |
11.0.1 |
11.1.0 |
NIMTC |
|
SP-51 |
SP-110162 |
S1-110411 |
22.368 |
0071 |
– |
Rel-11 |
A |
Clarification of EAB |
11.0.1 |
11.1.0 |
NIMTC |
|
SP-51 |
SP-110167 |
S1-110429 |
22.368 |
0058 |
3 |
Rel-11 |
B |
Additional security for MTC Triggering requirements |
11.0.1 |
11.1.0 |
SIMTC |
|
SP-51 |
SP-110167 |
S1-110414 |
22.368 |
0059 |
2 |
Rel-11 |
B |
Suppress MTC device triggering |
11.0.1 |
11.1.0 |
SIMTC |
|
SP-51 |
SP-110167 |
S1-110420 |
22.368 |
0080 |
2 |
Rel-11 |
B |
MTC – IMS Service Layer Capabilities |
11.0.1 |
11.1.0 |
SIMTC |
|
SP-52 |
SP-110374 |
S1-111026 |
22.368 |
0075 |
– |
Rel-11 |
F |
Correction of charging requirements |
11.1.0 |
11.2.0 |
SIMTC |
|
SP-52 |
SP-110374 |
S1-111036 |
22.368 |
0072 |
– |
Rel-11 |
B |
MTC – IMS Service Layer Capabilities |
11.1.0 |
11.2.0 |
SIMTC |
|
SP-52 |
SP-110374 |
S1-111304 |
22.368 |
0091 |
– |
Rel-11 |
F |
Clarification of MTC Device management requirement |
11.1.0 |
11.2.0 |
SIMTC |
|
SP-52 |
SP-110374 |
S1-111328 |
22.368 |
0088 |
1 |
Rel-11 |
F |
Clarification of MTC identifier to aligning it with MTC Group feature |
11.1.0 |
11.2.0 |
SIMTC |
|
SP-52 |
SP-110374 |
S1-111329 |
22.368 |
0083 |
2 |
Rel-11 |
B |
New Requirements for MTC Monitoring Feature |
11.1.0 |
11.2.0 |
SIMTC |
|
SP-52 |
SP-110374 |
S1-111373 |
22.368 |
0092 |
2 |
Rel-11 |
A |
Correction of SIMTC requirements to define the precedence for NAS configuration parameters in case they are defined in the device and in the USIM |
11.1.0 |
11.2.0 |
SIMTC |
|
SP-52 |
SP-110374 |
S1-111374 |
22.368 |
0078 |
2 |
Rel-11 |
C |
MTC Device Trigger and Time Controlled MTC Feature |
11.1.0 |
11.2.0 |
SIMTC |
|
SP-52 |
SP-110374 |
S1-111375 |
22.368 |
0081 |
3 |
Rel-11 |
F |
Clarification on MTC User |
11.1.0 |
11.2.0 |
SIMTC |
|
SP-52 |
SP-110374 |
S1-111377 |
22.368 |
0089 |
2 |
Rel-11 |
F |
Clarification of requirements for MTC |
11.1.0 |
11.2.0 |
SIMTC |
|
SP-52 |
SP-110374 |
S1-111379 |
22.368 |
0079 |
3 |
Rel-11 |
C |
Introduction of new scenarios for IP addressing |
11.1.0 |
11.2.0 |
SIMTC |
|
SP-53 |
SP-110578 |
S1-112334 |
22.368 |
0095 |
3 |
Rel-11 |
F |
Clarification to small data transmissions requirement |
11.2.0 |
11.3.0 |
SIMTC |
|
SP-53 |
SP-110578 |
S1-112335 |
22.368 |
0103 |
2 |
Rel-11 |
C |
Clarification of MTC Small Data |
11.2.0 |
11.3.0 |
SIMTC |
|
SP-53 |
SP-110578 |
S1-112336 |
22.368 |
0101 |
1 |
Rel-11 |
B |
Location Monitoring Requirement for MTC Monitoring Feature |
11.2.0 |
11.3.0 |
SIMTC |
|
SP-53 |
SP-110578 |
S1-112337 |
22.368 |
0096 |
2 |
Rel-11 |
F |
Correction of offline MTC Device Triggering |
11.2.0 |
11.3.0 |
SIMTC |
|
SP-53 |
SP-110578 |
S1-112338 |
22.368 |
0108 |
1 |
Rel-11 |
D |
Editorial CR on offline MTC Devices |
11.2.0 |
11.3.0 |
SIMTC |
|
SP-53 |
SP-110578 |
S1-112339 |
22.368 |
0098 |
2 |
Rel-11 |
C |
MTC Group-Based Addressing |
11.2.0 |
11.3.0 |
SIMTC |
|
SP-53 |
SP-110578 |
S1-112412 |
22.368 |
0099 |
3 |
Rel-11 |
F |
MTC Small Data Transmissions |
11.2.0 |
11.3.0 |
SIMTC |
|
SP-53 |
SP-110651 |
S1-112169 |
22.368 |
0106 |
2 |
Rel-11 |
F |
CR to 22.368 – Moving "Network provided destination for uplink data" requirement from 22.368 into 22.101 |
11.2.0 |
11.3.0 |
SIMTC |
|
SP-53 |
SP-110651 |
S1-112171 |
22.368 |
0107 |
2 |
Rel-11 |
F |
CR to 22.368 – Moving PS-Only requirements from 22.368 into 22.101 |
11.2.0 |
11.3.0 |
SIMTC |
|
SP-55 |
SP-120103 |
S1-120334 |
22.368 |
0120 |
3 |
Rel-11 |
F |
Security to MTC server and MTC application |
11.3.0 |
11.4.0 |
SIMTC |
|
SP-56 |
SP-120289 |
S1-121376 |
22.368 |
0126 |
1 |
Rel-11 |
F |
Clarify restricting use of a USIM to specific MEs/MTC Devices |
11.4.0 |
11.5.0 |
SIMTC |
|
SP-56 |
SP-120289 |
S1-121447 |
22.368 |
0128 |
4 |
Rel-11 |
F |
MTC Server Definition |
11.4.0 |
11.5.0 |
SIMTC |
|
SP-56 |
SP-120288 |
S1-121457 |
22.368 |
0130 |
5 |
Rel-11 |
F |
MTC Device Power Level Monitoring |
11.4.0 |
11.5.0 |
TEI11 |
|
SP-56 |
SP-120289 |
S1-121458 |
22.368 |
0131 |
4 |
Rel-11 |
F |
Connection Error Codes for Troubleshooting Requirement |
11.4.0 |
11.5.0 |
SIMTC |
|
SP-57 |
SP-120524 |
S1-122513 |
22.368 |
0133 |
2 |
Rel-12 |
F |
Clarification of MTC Charging Requirements wrt on line/off line |
11.5.0 |
12.0.0 |
MTCe-SRM |
|
SP-57 |
SP-120533 |
S1-122516 |
22.368 |
0127 |
7 |
Rel-12 |
C |
External identifier availability |
11.5.0 |
12.0.0 |
MTCe-SIMSE |
|
SP-57 |
SP-120533 |
S1-122435 |
22.368 |
0132 |
1 |
Rel-12 |
B |
MTC Device and MTC Server relation with Service Enablement Frameworks |
11.5.0 |
12.0.0 |
MTCe-SIMSE |
|
SP-58 |
SP-120868 |
S1-124465 |
22.368 |
0144 |
– |
Rel-12 |
C |
Removal of requirement to be able to count for device initiated signalling |
12.0.0 |
12.1.0 |
MTCe-SRM |
|
SP-58 |
SP-120868 |
S1-124489 |
22.368 |
0139 |
2 |
Rel-12 |
C |
Clean-up of Location specific trigger Requirement |
12.0.0 |
12.1.0 |
MTCe-SRM |
|
SP-58 |
SP-120868 |
S1-124512 |
22.368 |
0145 |
2 |
Rel-12 |
C |
Moving MTC Feature Infrequent Transmission into a generic requirement |
12.0.0 |
12.1.0 |
MTCe-SRM |
|
SP-58 |
SP-120868 |
S1-124488 |
22.368 |
0136 |
2 |
Rel-12 |
C |
Clean-up of Time Tolerant Requirement |
12.0.0 |
12.1.0 |
MTCe-SRM |
|
SP-59 |
SP-130104 |
S1-131289 |
22.368 |
0146 |
2 |
Rel-12 |
C |
Clarification and merge of Mobile Originated Only and Infrequent Mobile Terminated |
12.1.0 |
12.2.0 |
MTCe-SRM |
|
SP-59 |
SP-130104 |
S1-131290 |
22.368 |
0147 |
2 |
Rel-12 |
C |
Moving MTC Priority Alarm into a generic requirement |
12.1.0 |
12.2.0 |
MTCe-SRM |
|
SP-59 |
SP-130109 |
S1-131302 |
22.368 |
0148 |
2 |
Rel-12 |
D |
Clarification of requirements for the support of multiple service enablement frameworks |
12.1.0 |
12.2.0 |
MTCe-SIMSE |
|
SP-62 |
SP-130593 |
S1-135102 |
22.368 |
0151 |
– |
Rel-12 |
F |
Removal of group based charging requirements |
12.2.0 |
12.3.0 |
MTCe-SRM |
|
SP-64 |
– |
– |
– |
– |
– |
– |
– |
Rel.13 version created to keep text applicable to Rel-13 only, removed in the Rel-12 version 12.4.0 by CR0153r1 |
12.3.0 |
13.0.0 |
– |
|
SP-66 |
SP-140751 |
S1-144352 |
22.368 |
155 |
– |
Rel-13 |
F |
Align the MTC monitoring requirements with Service Exposure requirements |
13.0.0 |
13.1.0 |
TEI13 |
|
SP-75 |
– |
Rel-14 |
Updated to Rel-14 by MCC |
13.1.0 |
14.0.0 |
||||||
|
Aug. 2017 |
– |
– |
– |
Rel-14 |
Previous version was incorrectly saved as “22638-e10.doc” instead of “22368-e00.doc” |
14.0.0 |
14.0.1 |
– |
|||
|
July 2019 |
– |
– |
– |
– |
– |
Rel-15 |
Updated to Rel-15 by MCC |
14.0.1 |
15.0.0 |
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2020-07 |
SA#88e |
– |
– |
– |
– |
Updated to Rel-16 by MCC |
16.0.0 |
|
2022-03 |
SA#95e |
– |
– |
– |
– |
Updated to Rel-17 by MCC |
17.0.0 |