Special Articles on 3GPP Release 18 Standardization Activities (2)
Overview of 5G Core Network Advanced Technologies in 3GPP Release 18 —Core Network and Terminals—

3GPP Release 18 CT

Shunsuke Dojiri and Shin Nishida
6G-Tech Department

Akihiro Kubota and Maoki Hikosaka
Product Technology Department

Hiroshi Ishikawa
R&D Strategy Department

Ban Al-Bakri
MeadowCom

Abstract
In 3GPP Rel-18, functional enhancements and new technical areas were added to 5GC architecture with a focus on network selection and unavailability notification, positioning, roaming services, and network strengthening in relation to IoT and terminals. This article provides an overview of 5GC advanced technologies that have been enhanced in 3GPP Rel-18.

01. Introduction

• The 3rd Generation Partnership Project (3GPP) Core network and ...

  Open

  The 3rd Generation Partnership Project (3GPP) Core network and Terminals (CT) group defines protocols to support architecture defined by the Service and System Aspects (SA)^*1 group and specifies some functional enhancements requiring no changes to architecture. At 3GPP CT, the formulation of specifications continued in various fields in Release 18 (Rel-18) positioned as the initial release of 5G-Advanced. In particular, the following enhancements were made in network selection and unavailability notification, positioning, roaming services, and network strengthening in relation to Internet of Things (IoT) and terminals.

  • Given unstable radio conditions in a Public Land Mobile Network (PLMN)^*2 in which an IoT device is currently roaming, a function called Signal level Enhanced Network Selection (SENSE) was introduced in Rel-18 so that a PLMN could be selected based on signal level.
  • For the case that User Equipment (UE) cannot be used for a certain period of time due, for example, to an OS update or modem software update, Seamless User Equipment Context Recovery (SUECR) was introduced as a function that enables the UE and core network^*3 to maintain UE information for that period of time.
  • Specifications for location information services were studied from Rel-15 to Rel-17 including support for increasing the accuracy and shortening the acquisition period of location information in the vertical direction for Industrial IoT (IIoT)^*4 and other fields. In Rel-18, to further enhance those services, specifications were formulated to enable location information to be sent via the user plane^*5.
  • In roaming services, to strengthen security in the 5G Core network (5GC)^*6, there is a specification called Protocol for N32 Interconnect Security (PRINS) that enables additional functions offered by intermediary providers to be provided while making communications in the Home PLMN (HPLMN)^*7 and Visited PLMN (VPLMN)^*8 secure. However, in the process of implementing provided services, intermediary providers pointed out that there was some lack of functionality, so functional enhancements were made to PRINS to satisfy requirements.
  • The mobile network has become an indispensable infrastructure in people's lives, and this role is now expanding into a platform that supports all kinds of digitalization. A highly reliable system cannot be achieved without creating a robust mobile network. In the face of communication failures that have recently affected mobile communication operators in a number of countries, initiatives were taken in Rel-18 3GPP CT WG4 (CT4) to strengthen the network.

  This article describes the above enhancements.

  1. SA: The 3GPP group handling specifications for service requirements, architectures, security, codecs and network administration.
  2. PLMN: An operator that provides services using a mobile communications system.
  3. Core network: A constituent element of a mobile communications system governing registration control, session control, service control, etc. A mobile terminal accesses the core network via a radio access network.
  4. IIoT: IoT for industrial fields such as network connections for equipment and devices in a factory and elsewhere.
  5. User plane: Signals sent and received in communications that contain data sent and received by the user, or the constituent element of a mobile communications system that handles such data.
  6. 5GC: The fifth-generation core network specified by 3GPP for 5G access technologies.
  7. HPLMN: The operator where the user is a subscriber, namely, their home operator.
  8. VPLMN: The subscriber's roaming-destination operator.

02. SENSE

