WO2022066078A1 - Procédés et systèmes de détection d'une ressource défectueuse d'un fournisseur de réseau dans un réseau soa/5g - Google Patents

Procédés et systèmes de détection d'une ressource défectueuse d'un fournisseur de réseau dans un réseau soa/5g Download PDF

Info

Publication number
WO2022066078A1
WO2022066078A1 PCT/SE2020/050907 SE2020050907W WO2022066078A1 WO 2022066078 A1 WO2022066078 A1 WO 2022066078A1 SE 2020050907 W SE2020050907 W SE 2020050907W WO 2022066078 A1 WO2022066078 A1 WO 2022066078A1
Authority
WO
WIPO (PCT)
Prior art keywords
instance
provider
consumer
nrf
response
Prior art date
Application number
PCT/SE2020/050907
Other languages
English (en)
Inventor
Kiran JIDHAV
Stefan Gustafsson
Robert TÖRNKVIST
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/SE2020/050907 priority Critical patent/WO2022066078A1/fr
Publication of WO2022066078A1 publication Critical patent/WO2022066078A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/14—Backbone network devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/24—Interfaces between hierarchically similar devices between backbone network devices

Definitions

  • the present invention generally relates to communication networks and, more particularly, to mechanisms and techniques for detecting failed network resources in such systems.
  • the 5G architecture is based on Service Oriented Architecture (SOA) OR Service Based Architecture (SBA).
  • SOA Service Oriented Architecture
  • SBA Service Based Architecture
  • the Network function Repository Function is a node which provides a "Service Broker OR Service Registry or Service Repository” function as defined by the SOA or SBA.
  • the other Network Functions (NFs) in the 5G architecture can be "Service Providers" or “Service Requester/Consumer” or both.
  • the 5G NFs both Service Providers and Service Requesters/Consumers
  • the NRF itself also provides services to the other NFs for NFManagement (register, update or deregister its profile in another NRF) and NFDiscovery (which allows a Network Function to discover services offered by other Network Functions, by querying the NRF).
  • the 3GPP technical specification 29.510 provides the current technical specification for Network Function Repository Services for 5G systems. More specifically, sections 5.2.2.2.2 and 5.2.2.3.2 in this technical specification describe how NF registration with the NRF is performed and how the NF informs the NRF that it is still operational, respectively. Regarding the latter function, the standards specify that each registered NF shall contact the NRF periodically to indicate that it is still operational by sending a “heart-beat” signal. The time interval at which the NRF shall be contacted is deployment-specific, and it is returned by the NRF to the NF Service Consumer as a result of a successful registration.
  • the NRF when the NRF detects that a given NF has not updated its profile for a configurable amount of time (longer than the heart-beat interval), the NRF changes the status of the NF to SUSPENDED and considers that the NF and its services can no longer be discovered by other NFs via the NFDiscovery service.
  • the NRF notifies NFs subscribed to receiving notifications of changes of the NF Profile that the NF status has been changed to SUSPENDED. This “heart-beat” technique for discovering NF failure is described in more detail below with respect to Figure 2.
  • the existing method for tracking the operational status of NFs in a 5G network as described in the 3GPP TS 29.510 has the following drawbacks. It relies only on the fixed interval-based Heart-Beat information being sent from the network resources to the NRF to be able to detect whether a network resource is healthy/available/functional or not. If a network resource fails/goes down immediately after sending the heart-beat information to NRF, the NRF will not be aware that the network resource has gone down until the next interval of heart-beat, when it will miss the heart-beat from the network resource and thus determine that the network resource has failed.
  • the time between when a network resource has failed and when the NRF detects the failure of the network resource can be quite long (depending on what has been configured as the heart-beat interval).
  • this time i.e., the time between the failure of network resource and detection of it by NRF
  • the NRF (before it detects the failure of a network resource) shall keep providing information about the unavailable network resource to the consumer network functions who request the functionality provided by the (now) unavailable NF. This, in turn, may lead to delay in response times for a service request (where the consumer network function sends a request to the unavailable network resource and after response time-out, tries some other resource) or even temporary unavailability of a service.
  • Embodiments enable network function resource function nodes in, for example, a 5G telecommunication network to more rapidly detect network node failures.
  • a method for indicating failure of a provider network function instance by a consumer network function instance in a telecommunication network including requesting, by the consumer network function (NF) instance, a service from the provider NF instance; failing to receive, by the consumer NF instance, a response from the provider NF instance; and transmitting a signal, by the consumer NF instance, towards a network function repository function (NRF) node indicating a lack of response to its request from the provider NF instance.
  • NRF network function repository function
  • a processor and interface configured to request, a service from a provider NF instance and which fail to receive a response from the provider NF instance; and which are further configured to transmit a signal, by the consumer NF instance, towards a network function repository function (NRF) node indicating a lack of response to its request from the provider NF instance.
  • NRF network function repository function
  • a method for detecting failure of a provider network function instance includes receiving, by a network function repository function (NRF) node from a consumer network function (NF) instance, a message indicating a lack of response by the provider NF instance to a request for service from the consumer network function (NF) instance; and taking, by the NRF node, remedial action associated with the message indicating a lack of response by the provider NF instance to a request for service.
  • NRF network function repository function
  • a network function repository function (NRF) node includes a processor and interface configured to receive, a message from a consumer NF instance indicating a lack of response by a provider NF instance to a request for service from the consumer network function (NF) instance; and further configured to take remedial action associated with the message indicating a lack of response by the provider NF instance to a request for service.
  • NRF network function repository function
  • Figure 1 illustrates an architecture according to an embodiment
  • Figures 2A-2C show a signaling diagram according to an embodiment
  • Figures 3A-3E illustrate a use example according to an embodiment
  • Figure 4 shows a flowchart for indicating failure of a provider network function node according to an embodiment
  • Figure 5 illustrates a flowchart for detecting failure of a provider network function instance according to an embodiment
  • Figure 6 depicts a communication node according to an embodiment
  • Figure 7 depicts an electronic storage medium on which computer program embodiments can be stored.
  • Embodiments described herein support various techniques for network functions which are consuming services (referred to herein as “consumer NFs” or “consumer nodes”) from other network functions which provide services (referred to herein as “provider NFs” or “provider nodes”) to enable the consumer NFs to inform the NRF when a provider NF registered with the NRF has failed to respond to a request for service.
  • the consumer NF can inform the NRF of information associated with a failed or potentially failed provider NF in conjunction with sending its own heart-beat signal to the NRF.
  • the consumer NF can inform the NRF of information associated with a failed or potentially failed provider NF in a signal to the NRF which is separate from the sending of its own heart-beat signal to the NRF.
  • the NRF 200 is the network function that acts as a “Service Registry” where other network functions register and publish the services which they provide or consume.
  • the Charging Function (CHF) 202 is the network function responsible for providing “Charging” and “Policy” services and has multiple network function instances, i.e., NFi1 , NFi2, NFi3... NFin.
  • the Session Management Function (SMF) or Policy Control Function (PCF) 204 is the network function that consumes “Charging” and “Policy” services provided by CHF 202 and may also have multiple network function instances.
  • SMF Session Management Function
  • PCF Policy Control Function
  • the terms “instance” or “instances” are used herein to include both virtual servers in a cloud environment as well as physical servers or nodes which are all used to supply sufficient bandwidth in a telecommunication system to support the CHF, SMF, PCF or other functions.
  • the NRF 200 Given the exemplary network architecture shown in Figures 2A-2C and assuming that the heart-beat interval is configured for every 1 hour, the NRF 200 will expect that after an NF or NF instance registers itself, the NF will send a heart-beat signal every 1 hour after the successful registration (as long as it remains operational). To better understand the challenges presented by this conventional mechanism for the NRF 200 to track NF operability consider the following scenario
  • each of the CHF 202 instances N Fi 1 , N Fi2, NFi3... NFin registers in the NRF 200.
  • the steps/signals illustrated in block 208 show the registration process of the CHF instances NFi1 , NFi2, NFi3... NFin, in the NRF 200 by sending a registration signal to the NRF 200.
  • each CHF 202 instance receives a registration successful response signal which includes the time interval (e.g., 1 hour) for sending heart-beat signals back to the NRF 200.
  • the time interval e.g., 1 hour
  • other NFs like the SMF or PCF 204 also register in the NRF 200 and send heart-beat signals, but these other NFs are not shown explicitly in Figures 2A-2C for brevity.
  • NRF 200 receives a request for service discovery form SMF/PCF 204 for charging/policy services. Still unaware of the NFi2 instance failure, the NRF 200 responds to SMF/PCF 204 with the information about network functions that provide the charging/policy services via signal 214. In this response 214, NRF 200 also includes NFi2 as one of the resources that provides the requested charging/policy services.
  • SMF/PCF 204 randomly (or otherwise) selects the NFi2 instance from the list that the NRF 200 has provided and requests service from NFi2. As NFi2 is unavailable, there is no response to the request 216 from SMF/PCF 204. Therefore, at step 218, the request from SMF/PCF 204 times out due to no response from NFi2 and SMF/PCF 204 has to retry the request towards some other NF instance from the list that the NRF 200 has provided. As will be appreciated by those skilled in the art, this adds to the delay in the actual provision of service to the SMF/PCF 204 and, if there were more NF instances that were unavailable, the delay would increase further.
  • step/signal 220 SMF/PCF 204 retries the request to a different NF instance from the list provided by the NRF 200 and, at step/signal 222 gets a successful response.
  • this wait and retry has caused delay in the actual response to the end-user service.
  • the NRF 200 is still unaware that NFi2 is down.
  • Steps 216, 218, 220 and 222 may even be repeated by SMF/PCF 204 as it is acting on information received from NRF 200, randomly requesting service from N Fi2, reaching a time-out status and then retrying to a different NF instance to eventually obtain the service. This has the effect of increasing the load/traffic towards other NF instances of CHF 202 as shown in steps 224, 226, and 228, while NRF 200 continues to be unaware of the NFi2 instance failure.
  • NFi1 , NFi3... NFin send their heart-beat signals and load information to the NRF 200 at steps 230, 232 and 234 (and NRF responds at steps 236, 238 and 240).
  • NFi2 does not send any heart-beat signal and load information to the NRF 200 as it has crashed (step 242). It is only after this point that the NRF 200 becomes aware that NFi2 is not available and has crashed and changes NFi2 instance status to SUSPENDED such that NFi2’s services can no longer be discovered by the NFDiscovery service.
  • NRF 200 then notifies the other NFs (e.g., SMF/PCF 204) that have subscribed to receiving notifications about the unavailability of NFi2 and its status being changed to SUSPENDED.
  • the NRF 200 since the NRF 200 has no way of quickly finding out that a network resource has crashed, it waits for the next heart-beat interval to determine whether a certain network resource is working or not.
  • the heart-beat interval was considered to be 1 hour, but in reality, it can be even longer which means there will be an even longer service disruption during the time between when a network resource fails and its eventual determination by NRF 200 as having failed.
  • the NRF 300 is the network function that acts as a “Service Registry” where other network functions register and publish the services they provide or consume.
  • the CHF 302 is the network function responsible for providing “Charging” and “Policy” services and has multiple network function instances (i.e., NFi1 , NFi2, NFi3...
  • the SMF or PCF 304 is the network function that consumes “Charging” and “Policy” services provided by CHF 302 and, in this embodiment, also has multiple instances (i.e., SMF or PCF 1 , SMF or PCF 2, SMF or PCF 3... SMF or PCF n).
  • SMF or PCF 1 SMF or PCF 2
  • SMF or PCF 3 SMF or PCF n
  • the heart-beat interval is configured for every 1 hour, such that the NRF 300 will expect that after a NF or NF instance registers itself, it will send a heart-beat signal every 1 hour after its successful registration as shown by block
  • Signals in block 308 show the registration process of the CHF 302 instances NFi1 , NFi2, NFi3... NFin, in the NRF 300 as well as the NRF’s successful registration response and setting of the time interval (1 hour) for the CHF instances to send their respective heart-beat signal.
  • NFs or NF instances like SMF or PCF 304 will also register in the NRF 300 and send heart-beat signals, albeit such is not shown explicitly in Figures 3A-3E.
  • the NRF 300 receives a request for service discovery from SMF/PCF 304 for charging/policy services. Still unaware of the NFi2 instance failure, the NRF 300 responds to SMF/PCF 304 with the information about network functions that provide the charging/policy services. In this response 314, the NRF 300 also includes NFi2 as one of the resources that provides the requested services.
  • SMF/PCF 304 randomly selects the NFi2 instance from the list that NRF 300 provided. As NFi2 is unavailable, there is no response to the request 316 from SMF/PCF 304.
  • the request 316 from SMF/PCF 304 times out due to no response from NFi2 and SMF/PCF 304 must retry the request towards some other NF instance from the list that NRF 300 has provided.
  • the SMF/PCF 304 can time out after it sends a single request signal 316 without a response or it could resend signal 316 one or more additional times before the time out occurs.
  • steps 306-318 of the embodiment of Figures 3A- 3E and steps 206-218 of the Background Art of Figures 2A-2C are substantially the same.
  • the embodiment of Figures 3A-3E addresses the delay in detection of the failure of NFi2 by the NRF 200 starting with the signaling illustrated in block 320 which will now be described below.
  • the consumer NF node i.e., SMF or PCF 304 in this case
  • the manner in which the consumer NF node informs the NRF 300 of this can vary based on different embodiments.
  • the SMF/PCF 304 (service consuming NFs) performs an additional step 322 where it will, e.g., immediately after its request(s) 316 time out, inform the NRF 300 (e.g., via a new Representational State Transfer (REST) message) that the NF instance to which request 316 was sent and which was identified by the NRF 300 in the NFDiscovery response to the SMF/PCF is not available.
  • REST Representational State Transfer
  • the transmission of message 322 toward NRF 300 can be performed by one instances of the consumer NF, multiple instances of the consumer NF or all instances of the consumer NF (as shown in Figure 3B).
  • This feature of various embodiments enables the NRF to obtain an overall view of the provider network resources in the network. For example, within a given period of time, there could be hundreds of consumer NFs trying to get service from the provider NFs. The reason for a certain consumer NF not being able to get a service from a given provider NF could be numerous. For example, the failure cause could be a temporary network glitch or it could be a disaster that caused the provider NF to go down until repaired.
  • the SMF/PCF 304 (consumer NF node) will report the unavailability of the provider NF node instance as an additional payload in the existing heart-beat message that the consumer NF node sends to the NRF 300 at regular intervals, e.g., every hour. Assuming that the consumer NF node’s heart-beat signal is sent at a different time than the provider NF node’s heart-beat signal (i.e., the one which has become non- operational), then at some times the NRF 300 would learn more quickly about NFi2’s failure.
  • the consumer NFs can send information about the status of more than one provider NF in the heart-beat signal.
  • the consumer NFs can not only send information about provider NF failures, but also on successes.
  • the NRF 300 will respond to such signals by acknowledging them via signal 328.
  • the consumer NF node uses the approach to inform the NRF 300 via a separate (from the heart-beat) signal 322, then it will proceed to attempt to gain service from another CHF service instance, e.g., NFi3, via signal 330. If successful, NFi3 will send a successful acknowledgement via signal 332.
  • the consumer NF node uses the technique to inform the NRF 300 of NFi2’s failure via its regularly scheduled heart-beat signal, it can attempt to gain service from another CHF service instance, e.g., NFi3, via signal 330 before it informs the NRF 300 of NFi2’s failure depending upon when its next heart-beat signal 326 is scheduled to be transmitted.
  • another CHF service instance e.g., NFi3
  • NRF 300 can then take one (or more) of several different remedial actions.
  • NRF 300 based on the information received from different NFs, immediately changes the status of the reported provider NF/NF instance (i.e., NFi2 in this example) to SUSPENDED and considers that the NF/NF instance and its services can no longer be discovered by other NFs via the NFDiscovery service.
  • the NRF notifies NFs subscribed to receive notifications of changes of the NF Profile that the NF/NF instance status has been changed to SUSPENDED.
  • the NRF 300 can first check the identified NF/NF instance itself to see if it is operational. Thus, at step 336 NRF can, based on the information received from a different NF, request a status report from the NF that was reported as unavailable. The NRF 300 can analyze all consumer NF reports of a provider NF/NFs before taking a decision on the availability of the provider NF. If the NRF 300 receives a status update 338 from the NF/NF instance, it means that the network resource is OK and no further action is required.
  • the NRF 300 changes the status of the NF/NF instance to SUSPENDED and considers that the NF/NF instance and its services can no longer be discovered by other NFs via the NFDiscovery service as shown in block 340.
  • the NRF 300 notifies NFs subscribed to receiving notifications of changes of the NF Profile that the NF/NF instance status has been changed to SUSPENDED.
  • step 342 when the other NFs send a request to NRF 300 for NFDiscovery, the NRF 300 shall provide the correct information about the resources that are available. At the next heart-beat interval, all the available network resources shall provide the heart-beat information (indicated by the signals in block 346) and NRF 300 shall not wait for the heart-beat information from the suspended NF instance.
  • a method 400 for indicating failure of a provider network function node by a consumer network function node in a telecommunication network includes requesting 402, by the consumer network function (NF) node, a service from the provider NF node; failing 404 to receive, by the consumer NF node, a response from the provider NF node; and transmitting 406 a signal, by the consumer NF node, toward a network function repository function (NRF) node indicating a lack of response to its request from the provider NF node.
  • NRF network function repository function
  • a method 500 for detecting failure of a provider network function instance includes the steps of receiving 502, by a network function repository function (NRF) node from a consumer network function (NF) instance, a message indicating a lack of response by the provider NF instance to a request for service from the consumer network function (NF) instance; and taking 504, by the NRF node, remedial action associated with the message indicating a lack of response by the provider NF instance to a request for service.
  • NRF network function repository function
  • Embodiments described above can be implemented in one or more nodes (or servers).
  • An example of a communication node 600 is shown in Figure 6.
  • the communication node 600 (or other network node) includes a processor 602 for executing instructions and performing the functions described herein, e.g., the functions performed by the NRF 300, the CHF 302 and the SMF or PCF 304.
  • the communication node 600 also includes a primary memory 604, e.g., random access memory (RAM) memory, a secondary memory 606 which can be a non-volatile memory, and an interface 608 for communicating with other portions of a network or among various nodes/servers in support of charging.
  • RAM random access memory
  • Processor 602 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other communication node 600 components, such as memory 604 and/or 606, node 600 functionality in support of the various embodiments described herein.
  • processor 602 may execute instructions stored in memory 604 and/or 606.
  • Primary memory 604 and secondary memory 606 may comprise any form of volatile or non-volatile computer readable memory including, without limitation, persistent storage, solid state memory, remotely mounted memory, magnetic media, optical media, RAM, read-only memory (ROM), removable media, or any other suitable local or remote memory component.
  • Primary memory 604 and secondary memory 606 may store any suitable instructions, data or information, including software and encoded logic, utilized by node 600.
  • Primary memory 604 and secondary memory 606 may be used to store any calculations made by processor 602 and/or any data received via interface 608.
  • Communication node 600 also includes communication interface 608 which may be used in the wired or wireless communication of signaling and/or data.
  • interface 608 may perform any formatting, coding, or translating that may be needed to allow communication node 600 to send and receive data over a wired connection.
  • Interface 608 may also include a radio transmitter and/or receiver that may be coupled to or a part of the antenna.
  • the radio may receive digital data that is to be sent out to other network nodes or wireless devices via a wireless connection.
  • the radio may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters.
  • the radio signal may then be transmitted via an antenna to the appropriate recipient.
  • the non-limiting communication node also interchangeably called a node or telecommunication node
  • UE user equipment
  • UE user equipment
  • core network a core network.
  • the disclosed embodiments provide methods and devices for detecting network function failure. It should be understood that this description is not intended to limit the invention. On the contrary, the embodiments are intended to cover alternatives, modifications and equivalents, which are included in the spirit and scope of the invention.
  • the embodiments may take the form of an entirely hardware embodiment or an embodiment combining hardware and software aspects.
  • the embodiments e.g., the configurations and other logic associated with the charging process to include embodiments described herein, such as, the methods associated with Figure 4 or Figure 5, may take the form of a computer program product stored on a computer-readable storage medium having computer- readable instructions embodied in the medium.
  • Figure 7 depicts an electronic storage medium 700 on which computer program embodiments can be stored. Any suitable computer-readable medium may be utilized, including hard disks, CD-ROMs, digital versatile disc (DVD), optical storage devices, or magnetic storage devices such as floppy disk or magnetic tape.
  • Other non-limiting examples of computer-readable media include flash-type memories or other known memories.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Une instance de fonction de réseau (NF) de consommateur dans un réseau de télécommunication comprend un processeur et une interface qui sont configurés pour demander un service auprès d'une instance de NF de fournisseur et qui, s'ils ne parviennent pas à recevoir une réponse provenant de l'instance de NF de fournisseur, sont en outre configurés pour transmettre à un nœud de fonction de référentiel de fonction de réseau (NRF) un signal indiquant une absence de réponse de l'instance de NF de fournisseur à leur demande.
PCT/SE2020/050907 2020-09-25 2020-09-25 Procédés et systèmes de détection d'une ressource défectueuse d'un fournisseur de réseau dans un réseau soa/5g WO2022066078A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/SE2020/050907 WO2022066078A1 (fr) 2020-09-25 2020-09-25 Procédés et systèmes de détection d'une ressource défectueuse d'un fournisseur de réseau dans un réseau soa/5g

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SE2020/050907 WO2022066078A1 (fr) 2020-09-25 2020-09-25 Procédés et systèmes de détection d'une ressource défectueuse d'un fournisseur de réseau dans un réseau soa/5g

Publications (1)

Publication Number Publication Date
WO2022066078A1 true WO2022066078A1 (fr) 2022-03-31

Family

ID=80846843

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2020/050907 WO2022066078A1 (fr) 2020-09-25 2020-09-25 Procédés et systèmes de détection d'une ressource défectueuse d'un fournisseur de réseau dans un réseau soa/5g

Country Status (1)

Country Link
WO (1) WO2022066078A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4290817A1 (fr) * 2022-06-08 2023-12-13 T-Mobile USA, Inc. Gestion de capacité de découverte de smf sur la base d'une connectivité à des fonctions de réseau homologue

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019162862A1 (fr) * 2018-02-21 2019-08-29 Telefonaktiebolaget Lm Ericsson (Publ) Détection de producteur de service de fonction de réseau (nf) inactif
US20200136911A1 (en) * 2018-10-31 2020-04-30 Oracle International Corporation Methods, systems, and computer readable media for providing a service proxy function in a telecommunications network core using a service-based architecture
US20200153707A1 (en) * 2018-11-14 2020-05-14 Telefonaktiebolaget Lm Ericsson (Publ) NF SERVICE CONSUMER RESTART DETECTION USING DIRECT SIGNALING BETWEEN NFs

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019162862A1 (fr) * 2018-02-21 2019-08-29 Telefonaktiebolaget Lm Ericsson (Publ) Détection de producteur de service de fonction de réseau (nf) inactif
US20200136911A1 (en) * 2018-10-31 2020-04-30 Oracle International Corporation Methods, systems, and computer readable media for providing a service proxy function in a telecommunications network core using a service-based architecture
US20200153707A1 (en) * 2018-11-14 2020-05-14 Telefonaktiebolaget Lm Ericsson (Publ) NF SERVICE CONSUMER RESTART DETECTION USING DIRECT SIGNALING BETWEEN NFs

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 16)", 3GPP STANDARD; TECHNICAL SPECIFICATION; 3GPP TS 29.510, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. CT WG4, no. V16.4.0, 7 July 2020 (2020-07-07), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , pages 1 - 192, XP051924191 *
ERICSSON, NOKIA, NOKIA SHANGHAI BELL, HUAWEI: "Populating Recovery Information via Direct signalling from a Service Producer", 3GPP DRAFT; CP-201030, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. CT WG4, no. E-Meeting; 20200415 - 20200424, 18 June 2020 (2020-06-18), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051899545 *
HUAWEI, HISILICON, SK TELECOM: "Pseudo CR on TS 23.501 for awareness of NF status", 3GPP DRAFT; S2-175784_PCR_23501_AWARENESS OF NF STATUS, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG2, no. Sophia Antipolis, France; 20170821 - 20170825, 21 August 2017 (2017-08-21), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051325632 *
ZTE: "Report the Status of NF (NF Service) by Management System", 3GPP DRAFT; C4-175232 WAS 5080_29.891_DETECTION OF NF STATUS, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. CT WG4, no. Kochi, India; 20171023 - 20171027, 27 October 2017 (2017-10-27), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051351029 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4290817A1 (fr) * 2022-06-08 2023-12-13 T-Mobile USA, Inc. Gestion de capacité de découverte de smf sur la base d'une connectivité à des fonctions de réseau homologue

