Standalone 5G moved the change into the network core
Standalone Release 15 gave 5G an independent deployment architecture. Turning it into a paid service required operators and software suppliers to resolve integration, reliability and customer demand.
On 14 June 2018, 3GPP reported completion of the standalone Release 15 specifications for 5G. The milestone complemented the non-standalone New Radio specifications approved in December 2017 and gave the new radio technology an architecture for independent deployment. It was an important step towards commercial systems, with implications well beyond the equipment at a mobile tower.
The network core would coordinate access, mobility, subscriber information, policy and data services through a more modular architecture. That created possible roles for software suppliers in integration, testing and operations. It also made the distance between a standard and a paid service especially important. A specification could define a capability without establishing that an operator had deployed it, that a device supported it or that a customer had a reason to buy it.
Approval was one stage in a longer programme
The standalone specifications built on the earlier New Radio approval and the architecture working group's stage 2 description of the overall system, including features, services and information flows. Radio, security, operations and protocol groups then completed the further work needed for standalone deployment. The sequence mattered because different parts of the system became defined at different stages.
- December 2017
Non-standalone NR approved
3GPP reports approval of the first non-standalone New Radio specifications, with further work needed for standalone operation.
- December 2017
System architecture defined
Stage 2 describes features, services and information flows; more detailed work continues across technical groups.
- 14 June 2018
Standalone Release 15 completed
TSG #80 approves the standalone specifications, complementing non-standalone operation and supporting independent NR deployment.
Specification milestones reported by 3GPP. Operator deployment and commercial service availability followed their own timetables.
For a startup deciding when to invest in a product, this sequence matters. Early architecture documents can reveal a future integration point before equipment is ready for procurement. They can also leave implementation details and delivery schedules unresolved. A company committing engineering resources needs to know which part of the standard is stable enough for its product and which partners must finish their work before a customer can use it. Release 15 did not include every enhancement that later 5G releases would address.
The core became a software integration problem
The architecture used service-based principles between network functions in the core control plane. Permitted functions could discover and use one another's services through a common framework, with network repository functions supporting discovery. The working group chairman described modular, reusable and self-contained functions designed to benefit from developments in virtualisation and software. Those principles applied to a defined part of the architecture; radio and data interfaces retained their own requirements.
Modularity can create room for a specialised supplier, but it also creates interfaces that must behave correctly together. An operator needs to understand how a function is configured, upgraded, monitored and restored after failure. Software companies could address those tasks through test systems, operational tooling or components that fit an established deployment. The investment question was whether a supplier could make a particular integration substantially easier while meeting the operator's requirements for continuity, support and compatibility with its existing network.
Slicing did not settle the service promise
Network slicing allowed an operator to compose functions and resources for different user groups or business requirements. The architecture explanation described slices with different features, availability or capacity, and even separate slices with identical functions serving different commercial segments. It also specified a boundary: 3GPP's architecture defined slicing for the resources composing the mobile network within its scope. Slicing the underlying transport network was a separate matter. The word alone could not prove a complete application service level.
Edge computing support had a similarly concrete scope. The architecture included ways to relocate an IP anchor, maintain sessions under different continuity modes and break out selected traffic towards application functions. These mechanisms could support placing an application nearer the user. They did not establish a universal latency result. A factory, transport operator or other enterprise would still need evidence about the full path from device to application, including the radio environment, transport, computing resources and what happened during faults or movement.
A buying case still needed an operator
The industry announcement anticipated new business models and stronger links between mobile operators and industrial customers. Those ambitions still needed paying customers. A startup building on the standard had to establish who controlled deployment, who could expose the required network capability and who would support the customer when a service crossed several suppliers. A successful demonstration did not by itself answer those commercial questions.
A narrower initial product could be easier to evaluate: a testing tool that reduced acceptance work, monitoring that helped locate a service failure, or an application with a specific reason to use a particular network capability. In each case, the company needed an observable customer benefit and a route through procurement. Partnerships could provide that route while creating dependence on an operator's timetable and commercial priorities.
The standalone specifications made an independent 5G system technically definable. Their venture significance lay in the work needed to make that system usable and dependable. Teams could build against clearer interfaces, but customer value still had to be demonstrated at the point where network behaviour affected a real operation.
Sources
Published