• 2.1 Overview

  Open

  A situation can arise in which an IoT device that is currently roaming in a PLMN will not switch to another PLMN despite unstable radio conditions, i.e., it will continue to roam in that PLMN. This is due to the method used in selecting a PLMN and the access technology to be used. In the conventional method, selecting an initial PLMN or recovering from the loss of coverage^*9 will not take into account cell^*10 signal level. Rather, it will only consider selection criteria broadcast in the System Information Block (SIB)*11 and the PLMN priority list. The above case arises because the UE selects a VPLMN with higher priority regardless of radio signal strength. Detecting this situation is not a simple matter for the operator, and identifying and correcting the problem requires manual intervention in the field.

  In response to this issue, Rel-18 introduced a function called SENSE that considers signal level in the initial step of network selection after device switch-on, after recovery from coverage loss, or in the step of periodic network reselection thereby enabling a network to be selected based on that signal level. With this function, the operator can control the UE's selection of a PLMN and access technology using a predefined radio signal threshold.

  The SENSE function is useful for stationary IoT devices deployed in a remote location in the same or another country making access by maintenance personnel difficult. Usage scenarios include water-level warning systems, temperature measurement of high voltage lines, and metering devices for power or water, all mainly used in European countries.

  We note here that IoT/UE devices related to SENSE are limited to those that support any one or a combination of Narrow Band-IoT (NB-IoT)^*12, Global System for Mobile communications Enhanced Data rates for GSM Evolution Radio Access Network (GERAN)^*13 Extended Coverage-GSM (EC-GSM)^*14 -IoT [1], and Evolved-Universal Terrestrial Radio Access (E-UTRA)^*15 [2] category M1/M2.

  The use of an operator-controlled signal threshold per access technology targets stationary IoT devices with no user intervention. Here, the allowable range of the threshold value lies between signal intensity in cell selection criteria and signal intensity in a high quality signal.

  2.2 SENSE Functional Overview

  The HPLMN, which manages subscriber information and the Universal Subscriber Identity Module (USIM)^*16 on the IoT device, configures the device to take into account signal level in each of the following steps: PLMN and access technology selection, initial network selection after device switch-on or after recovery from coverage loss, and periodic network reselection. The USIM implements Operator Controlled Signal Threshold per access technology (OCST) parameters, specifically, a list of combinations of signal thresholds controlled by the HPLMN and access technologies (such as GERAN, Universal Terrestrial RAN (UTRAN)^*17, and Evolved UTRAN (E-UTRAN)^*18).

  The OCST consists of unique values per access technology—it is applicable to all PLMNs that allow the UE to connect by the corresponding technology.

  The HPLMN configures, updates, or deletes OCST within the USIM either directly in advance (e.g., at time of shipping) or by using Non-Access Stratum (NAS)^*19 signaling^*20.

  In the automatic selection of PLMN and access technology, the procedure for using OCST as initial criteria has been extended as follows provided that USIM includes OCST settings and the UE is set so as to use SENSE. In the event that OCST cannot be achieved, the UE falls back on the procedure for selecting PLMN and access technology in existing specifications. Otherwise, in selecting a PLMN, the UE gives top priority to the PLMN having access technology for which the received signal quality is equal to or greater than OCST stored in the USIM. Furthermore, if there are multiple access technologies for which the received signal quality is equal to or greater than OCST stored in the USIM for registered PLMNs or their Equivalent PLMN^*21, which access technology the UE is to select depends on the implementation.

  If the average of received signal quality of registered PLMNs over a fixed period of time should drop below OCST, the UE attempts to receive services by a permitted PLMN and access technology for which the received signal quality periodically becomes equal to or greater than the threshold described above.

  1. Coverage: In wireless communications such as mobile phones, the area in which radio signals can be transmitted and received.
  2. Cell: The smallest area unit for sending and receiving radio signals between mobile communications network and mobile terminals.
  3. SIB: Various types of information broadcast simultaneously from a base station to UE including information needed for judging cell selection, PLMN selection, etc.
  4. NB-IoT: An LTE communications specification for low data rate communications for IoT devices (sensors, etc.) using a narrow bandwidth.
  5. GERAN: A 3GPP radio access network having a GSM radio transmission scheme.
  6. EC-GSM: A second-generation mobile communications scheme used by digital mobile phones.
  7. E-UTRA: An air interface used for advanced wireless access schemes in 3GPP mobile communications networks.
  8. USIM: An IC card used to store information such as the identifier of the subscriber to the mobile operator.
  9. UTRAN: A 3GPP radio access network using the W-CDMA system.
  10. E-UTRAN: A 3GPP radio access network using the LTE system.
  11. NAS: A function layer in the protocol stack between the UE and core network.
  12. Signaling: Control signals needed by UE to communicate with a base station and core network equipment.
  13. Equivalent PLMN: A PLMN handled the same as HPLMN at the time of PLMN selection by UE.

