5 SYNC protocol version 1
25.4463GPPMBMS synchronisation protocol (SYNC)Release 17TS
5.1 General
5.1.1 Applicablity of SYNC protocol version 1
This version of the specification specifies the SYNC protocol for UTRAN and E-UTRAN. It is on top of TNL in Iu (UTRAN) and M1 (E-UTRAN) user plane, i.e. Iu userplane TNL transports SYNC protocol PDUs over the Iu interface, M1 userplane TNL transports SYNC protocol PDUs over the M1 interface.
As a specification convention, within this specification, the interface between the Core Network and the Radio Access Network is denoted as the “RAN Access Interface”, the termination point at the Radio Access Network is denoted as “RAN Access Node”, the termination point at the Core Network is denoted as “Core Network” (CN). Further, “MBMS RAB” denotes the Radio Access data bearer together with the RAN Access Interface data bearer for MBMS service user data transmission.
For the application of the SYNC protocol to UTRAN, the RAN Access Interface is the Iu interface, the RAN Access Node is the RNC.
For the application of the SYNC protocol to E-UTRAN, the RAN Access Interface is the M1 interface, the RAN Access Node is the eNB.
5.1.1 Operation of the SYNC protocol
The SYNC protocol layer is present for data streams that originate in the CN and carry additional information within a specific userplane-frame.
The two strata communicate through a Service Access Point for Non Access Stratum (NAS) Data Streams transfer.
5.1.2 Interfaces of the SYNC protocol layer
As part of the Access Stratum responsibility, the SYNC protocol layer provides the services and functions that are necessary to handle non access stratum data streams for MBMS. The SYNC protocol layer is providing these services to the UP upper layers through a Dedicated Service Access Point used for Information Transfer.
The SYNC protocol layer is using services of the Transport layers in order to transfer user plane PDUs over the RAN Access interface.
5.2 SYNC protocol layer services
The following functions are needed to support the SYNC protocol:
– Transfer of user data along with synchronisation information;
– Transfer of synchronisation information without user data.
5.3 Services Expected from the UP Data Transport layer
The SYNC protocol layer expects the following services from the Transport Network Layer:
– Transfer of user data.
– No flow control.
5.4 Elementary procedures
5.4.1 Transfer of User Data for MBMS procedure
5.4.1.1 Successful operation
The purpose of the Transfer of User Data procedure for MBMS is to transfer RAN Access Interface UP frames from the RAN Access interface UP protocol layers at CN to the RAN Access interface UP protocol layer at the RAN Access Node. One RAN Access interface UP instance is associated to a single MBMS RAB only.
The Transfer of User Data procedure is invoked whenever user data for that particular RAB needs to be sent across the Radio Access interface.
The NAS Data Streams specific functions make the padding of the payload (if needed) so that the Radio Access interface UP frame payload will be an integer number of octets. Then the NAS Data Streams specific functions perform, if needed, CRC calculation of the Iu/M1 frame payload and passes the Radio Access interface UP frame payload down to the Frame Handler function.
The Frame Handler function within the CN retrieves the packet counter and octet counter value from its internal memory, formats the frame header and frame payload into the appropriate PDU Type and sends the Radio Access interface UP frame PDU to the lower layers for transfer across the Radio Access interface. If the user data is provided with compressed IP header, the Radio Access interface UP frame contains PDCP information and the uncompressed IP header.
The Frame Handler function within the CN is also responsible for appropriate setting of the Time Stamp value in order to allow all RAN Access nodes to submit the MBMS user data in a synchronised manner.
Upon reception of a user data frame, the RAN Access interface UP protocol layer within the RAN Access node checks the consistency of the RAN Access interface UP frame as follows:
– The Frame Handler function checks the consistency of the frame header and the consistency of the packet counter value.
– Then the RAN Access node utilises the time stamp information to schedule the user data on the radio interface on the next TTI for UTRAN or MCH scheduling period for E-UTRAN as defined in TS 36.300 [6].
Figure 5.4.1.1-1. Successful Transfers of User Data.
5.4.1.2 Unsuccessful operation
If multiple consecutive RAN Access interface UP frames carrying the user data are incorrectly formatted or cannot be correctly treated by the receiving RAN Access interface UP protocol layer, or if multiple consecutive frames loss is detected due to gaps in the sequence of the received frame numbers, the RAN Access node shall, if packet length information in Type 3 is not provided,
– in case the RAN Access Interface UP is the Iu UP.
– cease to provide user data to the radio interface protocol entities and wait until the next synchronisation sequence if soft combining and MBSFN are used, or until the next scheduling transmission interval if the RNC acts as an MRNC and TDM multiplexing is used, as described in TS 25.346 [4].
– in case the RAN Access Interface UP is the M1 UP and MBSFN is used,
– cease to provide user data to the radio interface protocol entities and wait until the next dynamic scheduling interval, as described in TS 36.300 [6].
– in case the RAN Access Interface UP is the M1 UP and SC-PTM is used,
– provide other correctly received user data to the radio interface protocol entities, as described in TS 36.300 [6].
If packet length information in Type 3 is provided, the RAN Access nodes could cease to provide user data to the radio interface protocol entities for those lost subframes.
5.4.2 Transfer of Synchronisation Information for MBMS procedure (without user data)
5.4.2.1 Successful operation
The purpose of the Transfer of Synchronisation Information for MBMS procedure is to transfer synchronisation information from the CN to the RAN Access node at the end of each synchronization sequence (see TS 25.346 [4], TS 36.300 [6]) to improve the RAN Access node resynchronization in case of packet loss.
The Frame Handler function within the CN retrieves the synchronisation time stamp from its internal clock and the total packet counter and total octet counter from its internal memory, formats the frame header and frame payload into the appropriate PDU Type and sends the RAN Access interface UP frame PDU to the lower layers for transfer across the RAN Access interface.
If there is no data frame in a synchronization sequence, synchronization information shall still be transmitted.
Furthermore, the SYNC PDU towards RAN Access node could contain length of each packet if supported.
Upon reception of a user data frame, the RAN Access interface UP protocol layer checks the consistency of the RAN Access interface UP frame as follows:
– The Frame Handler function checks the consistency of the frame header and the consistency of the synchronisation time stamp, total packet counter, total octet counter and packets length counter value if contained.
Figure 5.4.2.1-1. Successful Transfers of Synchronisation Information.
5.4.2.2 Unsuccessful operation
If the RAN Access interface UP frame without user data is incorrectly formatted or cannot be correctly treated by the receiving RAN Access interface UP protocol layer, the RAN Access interface UP protocol layer shall either discard the frame or pass it to the upper layers with a frame classification indicating a corrupted frame.
5.5 Elements for the SYNC protocol
5.5.1 General
In the present document the structure of frames will be specified by using figures similar to Figure 5.5.1-1.
|
Bits |
Number of Octets |
|||||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|||||
|
Field 1 |
Field 2 |
1 |
Octet 1 |
Header part |
||||||||
|
Field 3 |
Field 4 |
2 |
Octet 2 |
|||||||||
|
Field 4 continue |
Spare |
Octet 3 |
||||||||||
|
Field 6 |
2 |
Octet 4 Octet 5 |
Payload part |
|||||||||
|
Field 6 continue |
Padding |
|||||||||||
|
Spare extension |
0-m |
|||||||||||
Figure 5.5.1-1. Example frame format.
Unless otherwise indicated, fields which consist of multiple bits within an octet will have the most significant bit located at the higher bit position (indicated above frame in Figure 5.5.1-1). In addition, if a field spans several octets, most significant bits will be located in lower numbered octets (right of frame in Figure 5.5.1-1).
On the Iu/M1 interface, the frame will be transmitted starting from the lowest numbered octet. Within each octet, the bits are sent according decreasing bit position (bit position 7 first).
Spare bits should be set to "0" by the sender and should not be checked by the receiver.
The header part of the frame is always an integer number of octets. The payload part is octet aligned (by adding ‘Padding’ when needed).
The receiver should be able to remove an additional spare extension field that may be present at the end of a frame. See description of Spare extension field.
5.5.2 Frame format for the SYNC protocol
5.5.2.1 Transfer of Synchronisation Information without payload (SYNC PDU Type 0)
This Frame Format is defined to transfer synchronisation information over the RAN Access Interface UP without user data payload.
The following shows the SYNC frame structure for PDU TYPE 0 data frame of the RAN Access Interface UP protocol at the SAP towards the transport layers (TNL-SAP).
|
Bits |
Number of Octets |
||||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||||
|
PDU Type (=0) |
spare |
1 |
Frame Control Part |
||||||||
|
Time Stamp |
2 |
||||||||||
|
Packet Number |
2 |
||||||||||
|
Elapsed Octet Counter |
4 |
||||||||||
|
Total Number Of Packet |
3 |
||||||||||
|
Total Number Of Octet |
5 |
||||||||||
|
Header CRC |
Padding |
1 |
Frame Check Sum Part |
||||||||
Figure 5.5.2.1-1. SYNC PDU Type 0 Format.
The SYNC PDU TYPE 0 data frame is made of two parts:
1) SYNC Frame Control part (fixed size);
2) SYNC Frame Check Sum part (fixed size);
5.5.2.2 Transfer of User Data for MBMS with uncompressed header (SYNC PDU Type 1)
This Frame Format is defined to transfer user data over the RAN Access Interface UP for user data with uncompressed header.
The following shows the SYNC frame structure for PDU TYPE 1 data frame of the RAN Access Interface UP protocol at the SAP towards the transport layers (TNL-SAP).
|
Bits |
Number of Octets |
||||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||||
|
PDU Type (=1) |
spare |
1 |
Frame Control Part |
||||||||
|
Time Stamp |
2 |
||||||||||
|
Packet Number |
2 |
||||||||||
|
Elapsed Octet Counter |
4 |
||||||||||
|
Header CRC |
Payload CRC |
2 |
Frame Check Sum Part |
||||||||
|
Payload CRC |
|||||||||||
|
Payload Fields |
1–n |
Frame Payload part |
|||||||||
|
Payload Fields |
Padding |
||||||||||
|
Spare extension |
0-4 |
||||||||||
Figure 5.5.2.2-1. SYNC PDU Type 1 Format.
The SYNC PDU TYPE 1 data frame is made of three parts:
1) SYNC Frame Control part (fixed size);
2) SYNC Frame Check Sum part (fixed size);
3) SYNC Frame Payload part (SDU sizes rounded up to octets [Note: this does not consider the usage of spare extension field]).
5.5.2.3 Transfer of User Data for MBMS with compressed header (SYNC PDU Type 2)
This Frame Format is defined to transfer user data over the RAN Access Interface UP for user data with compressed header.
The following shows the SYNC frame structure for PDU TYPE 2 data frame of the RAN Access Interface UP protocol at the SAP towards the transport layers (TNL-SAP).
For this version of the specification, SYNC PDU TYPE 2 is only applicable if the RAN Access Interface UP is the Iu UP, it shall not be used over M1.
|
Bits |
Number of Octets |
||||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||||
|
PDU Type (=2) |
spare |
IPv6 indic |
1 |
Frame Control Part |
|||||||
|
Time Stamp |
2 |
||||||||||
|
Packet Number |
2 |
||||||||||
|
Elapsed Octet Counter |
4 |
||||||||||
|
PDCP Information |
1 |
||||||||||
|
Uncompressed Payload IP header |
20(40) |
||||||||||
|
Header CRC |
Payload CRC |
2 |
Frame Check Sum Part |
||||||||
|
Payload CRC |
|||||||||||
|
Payload Fields |
1–n |
Frame Payload part |
|||||||||
|
Payload Fields |
Padding |
||||||||||
|
Spare extension |
0-4 |
||||||||||
Figure 5.5.2.3-1. SYNC PDU Type 2 Format.
The SYNC PDU TYPE 2 data frame is made of three parts:
1) SYNC Frame Control part (fixed size);
2) SYNC Frame Check Sum part (fixed size);
3) SYNC Frame Payload part (SDU sizes rounded up to octets [Note: this does not consider the usage of spare extension field]).
5.5.2.4 Transfer of Synchronisation Information with Length of Packets (SYNC PDU Type 3)
This Frame Format is defined to transfer synchronisation information over the RAN Access Interface UP with Length of Packets.
The following shows the SYNC frame structure for PDU TYPE 3 data frame of the RAN Access Interface UP protocol at the SAP towards the transport layers (TNL-SAP).
|
Bits |
Number of Octets |
||||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||||
|
PDU Type (=3) |
spare |
1 |
Frame Control Part |
||||||||
|
Time Stamp |
2 |
||||||||||
|
Packet Number |
2 |
||||||||||
|
Elapsed Octet Counter |
4 |
||||||||||
|
Total Number Of Packet |
3 |
||||||||||
|
Total Number Of Octet |
5 |
||||||||||
|
Header CRC |
Payload CRC |
2 |
Frame Check Sum Part |
||||||||
|
Payload CRC |
|||||||||||
|
Length of the 1st Packet |
1.5* (Packet Number -1) + 2 |
Frame Payload part |
|||||||||
|
Length of the 1st Packet (cont) |
Length of 2nd packet |
||||||||||
|
… |
|||||||||||
|
Length of the Nth Packet |
|||||||||||
|
Length of the Nth Packet (cont) |
Padding |
||||||||||
|
Spare extension |
0-4 |
||||||||||
Figure 5.5.2.4-1. SYNC PDU Type 3 Format (Odd number of packets, i.e. N=1, 3, 5, …)
|
Bits |
Number of Octets |
||||||||||
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
||||
|
PDU Type (=3) |
spare |
1 |
Frame Control Part |
||||||||
|
Time Stamp |
2 |
||||||||||
|
Packet Number |
2 |
||||||||||
|
Elapsed Octet Counter |
4 |
||||||||||
|
Total Number Of Packet |
3 |
||||||||||
|
Total Number Of Octet |
5 |
||||||||||
|
Header CRC |
Payload CRC |
2 |
Frame Check Sum Part |
||||||||
|
Payload CRC |
|||||||||||
|
Length of the 1st Packet |
1.5* Packet Number |
Frame Payload part |
|||||||||
|
Length of the 1st Packet (cont) |
Length of the 2nd Packet |
||||||||||
|
… |
|||||||||||
|
Length of the Nth Packet |
|||||||||||
|
Spare extension |
0-4 |
||||||||||
Figure 5.5.2.4-2. SYNC PDU Type 3 Format (Even number of packets, i.e. N=2, 4, 6, …)
The SYNC PDU TYPE 3 data frame is made of three parts:
1) SYNC Frame Control part (fixed size);
2) SYNC Frame Check Sum part (fixed size);
3) SYNC Frame Payload part (variable size); the size of the SYNC Frame Payload part is the length of the Length of the Nth Packet IE in octets = 1.5* (Packet Number -1) + 2 + the length of Spare Extension, if the number of packets is odd in the synchronization sequence; the length of the Length of the Nth Packet IE in octets = 1.5* Packet Number + the length of Spare Extension, if the number of packets is even in the synchronization sequence.
5.5.3 Coding of information elements in frames
5.5.3.1 PDU Type
Description: The PDU type indicates the structure of the SYNC frame. The field takes the value of the PDU Type it identifies: i.e. "0" for PDU Type 0. The PDU type is in bit 4 to bit 7 in the first octet of the frame.
Value range: {0=synchronisation frame without payload, 1=user data with synchronisation frame for uncompressed headers, 2=user data with synchronisation frame for compressed headers, 3=synchronisation frame with Length of Packets, 4-15=reserved for future PDU type extensions}
Field length: 4 bits
5.5.3.2 Timestamp
Description: Relative time value for the starting time of a synchronization sequence within the synchronisation period.
Value range: {0…60000-1} Unit: multiples of 10ms.
Note: The value range allows for a synchronisation period of 600s.
Field length: 2 octets
5.5.3.3 Packet Number
Description: This parameter indicates the number of elapsed SYNC PDUs cumulatively within the synchronization sequence. It helps the RAN Access node to notice the loss of SYNC PDUs. Additionally it is used to reorder the PDUs in the RAN Access node. The Packet number is reset at the end of every synchronisation sequence, and is set to 0 for the 1st SYNC PDU of every synchronisation sequence. SYNC PDUs of Type 0 and Type 3 are not counted by this parameter.
Value range: {0..216-1}.
Field length: 2 octets.
5.5.3.4 Elapsed Octet Counter
Description: This parameter indicates the number of elapsed cumulative octets cumulatively within one synchronisation sequence. It helps the RAN Access node to know how many packets were not received in case of packet loss. This counter is reset at the end of every synchronisation sequence, and is set to 0 for the 1st SYNC PDU of every synchronisation sequence. This parameter does not count the header part of the SYNC PDU. Octets of SYNC PDUs of Type 0 and Type 3 are not counted by this parameter.
Value range: {0..232-1}.
Field length: 4 octets.
5.5.3.5 Total Number Of Packet
Description: This parameter indicates cumulatively the number of the packets for the MBMS service within one synchronization period. SYNC PDUs of Type 0 and Type 3 are not counted by this parameter.
Value range: {0..224-1}.
Note: In case of soft combining and MBSFN(except in case the RNC acts as an MRNC and TDM multiplexing is used), the parameter shall be ignored in RNC.
Field length: 3 octets.
5.5.3.6 Total Number Of Octet
Description: This parameter indicates cumulatively the number of the octets for the MBMS service within one synchronization period. This parameter does not count the header part of the SYNC PDU. Octets of SYNC PDUs of Type 0 and Type 3 are not counted by this parameter.
Value range: {0..240-1}.
Note: In case of soft combining and MBSFN(except in case the RNC acts as an MRNC and TDM multiplexing is used), the parameter shall be ignored in RNC.
Field length: 5 octets.
5.5.3.7 PDCP Information
Description: This parameter contains PDCP Information as specified in TS 25.323 [3].
Value range: as specified in TS 25.323 [3].
Field length: 1 octet.
5.5.3.8 IPv6 Indicator
Description: This parameter indicates whether the Uncompressed Payload IP header is of IPv6 type.
Value range: {0=IPv4, 1=IPv6}.
Field length: 1 bit.
5.5.3.9 Uncompressed Payload IP header
Description: This parameter provides the uncompressed IP header of the payload.
Value range: {any value}
Field length: 20 octets if IPv6 Indicator=0, 40 octets if IPv6 Indicator=1.
5.5.3.10 Header CRC
Description: This field contains the CRC of all fields in Frame Control Part. The CRC is a 6-bit checksum based on the generator polynomial G(D) = D6+D5+D3+D2+D1+1, see subclause 5.6.2. With this CRC all error bursts shorter than 7 bits are detected, as well as all odd number of bits faulty (and two-bit faults) when the protected area is shorter than 24 bits, (max 3 octets).
Field length: 6 bits.
5.5.3.11 Payload CRC
Description: This field contains the CRC of all the fields (including Padding and possible Spare extension) of the Frame Payload Part. The CRC is a 10 bit checksum based on the generator polynomial G(D) = D10+ D9+D5+D4+D1+1, see subclause 5.6.2. With this CRC all error bursts shorter than 11 bits are detected, as well as all odd number of bits faulty (and two-bit faults) when the protected area is shorter than 500 bits (max 62 octets).
Field length: 10 bits.
5.5.3.12 Padding
Description: This field is an additional field used to make the frame header or payload part an integer number of octets when needed. Padding is set to "0" by the sender and is not interpreted by the receiver.
Value range: {0–127}.
Field length: 0–7 bits.
5.5.3.13 Spare
Description: The spare field is set to "0" by the sender and should not be interpreted by the receiver. This field is reserved for later versions.
Value range: (0–2n-1).
Field Length: n bits.
5.5.3.14 Spare extension
Description: The spare extension field is reserved for extension in later versions. It shall not be sent. The receiver should be capable of receiving a spare extension. The spare extension should not be interpreted by the receiver since in later versions of the present document additional new fields might be added in place of the spare extension. The spare extension can be an integer number of octets carrying new fields or additional information; the maximum length of the spare extension field (m) depends on the PDU type.
Value range: 0–2m*8-1.
Field Length: 0–m octets. For PDU Types in the set {1,2,3}, m=4.
5.5.3.15 Payload fields
Description: This field contains the payload of the MBMS user data.
Value range: {any value}.
Field length: n bits
.
5.5.3.16 Length of the Nth Packet
Description: This parameter indicates the length of the SYNC PDU within the synchronization sequence in octets. It helps the RAN Access node to recover from de-synchronization in case of the loss of consecutive SYNC PDUs.
Value range: {0..212-1}
Field length: 12 bits
5.5.4 Timers
not applicable
5.6 Handling of unknown, unforeseen and erroneous protocol data
5.6.1 General
void
5.6.2 CRC Calculation
The parity bits are generated by one of the following cyclic generator polynomials:
gCRC6(D) = D6 + D5 + D3 + D2 + D1 + 1;
gCRC10(D) = D10 + D9 + D5 + D4 + D1 + 1.
Denote the bits to be protected of a frame by 
(
being the bit with the highest bit position in the first octet), and the parity bits by 
. Ai is the length of the protected data and Li is 6 or 10 depending on the CRC length.
The encoding is performed in a systematic form, which means that in GF(2), the polynomial
yields a remainder equal to 0 when divided by gCRC6(D) and the polynomial
yields a remainder equal to 0 when divided by gCRC10(D). If 
, 
.
5.6.3 Relation between input and output of the Cyclic Redundancy Check
The protected bits are left unchanged in the frame. The parity bits for the Header CRC are put in the Header CRC field with
being the highest bit position of the first octet of the Header CRC field. The parity bits for the Payload CRC are put in the Payload CRC field with being the highest bit position of the first octet of the Payload CRC field.
Annex A (informative):
Change history
|
Change history |
|||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
Old |
New |
|
12/2008 |
42 |
RP-080831 |
Presented to TSG-RAN for approaval |
1.0.0 |
|||
|
12/2008 |
42 |
RP-080831 |
approved at TSG-RAN#42 and placed under change control |
1.0.0 |
8.0.0 |
||
|
12/2009 |
46 |
RP-091182 |
0002 |
1 |
Ignorance of Total Number Of Packet and Total Number Of Octet in case of Soft Combining and MBSFN |
8.0.0 |
8.1.0 |
|
12/2009 |
46 |
RP-091182 |
0003 |
2 |
Correction for SYNC Protocol |
8.0.0 |
8.1.0 |
|
12/2009 |
– |
– |
– |
– |
Creation of version 9.0.0 based on v/ 8.1.0 |
8.1.0 |
9.0.0 |
|
12/2009 |
46 |
RP-091190 |
0001 |
2 |
Reusing SYNC for LTE |
8.1.0 |
9.0.0 |
|
12/2009 |
46 |
RP-091190 |
0004 |
SYNC PDU TYPE2 not applicable for LTE MBMS |
8.1.0 |
9.0.0 |
|
|
12/2009 |
46 |
RP-091190 |
0005 |
1 |
CR on Mechanism for Consecutive Packet Loss in 25.446 |
8.1.0 |
9.0.0 |
|
03/2010 |
47 |
RP-100227 |
0006 |
4 |
Clarification on Total counter frame |
9.0.0 |
9.1.0 |
|
03/2010 |
47 |
RP-100226 |
0007 |
Update Description for LTE MBMS Multiple Consecuctive Packet Loss |
9.0.0 |
9.1.0 |
|
|
03/2010 |
47 |
RP-100226 |
0008 |
1 |
Small Corrections/Improvements for SYNC |
9.0.0 |
9.1.0 |
|
03/2010 |
47 |
RP-100226 |
0010 |
1 |
Corrections on Packet Number |
9.0.0 |
9.1.0 |
|
06/2010 |
48 |
RP-100597 |
0011 |
Correction to MBMS scheduling terminology |
9.1.0 |
9.2.0 |
|
|
03/2011 |
SP-49 |
SP-100629 |
Clarification on the use of References (TS 21.801 CR#0030) |
9.2.0 |
9.2.1 |
||
|
03/2011 |
Created version 10.0.0 based on v. 9.2.1 |
9.2.1 |
10.0.0 |
||||
|
06/2011 |
52 |
RP-110686 |
0012 |
1 |
Specification Cleanup for Rel-10 |
10.0.0 |
10.1.0 |
|
12/2011 |
54 |
RP-111650 |
0013 |
1 |
Correction on the Length of Spare Extension |
10.1.0 |
10.2.0 |
|
12/2011 |
54 |
RP-111650 |
0014 |
1 |
Correction on the Spare Extension |
10.1.0 |
10.2.0 |
|
09/2012 |
– |
Update to Rel-11 version (MCC) |
10.2.0 |
11.0.0 |
|||
|
09/2014 |
Update to Rel-12 version (MCC) |
11.0.0 |
12.0.0 |
||||
|
12/2014 |
66 |
RP-142093 |
0020 |
1 |
Rapporteur Review |
12.0.0 |
12.1.0 |
|
12/2015 |
70 |
RP-152101 |
0021 |
2 |
Clarification on muting behavior in SC-PTM |
12.1.0 |
13.0.0 |
|
03/2016 |
71 |
RP-160447 |
0023 |
1 |
Clarification on SYNC |
13.0.0 |
13.1.0 |
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2017-03 |
SA#75 |
Promotion to Release 14 without technical change |
14.0.0 |
||||
|
2018-07 |
SA#80 |
– |
– |
– |
– |
Promotion to Release 15 without technical change |
15.0.0 |
|
2020-07 |
SA#88-e |
– |
– |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|
2022-03 |
SA#95-e |
Promotion to Release 17 without technical change |
17.0.0 |
||||