Questions relating to 3GPP Releases
Question 1: How do these standards actually fit with capability that is realistic and achievable in a realistic timeframe?
Response:
This is a great question as there is no compulsion or commitment required by any hardware or software vendor to build anything that has been written into a standard. Most features require changes to multiple standards.
From my experience any change to a standard or addition of a feature requires a sponsor to submit a proposal into a working group of an international standards body. It can take years for some features to get on a candidate list for a study and then definition into a Release. It all comes down to lobbying.
Sponsors usually bring requests as a result of either; customer demand, government regulation, or their own R&D. It is not unusual for a vendor to bring a request to the standards body for something they have already built and implemented for a single customer. These are usually referred to as pre-standard deployments.
As an aside issue there are times where vendor R&D generates patents that when included into standards as features result in royalties being paid to the vendor by anyone else who implements the specific feature.
One of the rules of thumb I have used in the past is that there is usually 12-18months between a feature being ratified (agreed) and it appearing in commercial hardware/software IF there is the commercial impetus (sales $$) for vendors to build the feature. There are always features that make it into standards you never seem to happen in the real world. Sometimes they are just before their time but usually either the original customer demand dries up or another feature (or even a different technology. Eg wifi instead of cellular) is more appropriate to meet the customer need.
For the mobile to mobile services that appeared in release 13 it would seem this is simply a case of not enough customer demand to warrant the development in both the network equipment and/or the device market.
Question 2: when the standards are optional and in some cases aren’t even delivered by suppliers?
Response:
In my experience one of the key advantages of standards is that they allow you to change vendors for individual functions of your infrastructure as well as provide a level of assurance of inter-operation with other networks and devices. For the cellular world inter-operation of a feature with the widest range of devices is critical.
A simple example is Picture Messaging Platforms. Let say there are three places where standards are important.
– The format of a Picture message between a customer device and a Picture message platform
Standardisation here means that any device connected to your network can send and receive Picture messages to other customers on your network.
This is the sort of standard that is considered mandatory
– The protocols and interface standards between two Picture message platforms
Standardisation here means that customers on one network can send Picture messages to customers on another network.
This is the sort of feature that may not be important initially becomes mandatory
– The protocols and interface standards between a picture message platform and the other cellular network components.
Standardisation here means that when you want to change your supplier of picture messaging platform this can be done with minimal impact to other systems within the cellular network. It also means you can change components of your cellular network without major changes to your picture messaging platform.
Compliance to a standard could be considered “optional” if the network operator is happy with a lock in between their picture messaging platform supplier and the supplier of other cellular network components.
Picture messaging is a real example of how the development and commercialisation of standards for 2 and 3 came much later than the commercialisation of the standard for 1. In fact the telcos generally decided that number2, the ability to send/receive picture messages with customers of their competitors was not even required initially. Many Telcos chose to deploy picture messaging as a service as a competitive advantage prior to the development (or commercialisation) of the standards for 2 & 3. Over time 3 became important as newer vendors for picture messaging platforms came out with more features and the telco wanted to replace their older platforms. It was then customer demand on the telcos that drove the commercialisation of standards for 2.
Whilst not always imperative for an initial deployment standardisation can become key for long term cost management.
As a linkage to a different conversation it is my view that public safety may consider compliance to a standard for the interface between a digital LMR network and a MCPTT platform as “optional” for initial deployment if the two systems come from the same vendor. This might enable the vendor to provide a single management system for talk groups and user authentication which public safety might consider of greater benefit that managing these with two systems through a console interface. But public safety might contract the vendor to upgrade their systems so that the interface is standardised within short period (a couple of years). This then enables us to change the vendor for one of the systems in the future. Public safety then have options but with non-standard interfaces we have no options.