03. SUECR

• 3.1 Overview

  Open

  For the case in which UE cannot be used for a certain period of time due, for example, to an OS update or modem software update, SUECR is a function that notifies the core network of that unavailability period and maintains UE information in the UE and core network for that period of time. As background to this function, we consider the case in which UE becomes unavailable without notifying the core network or application server. At such a time, the application server considers the UE to be in an available state, so the possibility arises that operations that assume the UE to be available will be negatively affected. For example, an application server that collects data from UE will try to access a UE that has become unavailable any number of times even if there is an alternative UE from which data can be collected. To solve this problem, specifications have been established for sending out a notification about a UE in an unavailable state to get the core network and application server to perform appropriate exception processing.

  If an event occurs that temporarily makes the UE unavailable, then, given that the UE and core network support the use of an unavailability period, the UE will notify the Access and Mobility management Function (AMF)^*22 of the expected duration of that unavailability period. At this time, the UE can save Mobility Management (MM) Information^*23 and Session Management (SM) information^*24 in the UE's non-volatile memory^*25 or SIM and can reuse that information after the unavailability period ends.

  3.2 Notification of UE Unavailability Period

  Given that some kind of event (such as an OS update) is about to occur that will make a UE unavailable, the UE will execute a registration^*26 procedure or deregistration procedure before making itself unavailable. Specifically, if the UE can save MM Information and SM information in the UE's non-volatile memory or SIM, it will execute a registration procedure, and if it cannot, it will execute a deregistration procedure.

  1) Executing a Registration Procedure

  The UE notifies AMF of an unavailability period and its start time as part of a registration request (Figure 1 (1)). However, there are times in which the start time of the unavailability period is not included, and in such a case, AMF will regard the time of receiving the registration request as the start time of the unavailability period.

  When the UE's unavailability period begins (Fig. 1 (2)), AMF regards the UE to be unavailable until it completes its next registration (Fig. 1 (3)). At this time, if the Application Function (AF)^*27 has made a reservation beforehand with the UE that it is to be notified when the UE becomes unavailable, AMF will notify AF of the unavailability period. This enables both the AF and application server to recognize that the UE is unavailable.

  When the unavailability period ends, the UE executes a registration procedure unless AMF has indicated that registration is unnecessary (Fig. 1 (4)). Completion of the registration procedure enables the UE to communicate again.

  In addition, if the start of the unavailability period is delayed or cancelled, or if the actual unavailability period exceeds the period that the AMF has been notified of, the UE executes a registration procedure. At this time, the UE updates the unavailability period and its start time as needed and returns to step (1) in the flow.

  2) Executing a Deregistration Procedure

  The UE notifies AMF of an unavailability period as part of a deregistration request (Figure 2 (1)). At this time, AMF will regard the time of receiving the deregistration request as the start time of the unavailability period.

  On receiving the deregistration request, AMF regards the UE to be unavailable until it completes its next registration (Fig. 2 (2)). At this time, as in the case of executing a registration procedure, AMF will notify AF of the unavailability period provided that the AF has a reservation with the UE to be notified of such.

  When the unavailability period ends, the UE executes a registration procedure unless AMF has indicated that registration is unnecessary (Fig. 2 (3)). Completion of the registration procedure enables the UE to communicate again. In addition, operations in the case that the start of the unavailability period is delayed, etc. are the same as when executing a registration procedure as described above.

  

  1. AMF: A logical node that accommodates base stations (gNB) and provides mobility control and other services.
  2. MM information: Information involved in mobility management.
  3. SM information: Information involved in session management.
  4. Non-volatile memory: Memory whose stored information is not deleted even when power is turned off.
  5. Registration: In 5GS, mobile terminal registration of its current location information with the UDM.
  6. AF: A network function that provides an application.

04. Location Information Services in the 5G System

