Editor’s Note: SRG has been participating in 3GPP standardization meetings since September 2015 when the standards body held its first workshop on 5G. Prior to that initial 5G workshop, SRG closely followed the various standardization efforts since they provide great insight into the future capabilities of next-generation cellular technologies and the operator roadmaps. Mike Thelander, CEO and founder of SRG, has covered additional Third Generation Partnership Project insights here and here.
This contribution covers the basic attributes of a 3GPP standard, regardless of how many G’s it has, with a particular focus on how the submissions make their way into one of the specifications that actually define how the standard works; and how innovative concepts work their way from being a twinkle in someone’s eyes to their place within a specification(s), a process that more likely than not never completes the journey, suggesting very few companies have the wherewithal to pursue the endeavor.
Releases and Specifications and Standards, Oh My! In the Wizard of Oz, Dorothy faced her fears of the unknown by singing a song aptly paraphrased for the standardization process. Although no child wakes up from a bad dream about a “Release Gone Rogue,” it is likely there are several misconceptions and unknowns pertaining to the dependencies of these three topics, or more specifically, the roles that specifications have on standards and the relationship between releases and standards. Let’s start with the latter and work backwards.
In the context of 3GPP, a standard is collection of documents which defines the capabilities of a suite of wireless capabilities and how those capabilities are implemented. Fun Fact – 3GPP doesn’t get to decide the 5G requirements and if its current standardization work will result in the next G standard. Instead, this role belongs to the ITU (International Telecommunication Union), which also identifies and allocates radio frequencies for specification applications, such as cellular services. I mention spectrum management since it has a big impact on how 3GPP determines its priorities and how it selects the technical attributes in its work. For example, 3GPP wouldn’t select millimeter wave frequencies for 5G unless it knew the ITU was going to allocate millimeter wave frequencies for cellular applications. Presently, 3GPP is working on an ITU submission which provides a self-evaluation of the new standard it is currently pursuing. This self-evaluation will provide evidence the proposed standard will meet the ITU requirements, but ultimately the ITU will determine the merits of the 3GPP work and whether the 3GPP submission receives the 5G moniker.
Fun Fact Number II – the 3GPP “5G” submission to the ITU is going to include elements of LTE in the submission. Although 3GPP is defining a new air interface and network architecture as part of the ongoing standardization process, it also recognizes that LTE can achieve some of the ITU requirements for 5G. Specifically, 3GPP is going to propose NB-IoT, an LTE-based solution, to meet the ITU 5G requirements for massive machine-type-communication. (mMTC). From the perspective of the ITU, it doesn’t dictate the need for a new technology or air interface when it awards the 5G title. Instead, it merely establishes performance requirements, which the new standard must meet.
Eventually, 3GPP will use a new air interface for mMTC, which brings us to the topic of Releases. There has been a fair amount of press about Phase 1 and Phase 2 of 5G, also known as Release 15 and Release 16. The concept of a release extends back to the days of 3G when Release ’99 defined the initial 3G standard, followed by multiple releases which introduced improvements to the original standard. Release 5, for example, introduced HSDPA, which meaningfully improved the downlink capabilities of the initial 3G standard.
Things got a bit more interesting with Release 8, which took 3G downlink performance to the next level with HSPA+. Release 8 also included something called E-UTRAN (Evolved UMTS Radio Access Network), which among other things introduced a new air interface call LTE. Put simply, Release 8 included the new LTE air interface along with critical enhancements to the existing air interface. Fun Fact III – 3GPP never intended for LTE Release 8 to be called 4G. Instead, the original plan was to introduce advancements to LTE in Release 10 (aka LTE-Advanced) which would ensure LTE met the ITU requirements for 4G. One thing led to another, the marketing dog started wagging the technology tail, and everyone now assumes LTE equals 4G. Luckily, most LTE networks now support carrier aggregation, a critical Release 10 feature, so it is a moot point whether LTE Release 8 was 4G or not.
Long story, short: Release 15 and Release 16 will include enhancements and new features for LTE (or is that 4G?), along with introducing 5G functionality. I’ll also bet the ranch that 3GPP doesn’t stop enhancing 5G when they complete Release 16 in 2019. Instead, 3GPP will introduce new features and enhancements in Release 17, Release 18, etc., thus keeping everyone involved in 3GPP standardization gainfully employed for the next decade. God forbid if anyone calls it 5.5G!
To wrap up this section, let’s distinguish between specifications and standards. The former, specifications, is really a subset of the latter, standards. 3GPP currently defines 28 groups, or series, of specifications which impact 3G and subsequent standards. Each series addresses one facet of the standard. The 24 series, for example, deals with signaling protocols, and the 21 series addresses requirements. Two standouts are Series 36 (LTE, including LTE-Advanced/Pro radio technology) and Series 38, which tackles 5G. Taking it one step further, there are some 246 different documents that fall under the 36 series of specifications with some of these documents comprised of hundreds and hundreds of pages, complete with appendices and enough tables with very granular requirements to choke a horse.
Although some of the documents pertain to study items that have or will soon be completed, most of these documents in the 36 series of specifications involve technical specifications pertaining to one feature or an enhancement to one feature. For example, there are innumerable documents in the 36 series that deal with carrier aggregation, including various combinations of the number of downlink and uplink channels, carrier aggregation in new bands, and carrier aggregation between LTE FDD and LTE TDD. Generally, 3GPP must update these documents with each new release.
In theory, someone who reads and understands everything in all these documents could build a standards-compliant LTE system that “talks” with all vendors’ infrastructure, devices and chipsets.
From Concept, to Submission, to Specification. In an earlier article, SRG discussed company submissions, what they entail, and how/why/if they are presented in a 3GPP meeting. I’d like to take it an additional step and discuss one unique type of submission and then how submissions find their way into specifications.
There are literally zillions – OK, tens of thousands – of submissions that companies introduce during the standardization process. The most mundane ones, as noted in an earlier article, apply existing functionality to a new frequency band. The most interesting submissions involve entirely new concepts that significantly alter the capabilities of an existing standard or bring new promise with the next standard. Examples, which come to mind, include carrier aggregation, LAA (License Assisted Access), LTE-Broadcast (eMBMS), and ICIC – intercell interference coordination, along with eICIC (e = enhanced) defines how large LTE base stations and nearby LTE small cells allocate network resources to mobile devices while minimizing interference. Admittedly, it sounds a bit geeky, but it is really kind of cool.
When a company, or companies, introduces a new concept, it’s time to sit back and take notice. In part, there is a bit of “why didn’t I think of that,” but there is also a recognition that this new technology concept will take the cellular industry in an entirely new direction with far greater capabilities than imagined. One shouldn’t take these new technology concepts for granted since it takes a lot more than a really cool idea to get the 3GPP member companies excited and on board. Instead, when companies present these new technology concepts, they must come prepared with a wealth of supporting documentation, including “proof” the idea will work, the impact the concept will have on the existing technology, and the proposed means of implementing the concept.
Ultimately, 3GPP will do its own investigative work, and likely tweak the concept and how it is implemented, if and when they actually approve it. However, there is still a tremendous amount of R&D investment required by the initiating company that makes it all possible. The company also can’t force its ideas into the standard, no matter how great they think the new idea is, since 3GPP is consensus driven, as discussed in the last article. Having attended 3GPP meetings for the last two years and followed the process for more than the last decade, I can safely say that the success ratio for this endeavor isn’t great and there are only a handful of companies with the wherewithal to make it possible.
Concept submissions don’t find their way directly into one of the hundreds of specifications discussed in the earlier section, since there is a whole lot of work required between concept and implementation. However, company submissions do form the basis of the specifications, so a short commentary on the origination of specifications is in order.
There isn’t a hard and fast recipe for how a specification gets written, but there are a few generalities that always apply. Company submissions are always the starting point since these submissions form the basis of how study items and work items get started. Study Items, as noted in the last article, precede the Work Items with the Work Item activities ultimately defining what gets written in the specification(s) – nearly all work items impact multiple specifications.
During the Work Item phase, companies make submissions which address all aspects of the proposed change or new feature. With multiple submissions from different companies with competing ideas there is inherently conflict and contradiction regarding how something should be implemented. Given the consensus nature of 3GPP, multiple submissions eventually morph into a way forward, which is essentially a compromised approach that everyone can accept. This debate and discussion takes place during 3GPP meetings when delegates meet face to face, as well as in between meetings when the work is done via email.
At some point in the process it is time to put pen to paper, meaning that some unlucky soul gets the task of writing the new specification or, more likely, updating an existing specification. Fortunately, the writer, or Rapporteur, has a lot of help in the process since earlier company submissions and their evolution, along with meeting notes and way forward documents provide the necessary content. When the Rapporteur is “done”, he or she provides the updated specification for peer review – even this activity involves a submission so that everything is well documented in the standardization process. Inevitably, additional changes, additions and deletions, will be required to the specification before everyone comes on board and approves the new specification. These edits are done through what is known as a Change Request (CR), which is another type of submission.
All told, a specification is hardly ever finished. Its lifecycle begins with a draft template, consisting largely of boilerplate text and high-level language that everyone accepts. Over multiple months, the specification begins to take shape until ultimately it becomes a complete specification that includes everything needed to implement it. At this point, the CR process continues as companies identify [hopefully minor] corrections that are needed to make wording clearer and consistent with other specifications. And then, once things start to wind down, the process begins all over again when the specification undergoes a potentially major revision – likely additional language – to support the next release of the standard.