Similar Documents

Publication Publication Date Title
US10791492B2 (en) Method and apparatus for monitoring internet connection status in wireless communication system
CN112534776B (zh) 用于在网络环境中检测网络功能失败和重启的方法及装置
RU2517373C2 (ru) Способ переключения основного/резервного контроллеров узла на основе сети доставки контента и соответствующая сеть доставки контента
CN110662260B (zh) 信息处理方法及装置、网元及存储介质
US20220191665A1 (en) Event notification method, apparatus and storage medium
US20090271517A1 (en) Method and apparatus for wireless device reconnection handling
KR20170020449A (ko) 모바일 네트워크에서의 정체 제어를 위한 시스템, 방법 및 디바이스
WO2019134649A1 (fr) Procédé et appareil de mise en œuvre pour une migration de ressource de plan de commande, et entité fonctionnelle de réseau
CN109996216B (zh) 订阅请求处理方法、网络实体及能力开放平台
US9058262B2 (en) Sending network reject/error codes from a terminal adaptor to terminal equipment through an AT command interface
US11251981B2 (en) Communication method and apparatus
US11310855B2 (en) Methods and systems for managing bearer configuration of user equipment with EN-DC capability
US20150365854A1 (en) Addressing communication failure in multiple connection systems
US20180110092A1 (en) Method, device and system for resuming user equipment context
WO2022066078A1 (fr) Procédés et systèmes de détection d'une ressource défectueuse d'un fournisseur de réseau dans un réseau soa/5g
CN112788088A (zh) 多边缘云的网络通信控制方法及边缘运算系统
JP2005301436A (ja) クラスタシステムおよびクラスタシステムにおける障害回復方法
US20230199534A1 (en) Service producer health-check
US20230403208A1 (en) Apparatus and method for high availability of virtual network function
US10277484B2 (en) Self organizing network event reporting
EP3736696A1 (fr) Détection et réponse précoces de défaillances de session gx/rx
CN114629825A (zh) 算力感知网络的路径检测方法、装置及节点
WO2022083281A1 (fr) Procédé et système de transmission de message, dispositif électronique, et support de stockage
CN113950100B (zh) 数据传输方法、装置、电子设备和介质
WO2021018202A1 (fr) Procédé de détection de défaillance de notification de données de liaison descendante, amf, smf et support d'informations

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20955420

Country of ref document: EP

Kind code of ref document: A1