• Specifications for location information services in the 5G ...

  Open

  Specifications for location information services in the 5G system^*28 have been formulated from Rel-15 to Rel-17 to improve accuracy and shorten the acquisition time of location information in the vertical direction for IIoT, etc. In Rel-17, even more studies were conducted in 3GPP SA2 and SA6 on supporting functions in edge computing*29.

  In Rel-18, to enhance these services even further, provisions were made to transmit location information via the user plane, provide satellite-related support, reduce power consumption, and improve accuracy. The following touches upon two of these provisions: the transmitting of location information via the user plane and the use of the NetWork Data Analytic Function (NWDAF)^*30 in location information services to improve accuracy.

  4.1 Location Information Signaling via User Plane

  Though based on existing 3GPP specifications, provisions were made for transmitting location information via the user plane with the aim of reducing signal delay and overhead^*31 involved in the acquisition of location information. Here, specifications call for the AMF, UE, and Location Manager Function (LMF)^*32 to establish a safe connection between LMF and UE and for the UE to transfer LTE Positioning Protocol (LPP)^*33 via user plane protocol. These provisions do not affect Secure User Plane Location (SUPL)^*34 in Open Mobile Alliance (OMA) specifications currently in use, and SUPL can be switched to the method presented here as needed.

  1) Establishing an LCS-UP Connection between LMF and UE

  Figure 3 shows the flow for establishing a LoCation Services User Plane (LCS-UP) connection^*35. The AMF selects an LMF (Fig. 3 (1)) and requests an LCS-UP connection setup (Fig. 3 (2)). In response, LMF sends LCS-UP information to AMF to transfer that information to UE. This information includes the LMF's IP address^*36 or Fully Qualified Domain Name (FQDN)^*37 address, temporary UE identifier, security information, etc. (Fig. 3 (3)). The AMF sends that information to the UE (Fig. 3 (4)) and establishes a Protocol Data Unit (PDU) session^*38 and LCS-UP connection between the LMF and UE (Fig. 3 (5)).

  2) Changing the LCS-UP Connection between LMF and UE

  On detecting the need for changing the LMF or reestablishing a connection, the source LMF sends a message indicating the reason for the change to AMF (Figure 4 (1)-a). Alternatively, the need for changing the LMF using LCS-UP may be detected on the AMF side (Fig. 4 (1)-b). An LCS-UP connection is then established between the target LMF and UE (Fig. 4 (2)). Next, if a connection is still established with the source LMF, AMF notifies the LMF that the LCS-UP connection will be terminated (Fig. 4 (3)). Once the LCS-UP connection is terminated (Fig. 4 (4)), the source LMF responds to AMF (connection terminated) (Fig. 4 (5)).

  3) UE-based Positioning via LCS-UP

  A procedure supporting LMF requests for UE-based positioning is also specified. Using an LCS-UP connection, this procedure enables the LMF to request the UE for location information, provide the UE with data, and verify UE functions by sending an LPP message to the UE. The UE executes the requested positioning, calculations, etc. on the basis of this LPP message.

  

  4.2 Use of NWDAF in Location Information Services

  LCS Quality of Service (QoS)^*39 defined in TS23.273 [3] has three attributes with respect to location information: accuracy, response time, and QoS class. Among these, QoS class has requirements with respect to the other attributes of accuracy and response time. Specifically, QoS class can take on the values of Best Effort, Multiple QoS Class^*40, and Assured^*41.

  Within LCS QoS, the accuracy of location information is derived from data analysis executed by NWDAF whose analysis function is trained by machine learning^*42. The LMF uses an Application Program Interface (API)^*43 provided by NWDAF to judge the accuracy of positioning and take appropriate action.

  In this process, LMF requests NWDAF to analyze location accuracy and NWDAF performs that analysis. The LMF then judges whether accuracy has been satisfied based on the analysis provided by NWDAF.

  1. 5G system: The 5G network system, consisting of the core network, RAN, and communications devices.
  2. Edge computing: Technology that distributes edge servers closer to users to reduce latency by shortening distances.
  3. NWDAF: A network function specified in 5GC that returns the results of collecting and analyzing various types of data within the network.
  4. Overhead: Additional processing or load that occurs outside of the intended purpose for a given process.
  5. LMF: A function specified in 5GC that provides communications and control for location services.
  6. LPP: A protocol used between UE and LMF for achieving location information services.
  7. SUPL: A positioning scheme that uses the user plane for sending/receiving positioning signals between the UE and server.
  8. LCS-UP connection: A service that identifies a mobile terminal's position. The user plane path established between the UE and LMF.
  9. IP address: A unique identification number allocated to each computer or communications device connected to an IP network.
  10. FQDN: Specifies an exact location in the tree hierarchy of the DNS, specifying all domain levels.
  11. PDU session: A logical connection between the UE and data network.
  12. QoS: In this article, refers to LCS QoS having the three attributes of accuracy, response time, and QoS class with respect to location information.
  13. Multiple QoS Class: One type of QoS class in LCS QoS. If multiple settings have been made for the accuracy of location information but location information at the highest level of accuracy cannot be obtained, this class requests that location information be obtained by consecutively lowering the level of accuracy.
  14. Assured: One type of QoS class in LCS QoS. If one setting has been made for the accuracy of location information but location information at that requirement cannot be obtained, this class requests that the obtaining of location information be treated as a failure.
  15. Machine learning: A mechanism for making a computer learn useful evaluation criteria from sample data.
  16. API: Interface specification used for exchange between 5GC equipment.

05. Functional Enhancements for Intermediary Providers in Roaming (PRINS Enhancements)

• 1) Roaming Services

  Open

  Roaming services are provided to users of HPLMN through a VPLMN where an agreement exists. They include features such as functions and services only provided for roaming (such as a Welcome SMS when roaming to VPLMN for the first time and a data rate/limit control service when exceeding a certain volume of data), mediation of parameter values between telecommunication operators for compatibility purposes, and a mechanism for temporarily rejecting registration requests to force UE to attempt VPLMN reselection. Considering that these services and functions are applicable only to roaming users, which are a relatively small portion of all subscribers, and as the mechanisms are common to most mobile operators, an intermediary provider provides such services to mobile operators as a common solution. In addition, it frequently happens that such functionality is hosted by an external provider, and it often happens that mobile operators will delegate both the interconnect and such features to one intermediary provider. In 4G and previous generations of networks, interconnect providers have performed signal processing and conversion if required between the HPLMN and VPLMN for Diameter^*44, Mobile Application Part (MAP)^*45, General Packet Radio Service Tunneling Protocol for Control Plane (GTP-C)^*46, and GTP for User Plane (GTP-U)^*47 signaling to achieve functions and services unique to roaming.

  2) Enhancements in 5G—Ensuring Secure Communications—

  In these roaming-specific services, external entities provided by an interconnect provider can see/parse the content of all control signals, user data, etc. and can rewrite (or reject in some occasions) the procedure. However, this is not desirable from a security perspective since the external entity can view all contents exchanged. To deal with this issue, specifications for connecting HPLMN and VPLMN in a secure manner in 5GC were specified in Rel-15. Specifically, Secure Edge Protection Proxy (SEPP)^*48, which handles control plane signaling at the boundary between each PLMN, and an N32 interface, which securely connects the signaling plane between SEPPs of the mobile operators, were specified. Similarly, for user data, Inter PLMN User Plane Security (IPUPS)^*49 at the boundary and an N9 interface to achieve secure communications between IPUPSs were specified.

  3) 5G—Formulation of PRINS—

  While the specifications ensured secure communication between PLMNs as described above, it became apparent that the services and functions taken on by interconnect providers for roaming users, a relatively small portion of subscribers, as done in the past could not be achieved by the same conventional mechanisms. To deal with this problem, PRINS was specified in Rel-15.

  PRINS classifies control plane signaling into two parts. Parameters that need to be parsed (viewed or rewritten) by an intermediary provider are transmitted in plain text while information that needs to be concealed is transmitted encrypted between SEPPs. Additionally, to guarantee rewritten content (or that data has not been manipulated), a mechanism to guarantee signal integrity by enabling an intermediary provider to add a signature to rewritten content was specified.

  4) PRINS Functional Enhancements—Specification of Roaming5G—

  Initially, in the formulation of PRINS, the methods of implementing many of the roaming-specific services and functions provided by intermediary providers were vague. As a result, those providers later pointed out that they could not fully perform processing solely by parsing and rewriting signals as specified in Rel-15.

  In Rel-18, work item^*50 “Roaming5G” to enable the implementation of various services and functions provided only for roaming services was created. This work item reflected the requirements presented by the Global System for Mobile communications Association (GSMA)^*51 5G Mobile Roaming Revisited (5GMRR)^*52 group that had likewise been working on roaming-specific services and functions.

  In Roaming5G, the following enhancements were made to PRINS.

  • Methods of establishing/rejecting connections by an intermediary provider when using PRINS for N32-c (control signals for establishing N32 connections) were additionally specified.
  • In the exchange of N32-f (signals between entities of two mobile operators passing through an established N32 connection), specifications were added to enable an intermediary provider to detect errors in that exchange, to reject that exchange for reasons on the application level, or to transmit new signals.

  In particular, these enhancements enabled rejection at the application level, and have specified a HyperText Transfer Protocol (HTTP)^*53 Request/Response transaction independent of those exchanged between Network Functions (NFs)^*54 of VPLMN and HPLMN (for example, between AMF and Unified Data Management (UDM)^*55 or between visited Session Management Function (vSMF)^*56 and home SMF (hSMF)^*57). This allows an intermediary provider to directly transmit on N32-f and to directly transmit and receive signals with UDM, SMF, etc. via its own entity, which is a significant enhancement.

  For example, an intermediary provider can achieve the following.

  • If an N32 connection has not yet been established and an intermediary would like to temporarily halt a roaming agreement between two providers, it can reject an N32 connection by simply configuring within itself without having to change any configuration in either VPLMN or HPLMN entities (such as AMF and UDM) thereby achieving a temporary halt to roaming services (Figure 5).
  • If an N32 connection has already been established and an intermediary provider is similarly handling the processing of a roaming agreement on behalf of two operators, mechanisms can be added enabling the intermediary provider to temporarily halt services and functions or reject communications under certain conditions (including user-related conditions) (Figure 6).
  • If an N32 connection has already been established and a roaming service is in progress, an interconnect provider that wishes to halt user communications after a certain amount of data has been consumed can directly act on the NF within the PLMN by autonomously transmitting N32-f signals (Figure 7).

  The above capabilities make it possible to achieve through an intermediary provider roaming services and functions that could not be provided with 4G and previous generations of networks under the Rel-15 PRINS specification.

  

  1. Diameter: A communication protocol specified by IETF and 3GPP for managing position registration and other procedures.
  2. MAP: A communication protocol specified by 3GPP, for managing position registration and other procedures.
  3. GTP-C: A communication protocol that establishes communication paths within the core network for transferring user data.
  4. GTP-U: A tunneling protocol used by radio base stations and devices in the core network to transmit user data.
  5. SEPP: Equipment positioned at the boundary between the 5GC of different operators, to handle control signals.
  6. IPUPS: A function deployed in the User Plane Function (UPF) of one's own PLMN to prevent the entry of inappropriate traffic from the UPF of another PLMN.
  7. Work item: A study theme in 3GPP standardization.
  8. GSMA: An organization active in the development of the entire mobile telecommunications industry, and which consists of mobile network operators and mobile telecommunications industry-related members from around the world.
  9. 5GMRR: Group that is restudying 5G roaming in GSMA.
  10. HTTP: A communications protocol used between Web browsers and Web servers to send and receive HyperText Markup Language (HTML) and other content.
  11. NFs: Network functions that comprise the 5GC.
  12. UDM: A database that stores and provides information such as subscription data, location information, and session information in 5GC.
  13. vSMF: Session management function at the roaming-destination PLMN when the roaming user establishes a PDU session.
  14. hSMF: Session management function at the home PLMN when the roaming user establishes a PDU session.

06. Network Strengthening

• 1) IMS Network Strengthening

  Open

  The occurrence of a communications failure in the Internet protocol Multimedia Subsystem (IMS)^*58 can impact the audio, video, and SMS services of from several million to tens of millions of users. Here, the cause of such a communications failure may be signal congestion^*59 originating, for example, in erroneous routing settings or an operational error when transferring subscriber data.

  For this reason, 3GPP CT4 conducted studies to identify scenarios of communications failures, bolster means of restoration, and develop prevention mechanisms. Although restoration and substitution procedures for handling the failure of some IMS equipment had already been specified in TS23.380 [4], the scope of these studies was taken to be failure cases that had yet to be specified. For example, congestion in the Home Subscriber Server (HSS)^*60 subscriber database and Unified Data Repository (UDR)^*61 is a case connected to large-scale failure. As of the writing of this article (June 2024), solutions with respect to this case had been made by various companies and compiled in TR29.866 [5]. To give an example, one solution that has been proposed for handling congestion in the subscriber database is to continue routing using data stored in other equipment (e.g., Call Session Control Function (CSCF)^*62, Application Server (AS)). In Rel-18, the study phase has been launched and discussions are progressing. The plan going forward is to evaluate the validity of each solution proposed in this study phase and to establish specifications as needed in Rel-19 and beyond.

  6.2 Canary Release

  A canary release (CANARY_RELEASE) is a technique for handling software releases and updates. If a new version of certain software is provided all at once to all users as is often the case, the occurrence of bugs or other problems in that new version has the potential of seriously impacting the entire system. A canary release, in contrast, releases a new version of software in a limited manner to only some users or devices so that the impact of any bugs or compatibility problems will not extend beyond those users or devices.

  This technique is already known through its adoption in Web service systems, but in mobile networks as well, the canary release has been specified for 5GC in Rel-18. In other words, when making a software update in an NF, the new version of that software can be provided and tested only for users limited by identifiers (such as a range of identifiers in SUbscription Permanent Identifier (SUPI)^*63).

  The procedure for carrying out a canary release in terms of registered information in the Network Repository Function (NRF)^*64 is shown in Figure 8 [5][6].

  1. Set the NRF registered state of the canary-release test target NF (NFp#A^*65) to UNDISCOVERABLE and notify the other NF (NFc^*66) of that fact.
  2. NFp#A is placed in standby until all sessions accommodated by its own equipment are released.
  3. As an option, the NRF registered state of NFp#A can be set to SUSPENDED and NFc notified of that fact. This guarantees that there is no signal transmission from NFc to NFp#A.
  4. Execute NFp#A software update.
  5. NRF sets the NRF registered state of NFp#A to CANARY_RELEASE and simultaneously sets identifiers (SUPI range, etc.) as selection conditions.
  6. NFc performs an NFp discovery procedure with NRF as usual and obtains REGISTERED or CANARY_RELEASE information for each NFp.
  7. NFc selects from the list of NFp candidates and accesses NFp#A if there is a match with canary release conditions (e.g., the SUPI that NFc is processing is included in the SUPI related to NFp#A).

  

  1. IMS: A subsystem that provides IP multimedia services (e.g., VoIP, messaging, presence) on a 3GPP mobile communications network. Session Initiation Protocol (SIP) is used for the calling control protocol.
  2. Congestion: A state where communication requests are concentrated inside a short time period and exceed the processing capabilities of the network, thereby obstructing communications.
  3. HSS: A subscriber information database specified by 3GPP related to Evolved Packet Core (EPC) and IMS. It manages authentication and location information.
  4. UDR: A repository in 5GC.
  5. CSCF: A centralized function in IMS performing call control of mobile terminals.
  6. SUPI: Information used in the 5GS to identify subscribers.
  7. NRF: Equipment that performs registration and provides information to enable the discovery of NF producers.
  8. NFp#A: NF producer. Name given to an NF when focusing on the provision of services to other NFs.
  9. NFc: NF consumer. Name given to an NF when focusing on the receiving of services from other NFs.

07. Conclusion

• This article described enhancements to 5GC specified ...

  Open

  This article described enhancements to 5GC specified in Rel-18 with a focus on network selection and unavailability notification, positioning, roaming services, and network strengthening in relation to IoT and terminals. At 3GPP, Rel-19 studies are now in progress with the aim of making further enhancements to 5G-Advanced. Going forward, NTT DOCOMO will continue to contribute to 5G-Advanced standardization activities at 3GPP and to contribute to the further development of mobile communications.

• REFERENCES

  Open

  1. [1] 3GPP TS43.064 V18.0.0: “GPRS; Overall description of the GPRS radio interface; Stage 2,” Mar. 2024.
  2. [2] 3GPP TS36.306 V18.2.0: “E-UTRA; User Equipment (UE) radio access capabilities,” Jun. 2024.
  3. [3] 3GPP TS23.273 V18.6.0: “5G System (5GS) Location Services (LCS); Stage 2,” Jun. 2024.
  4. [4] 3GPP TS23.380 V18.0.0: “IMS Restoration Procedures,” Mar. 2024.
  5. [5] 3GPP TR29.866 V1.0.0: “Study on IMS Disaster Prevention and Restoration Enhancement,” Jun. 2024.
  6. [6] 3GPP TS29.510 V18.7.0: “5G System; Network Function Repository Services; Stage 3,” Jun. 2024.

VOL.26 NO.3