FORM 2
THE PATENTS ACT, 1970
(39 OF 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)
“METHOD AND SYSTEM FOR INTEGRATING NETWORK
REPOSITORY FUNCTION WITH A SECURITY EDGE
PROTECTION PROXY”
We, Jio Platforms Limited, an Indian National, of Office - 101, Saffron, Nr.
Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India.
The following specification particularly describes the invention and the manner in
which it is to be performed.
2
METHOD AND SYSTEM FOR INTEGRATING NETWORK
REPOSITORY FUNCTION WITH A SECURITY EDGE PROTECTION
PROXY
5 FIELD OF THE DISCLOSURE
[0001] Embodiments of the present disclosure generally relate to wireless
communication. More particularly, embodiments of the present disclosure relate to
integrating a network repository function (NRF) with a Security Edge Protection
10 Proxy (SEPP).
BACKGROUND
[0002] The following description of the related art is intended to provide
15 background information pertaining to the field of the disclosure. This section may
include certain aspects of the art that may be related to various features of the
present disclosure. However, it should be appreciated that this section is used only
to enhance the understanding of the reader with respect to the present disclosure,
and not as admissions of the prior art.
20
[0003] Wireless communication technology has rapidly evolved over the past few
decades, with each generation bringing significant improvements and
advancements. The first generation of wireless communication technology was
based on analog technology and offered only voice services. However, with the
25 advent of the second-generation (2G) technology, digital communication and data
services became possible, and text messaging was introduced. 3G technology
marked the introduction of high-speed internet access, mobile video calling, and
location-based services. The fourth-generation (4G) technology revolutionized
wireless communication with faster data speeds, better network coverage, and
30 improved security. Currently, the fifth-generation (5G) technology is being
deployed, promising even faster data speeds, low latency, and the ability to connect
3
multiple devices simultaneously. With each generation, wireless communication
technology has become more advanced, sophisticated, and capable of delivering
more services to its users.
5 [0004] To support In-roamer and Out-roamer traffic for 5G, the Security Edge
Protection Proxy (SEPP) Network Function (NF) needs to be deployed to ensure
secure communication between different Public Land Mobile Networks (PLMNs)
during roaming. RP NF may be not authorized to direct communicate with a
Network Repository Function (NRF) as the home network can be exposed
10 externally, so SEPP and NRF solves the problem by modifying the callback URI.
As part of this deployment, the Network Repository Function (NRF) will need
enhancements to handle roaming traffic effectively and also if the SEPP is not
registered at the NRF for communication between them, and NRF receives request
to send a notification to a different PLMN or operator. Here are the key
15 enhancements required for the NRF:
- For other network operator PLMNs request from NFs, currently NRF rejects
the requests as other network operator’s PLMNs are not served by any
of NRF instances.
20 - The NRF is not able to create Roaming Partner NRF address using the
MCC+MNC (and NID if applicable) information as defined in 3gpp
standard.
- Although SEPP can register and query from NRF, NRF is not able to
forward discovery request for other network operator’s PLMNs to SEPP.
25
[0005] The NRF should be able to resolve the above challenges while conforming
with 3gpp standards. In the current existing 3GPP standards, the problems of
runtime static connectivity, identification of traffic from SEPP using custom
header, handling of forward subscribe and non-subscribe messages and notification
30 routing through SEPP are not solved. Further, there does not exist a solution which
enables the NRF to integrate with SEPP via SCP. Also, there are no solutions
4
defined as to how the NRF should cater to requests from local NFs for In-roamers,
and from Roaming Partners for Out-roamers. If SEPP is only at two PLMN i.e.,
Delhi & Mumbai. If a user from third (Kolkata) PLMN out roams and
subscribe/unsubscribe/update/discovery requests are received from another
5 operator the present solutions will include third PLMN’s MCC & MNC only. So,
the problem remains unsolved on how to transfer the
subscribe/unsubscribe/update/discovery requests to third PLMN NRF by
appending multiple MCC & MNC.
10 [0006] Thus, there exists an imperative need in the art to develop methods and
systems for integrating Network Repository function (NRF) with a Security Edge
Protection Proxy (SEPP).
SUMMARY
15
[0007] This section is provided to introduce certain aspects of the present disclosure
in a simplified form that are further described below in the detailed description.
This summary is not intended to identify the key features or the scope of the claimed
subject matter.
20
[0008] An aspect of the present disclosure may relate to a method for processing a
traffic by a Network Repository Function (NRF) from a Network Function
Consumer (NF Consumer). The method comprises receiving, by a transceiver unit,
at a network repository function (NRF), the traffic from the NF Consumer. Further,
25 the method comprises identifying, by an identification unit, at the NRF, a plurality
of Internet Protocol (IP) and Ports combination associated with one or more
Security Edge Protection Proxy (SEPP). Each of the IP and Port combinations from
the plurality of IP and Port combinations is assigned a weight and a priority.
Furthermore, the method comprises selecting, by the identification unit, at the NRF,
30 an IP and Port combination from the plurality of IP and Port combinations
associated with the one or more SEPPs based on the assigned weight and priority.
5
[0009] Hereinafter, the method comprises transmitting, by the transceiver unit,
from the NRF, the traffic to the selected the IP and the Port combination.
5 [0010] In an exemplary aspect of the present disclosure, the traffic comprises a
plurality of NF discovery requests.
[0011] In an exemplary aspect of the present disclosure, the NF Consumer is
associated with a first network operator and sends a discovery request to a second
10 network operator.
[0012] In an exemplary aspect of the present disclosure, the selected IP and Port
combination is assigned the highest priority.
15 [0013] In an exemplary aspect of the present disclosure, the if a first IP and Port
combination and a second IP and Port combination from the plurality of IP and Port
combinations have the same priority, distributing the traffic between the first IP and
Port combination and the second IP and Port combination based on the weight
associated with each of the first IP and Port combination and the second IP and Port
20 combination.
[0014] In an exemplary aspect of the present disclosure, the method further
comprises selecting, by the identification unit, at the NRFs the next available lower
priority IP and Port combination, in an event one or more higher priority IP and
25 Port combinations are unavailable.
[0015] In an exemplary aspect of the present disclosure, the method further
comprises selecting, at the identification unit, at the NRF, the one or more higher
priority IP and Port combinations, in an event the one or more higher priority IP
30 and Port combinations are available when the traffic at the one or more higher
priority IP and Port combinations falls below a threshold.
6
[0016] In an exemplary aspect of the present disclosure, the NRF provides an
automated selection and a command-line based selection for selecting the traffic
between the plurality of IP and Port combinations.
5
[0017] In an exemplary aspect of the present disclosure, for the automated
switching, the method further comprises running, at a processing unit at the NRF,
a configurable timer, based on which the NRF selects an IP and Port combination.
10 [0018] In an exemplary aspect of the present disclosure, the method further
comprises transmitting, by the transceiver unit, at the NRF, an error code to the NF
consumer, if the plurality of IP and Port combinations is unavailable based on the
traffic.
15 [0019] In an exemplary aspect of the present disclosure, the method further
comprises triggering, by the transceiver unit at the NRF, an alarm if the plurality of
IP and Port combinations is not reachable.
[0020] Another aspect of the present disclosure may relate to a method for
20 processing subscribe notifications from a Network Repository Function (NRF) to a
Roaming Partner (RP) Network Function (NF). The method comprises checking,
by a verification unit, at the NRF, one or more subscribe conditions for a
subscription of the RP NF. Further, the method comprises generating, by a
processing unit, at the NRF, a status notification for the RP NF, based on the
25 checking of the one or more subscribe conditions. Furthermore, the method
comprises modifying, by the processing unit, at the NRF, the status notification by
adding a callback Uniform Resource Identifier (URI) to the status notification.
Hereinafter, the method comprises transmitting, by the transceiver unit, from the
NRF the modified status notification to the RP NF.
30
7
[0021] In an exemplary aspect of the present disclosure, modifying the status
notification by placing the callback URI comprises receiving, by a transceiver unit,
at the NRF, a status subscribe request from an RP NRF. The method further
comprises forwarding, by the transceiver unit, from the NRF, a subscribe response
5 to one or more Security Edge Protection Proxy (SEPPs). Furthermore, the method
comprises modifying, by a processing unit, at the SEPPs, a callback URI in the
subscribe response. Hereinafter, the method comprises transmitting, by a
transceiver unit, from the SEPP to the NRF, the modified subscribe response
comprising the callback URI. The method further comprises identifying, by the
10 processing unit, at the NRF, the callback URI from the modified subscribe response.
[0022] In an exemplary aspect of the present disclosure, the status notification is
generated at the NRF if the one or more subscribe conditions are met for an existing
subscription of RP NF stored at the NRF.
15
[0023] In an exemplary aspect of the present disclosure, the RP NF is registered at
the RP NRF.
[0024] In an exemplary aspect of the present disclosure, the processing unit, at the
20 one or more SEPPS, applies a topology hiding to the callback URI and one or more
discovered NF profiles included in the modified subscribe response.
[0025] Another aspect of the present disclosure may relate to a method for
managing one or more subscription requests at one or more Network Repository
25 Functions (NRFs). The method comprises receiving, by a transceiver unit, at a first
NRF from the one or more NRFs, the subscription request from one or more
Security Edge Protection Proxy (SEPPs). Further, the method comprises checking,
by a verification unit, at the first NRF, a Public Land Mobile Network Identifier
(PLMN ID) and a Network Identifier (NID) associated with the one or more
30 subscription requests. Furthermore, the method comprises identifying, by a
processing unit, at the first NRF, one of a positive status and a negative status based
8
on determining if the PLMN associated with the PLMN ID is served by the first
NRF. Hereinafter, the method comprises processing, by a processing unit, at the
first NRF, the one or more subscription requests based on the positive status.
Hereinafter, the method comprises forwarding, by the transceiver unit, from the first
5 NRF the subscription request to a second NRF from the one or more NRFs based
on the negative status.
[0026] In an exemplary aspect of the present disclosure, the method further
comprises generating, by the processing unit, at the first NRF, a response
10 comprising a subscription identifier (ID), if the one or more subscription requests
is received from a SEPP. The method further comprises forwarding, by the
transceiver unit, from the first NRF the generated response to the one or more
SEPPs.
15 [0027] In an exemplary aspect of the present disclosure, forwarding the
subscription request to the second NRF is based on identifying that the PLMN is
served by the second NRF.
[0028] In an exemplary aspect of the present disclosure, the PLMN ID comprises a
20 mobile country code (MCC) and a mobile network code (MNC).
[0029] In an exemplary aspect of the present disclosure, the subscription ID
comprises the MCC and the MNC.
25 [0030] In an exemplary aspect of the present disclosure, the method further
comprises transmitting, by the transceiver unit, from the first NRF, an error code to
the SEPP if the PLMN associated with the PLMN ID fails to be processed by the
first NRF and the second NRF.
30 [0031] In an exemplary aspect of the present disclosure, the method further
comprises receiving, by a transceiver unit, at the first NRF, a message from the
9
SEPP. The message comprises the subscription ID. Further, the method comprises
determining, by the processing unit, at the first NRF, one of a positive status and a
negative status, based on the MCC and MNC derived from the subscription ID.
Furthermore, the method comprises processing, by the processing unit, at the first
5 NRF, the message based on the positive status. Hereinafter, the method comprises
forwarding, by the transceiver unit, from the first NRF, the message to the second
NRF based on the negative status.
[0032] In an exemplary aspect of the present disclosure, the message is one of a
10 status unsubscribe message and a status update message.
[0033] In an exemplary aspect of the present disclosure, the first NRF removes the
MCC and MNC from the subscription ID if the message is processed at the first
NRF.
15
[0034] Another aspect of the present disclosure may relate to a system for
processing a traffic by a network Repository Function (NRF) from a Network
Function Consumer (NF Consumer). The system comprises a transceiver unit. The
transceiver unit is configured to receive, at a network repository function (NRF),
20 the traffic from the NF Consumer. The system comprises an identification unit. The
identification unit is configured to identify, at the NRF, a plurality of Internet
Protocol (IP) and Ports combination associated with one or more Security Edge
Protection Proxy (SEPP). Each of the IP and Port combinations from the plurality
of IP and Port combinations is assigned a weight and a priority. The identification
25 unit is further configured to select, at the NRF, an IP and Port combination from the
plurality of IP and Port combinations associated with the one or more SEPPs based
on the assigned weight and priority. Further, the transceiver unit is configured to
transmit, from the NRF, the traffic to the selected IP and the Port combination.
30 [0035] Yet another aspect of the present disclosure may relate to a system for
processing subscribe notifications from a Network Repository Function (NRF) to a
10
roaming partner (RP) Network Function (NF). The system comprises a verification
unit. The verification unit is configured to check at the NRF, one or more subscribe
conditions for a subscription of the RP NF. The system further comprises a
processing unit. The processing unit is configured to generate, at the NRF, a status
5 notification for the RP NF, based on the checking of the one or more subscribe
conditions. The processing unit is further configured to modify, at the NRF, the
status notification by placing a callback Uniform Resource Identifier (URI). The
transceiver unit is further configured to transmit, from the NRF the modified status
notification to the RP NF.
10
[0036] Yet another aspect of the present disclosure may relate to a system for
managing a subscription request at one or more Network Repository Functions
(NRFs). The system comprises a transceiver unit. The transceiver unit is configured
to receive, at a first NRF from the one or more NRFs, the subscription request from
15 one or more Security Edge Protection Proxy (SEPPs). The system further comprises
a verification unit. The verification unit is configured to check at the first NRF, a
Public Land Mobile Network Identifier (PLMN ID) and a Network Identifier (NID)
associated with the subscription request. The system further comprises a processing
unit. The processing unit is configured to identify, at the first NRF, one of a positive
20 status and a negative status based on determining if the PLMN associated with the
PLMN ID is served by the first NRF. The processing unit is further configured to
process, at the first NRF, the subscription request based on the positive status. The
transceiver unit is further configured to forward, from the first NRF the subscription
request to a second NRF from the one or more NRFs based on the negative status.
25
[0037] Yet another aspect of the present disclosure may relate to a non-transitory
computer readable storage medium storing instructions for processing a traffic by a
network Repository Function (NRF) from a Network Function Consumer (NF
Consumer), the instructions include executable code which, when executed by one
30 or more units of a system cause a transceiver unit to receive, at a network repository
function (NRF), the traffic from the NF Consumer. The instructions when executed
11
by the system further cause an identification unit to identify, at the NRF, a plurality
of Internet Protocol (IP) and Ports combination associated with one or more
Security Edge Protection Proxy (SEPP). Each of the IP Port from the plurality of IP
Ports is assigned a weight and a priority. The instructions when executed by the
5 system further cause the identification unit to select, at the NRF, an IP Port from
the plurality of IP Ports associated with the one or more SEPPs based on the
assigned weight and priority. The instructions when executed by the system further
cause the identification unit to transmit, from the NRF, the traffic to the selected
the IP and the Port.
10
[0038] Yet another aspect of the present disclosure may relate to a non-transitory
computer readable storage medium storing instructions for managing a subscription
request at one or more Network Repository Functions (NRFs), the instructions
include executable code which, when executed by one or more units of a system
15 cause a verification unit to check, at the NRF, one or more subscribe conditions for
a subscription of the RP NF. The instructions when executed by the system further
cause a processing unit to generate, at the NRF, a status notification for the RP NF,
based on the checking of the one or more subscribe conditions. The instructions
when executed by the system further cause the processing unit to modify, at the
20 NRF, the status notification by placing a callback Uniform Resource Identifier
(URI). The instructions when executed by the system further cause the transceiver
unit to transmit, from the NRF the modified status notification to the RP NF.
[0039] Yet another aspect of the present disclosure may relate to a non-transitory
25 computer readable storage medium storing instructions for managing a subscription
request at one or more Network Repository Functions (NRFs), the instructions
include executable code which, when executed by one or more units of a system
cause a transceiver unit to receive at a first NRF from the one or more NRFs, the
subscription request from one or more Security Edge Protection Proxy (SEPPs).
30 The instructions when executed by the system further cause a verification unit to
check, at the first NRF, a Public Land Mobile Network Identifier (PLMN ID) and
12
a Network Identifier (NID) associated with the subscription request. The
instructions when executed by the system further cause a processing unit to identify,
at the first NRF, one of a positive status and a negative status based on determining
if the PLMN associated with the PLMN ID is served by the first NRF. The
5 instructions when executed by the system further cause the processing unit to
process, at the first NRF, the subscription request based on the positive status. The
instructions when executed by the system further cause the transceiver unit to
forward, from the first NRF the subscription request to a second NRF from the one
or more NRFs based on the negative status.
10
OBJECTS OF THE INVENTION
[0040] Some of the objects of the present disclosure, which at least one
embodiment disclosed herein satisfies are listed herein below.
15
[0041] It is another object of the present disclosure to provide an ability to Network
Repository Function (NRF) to integrate with Security Edge Protection Proxy
(SEPP) via Service Communication Proxy (SCP).
20 [0042] It is yet another object of the present disclosure to provide an ability to
Network Repository Function (NRF) to cater to requests from Local NF for Inroamers.
[0043] Yet another object of the present disclosure to provide an ability to Network
25 Repository Function (NRF) to cater to Requests from Roaming Partners for Outroamers.
DESCRIPTION OF THE DRAWINGS
30 [0044] The accompanying drawings, which are incorporated herein, and constitute
a part of this disclosure, illustrate exemplary embodiments of the disclosed methods
13
and systems in which like reference numerals refer to the same parts throughout the
different drawings. Components in the drawings are not necessarily to scale,
emphasis instead being placed upon clearly illustrating the principles of the present
disclosure. Also, the embodiments shown in the figures are not to be construed as
5 limiting the disclosure, but the possible variants of the method and system
according to the disclosure are illustrated herein to highlight the advantages of the
disclosure. It will be appreciated by those skilled in the art that disclosure of such
drawings includes disclosure of electrical components or circuitry commonly used
to implement such components.
10
[0045] FIG. 1 illustrates an exemplary block diagram representation of 5th
generation core (5GC) network architecture.
[0046] FIG. 2 illustrates an exemplary block diagram of a computing device upon
15 which the features of the present disclosure may be implemented in accordance with
exemplary implementation of the present disclosure.
[0047] FIG. 3 illustrates an exemplary block diagram of a system for processing a
traffic by a Network Repository Function (NRF) from a Network Function
20 Consumer (NF Consumer), in accordance with exemplary implementations of the
present disclosure.
[0048] FIG. 4 illustrates an exemplary block diagram of a system for processing
subscribe notifications from a Network Repository Function (NRF) to a roaming
25 partner (RP) Network Function (NF), in accordance with exemplary
implementations of the present disclosure.
[0049] FIG. 5 illustrates an exemplary block diagram of a system for managing a
subscription request at one or more Network Repository Functions (NRFs), in
30 accordance with exemplary implementations of the present disclosure.
14
[0050] FIG. 6 illustrates a method flow diagram for processing a traffic by a
network Repository Function (NRF) from a Network Function Consumer (NF
Consumer), in accordance with exemplary implementations of the present
disclosure.
5
[0051] FIG. 7 illustrates a method flow diagram for processing subscribe
notifications from a Network Repository Function (NRF) to a roaming partner (RP)
Network Function (NF), in accordance with exemplary implementations of the
present disclosure.
10
[0052] FIG. 8 illustrates a method flow diagram for managing a subscription
request at one or more Network Repository Functions (NRFs), in accordance with
exemplary implementations of the present disclosure.
15 [0053] FIG. 9 illustrates an implementation of a call flow diagram for processing
subscribe notifications from a Network Repository Function (NRF) to a roaming
partner (RP) Network Function (NF), in accordance with exemplary
implementations of the present disclosure.
20 [0054] FIG. 10 illustrates another implementation of a call flow diagram managing
a subscription request at one or more Network Repository Functions (NRFs), in
accordance with exemplary implementations of the present disclosure.
[0055] FIG. 11 illustrates an implementation of a call flow diagram for managing
25 unsubscribe requests at one or more Network Repository Functions (NRFs), in
accordance with exemplary implementations of the present disclosure.
[0056] The foregoing shall be more apparent from the following more detailed
description of the disclosure.
30
15
DETAILED DESCRIPTION
[0057] In the following description, for the purposes of explanation, various
specific details are set forth in order to provide a thorough understanding of
5 embodiments of the present disclosure. It will be apparent, however, that
embodiments of the present disclosure may be practiced without these specific
details. Several features described hereafter may each be used independently of one
another or with any combination of other features. An individual feature may not
address any of the problems discussed above or might address only some of the
10 problems discussed above.
[0058] The ensuing description provides exemplary embodiments only, and is not
intended to limit the scope, applicability, or configuration of the disclosure. Rather,
the ensuing description of the exemplary embodiments will provide those skilled in
15 the art with an enabling description for implementing an exemplary embodiment.
It should be understood that various changes may be made in the function and
arrangement of elements without departing from the spirit and scope of the
disclosure as set forth.
20 [0059] Specific details are given in the following description to provide a thorough
understanding of the embodiments. However, it will be understood by one of
ordinary skill in the art that the embodiments may be practiced without these
specific details. For example, circuits, systems, processes, and other components
may be shown as components in block diagram form in order not to obscure the
25 embodiments in unnecessary detail.
[0060] Also, it is noted that individual embodiments may be described as a process
which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure
diagram, or a block diagram. Although a flowchart may describe the operations as
30 a sequential process, many of the operations may be performed in parallel or
concurrently. In addition, the order of the operations may be re-arranged. A process
16
is terminated when its operations are completed but could have additional steps not
included in a figure.
[0061] The word “exemplary” and/or “demonstrative” is used herein to mean
5 serving as an example, instance, or illustration. For the avoidance of doubt, the
subject matter disclosed herein is not limited by such examples. In addition, any
aspect or design described herein as “exemplary” and/or “demonstrative” is not
necessarily to be construed as preferred or advantageous over other aspects or
designs, nor is it meant to preclude equivalent exemplary structures and techniques
10 known to those of ordinary skill in the art. Furthermore, to the extent that the terms
“includes,” “has,” “contains,” and other similar words are used in either the detailed
description or the claims, such terms are intended to be inclusive in a manner similar
to the term “comprising” as an open transition word without precluding any
additional or other elements.
15
[0062] As used herein, a “processing unit” or “processor” or “operating processor”
includes one or more processors, wherein processor refers to any logic circuitry for
processing instructions. A processor may be a general-purpose processor, a special
purpose processor, a conventional processor, a digital signal processor, a plurality
20 of microprocessors, one or more microprocessors in association with a (Digital
Signal Processing) DSP core, a controller, a microcontroller, Application Specific
Integrated Circuits, Field Programmable Gate Array circuits, any other type of
integrated circuits, etc. The processor may perform signal coding data processing,
input/output processing, and/or any other functionality that enables the working of
25 the system according to the present disclosure. More specifically, the processor or
processing unit is a hardware processor.
[0063] As used herein, “a user equipment”, “a user device”, “a smart-user-device”,
“a smart-device”, “an electronic device”, “a mobile device”, “a handheld device”,
30 “a wireless communication device”, “a mobile communication device”, “a
communication device” may be any electrical, electronic and/or computing device
17
or equipment, capable of implementing the features of the present disclosure. The
user equipment/device may include, but is not limited to, a mobile phone, smart
phone, laptop, a general-purpose computer, desktop, personal digital assistant,
tablet computer, wearable device or any other computing device which is capable
5 of implementing the features of the present disclosure. Also, the user device may
contain at least one input means configured to receive an input from at least one of
a transceiver unit, a processing unit, a storage unit, a detection unit and any other
such unit(s) which are required to implement the features of the present disclosure.
10 [0064] As used herein, “storage unit” or “memory unit” refers to a machine or
computer-readable medium including any mechanism for storing information in a
form readable by a computer or similar machine. For example, a computer-readable
medium includes read-only memory (“ROM”), random access memory (“RAM”),
magnetic disk storage media, optical storage media, flash memory devices or other
15 types of machine-accessible storage media. The storage unit stores at least the data
that may be required by one or more units of the system to perform their respective
functions.
[0065] As used herein “interface” or “user interface” refers to a shared boundary
20 across which two or more separate components of a system exchange information
or data. The interface may also be referred to a set of rules or protocols that define
communication or interaction of one or more modules or one or more units with
each other, which also includes the methods, functions, or procedures that may be
called.
25
[0066] All modules, units, components used herein, unless explicitly excluded
herein, may be software modules or hardware processors, the processors being a
general-purpose processor, a special purpose processor, a conventional processor,
a digital signal processor (DSP), a plurality of microprocessors, one or more
30 microprocessors in association with a DSP core, a controller, a microcontroller,
18
Application Specific Integrated Circuits (ASIC), Field Programmable Gate Array
circuits (FPGA), any other type of integrated circuits, etc.
[0067] As used herein the transceiver unit include at least one receiver and at least
5 one transmitter configured respectively for receiving and transmitting data, signals,
information or a combination thereof between units/components within the system
and/or connected with the system.
[0068] As discussed in the background section, the current known solutions have
10 several shortcomings. The present disclosure aims to overcome the abovementioned and other existing problems in this field of technology by providing
method and system of processing a traffic by a network Repository Function (NRF)
from a Network Function Consumer (NF Consumer).
15 [0069] FIG. 1 illustrates an exemplary block diagram representation of 5th
generation core (5GC) network architecture, in accordance with exemplary
implementation of the present disclosure. As shown in FIG. 1, the 5GC network
architecture [100] includes a user equipment (UE) [102], a radio access network
(RAN) [104], an access and mobility management function (AMF) [106], a Session
20 Management Function (SMF) [108], a Service Communication Proxy (SCP) [110],
an Authentication Server Function (AUSF) [112], a Network Slice Specific
Authentication and Authorization Function (NSSAAF) [114], a Network Slice
Selection Function (NSSF) [116], a Network Exposure Function (NEF) [118], a
Network Repository Function (NRF) [120], a Policy Control Function (PCF) [122],
25 a Unified Data Management (UDM) [124], an application function (AF) [126], a
User Plane Function (UPF) [128], a data network (DN) [130], wherein all the
components are assumed to be connected to each other in a manner as obvious to
the person skilled in the art for implementing features of the present disclosure.
30 [0070] The Radio Access Network (RAN) [104] is the part of a mobile
telecommunications system that connects user equipment (UE) [102] to the core
19
network (CN) and provides access to different types of networks (e.g., 5G network).
It consists of radio base stations and the radio access technologies that enable
wireless communication.
5 [0071] The Access and Mobility Management Function (AMF) [106] is a 5G core
network function responsible for managing access and mobility aspects, such as UE
registration, connection, and reachability. It also handles mobility management
procedures like handovers and paging.
10 [0072] The Session Management Function (SMF) [108] is a 5G core network
function responsible for managing session-related aspects, such as establishing,
modifying, and releasing sessions. It coordinates with the User Plane Function
(UPF) for data forwarding and handles IP address allocation and QoS enforcement.
15 [0073] The Service Communication Proxy (SCP) [110] is a network function in the
5G core network that facilitates communication between other network functions
by providing a secure and efficient messaging service. It acts as a mediator for
service-based interfaces.
20 [0074] The Authentication Server Function (AUSF) [112] is a network function in
the 5G core responsible for authenticating UEs during registration and providing
security services. It generates and verifies authentication vectors and tokens.
[0075] The Network Slice Specific Authentication and Authorization Function
25 (NSSAAF) [114] is a network function that provides authentication and
authorization services specific to network slices. It ensures that UEs can access only
the slices for which they are authorized.
[0076] The Network Slice Selection Function (NSSF) [116] is a network function
30 responsible for selecting the appropriate network slice for a UE based on factors
such as subscription, requested services, and network policies.
20
[0077] The Network Exposure Function (NEF) [118] is a network function that
exposes capabilities and services of the 5G network to external applications,
enabling integration with third-party services and applications.
5
[0078] The Network Repository Function (NRF) [120] is a network function that
acts as a central repository for information about available network functions and
services. It facilitates the discovery and dynamic registration of network functions.
10 [0079] The Policy Control Function (PCF) [122] is a network function responsible
for policy control decisions, such as QoS, charging, and access control, based on
subscriber information and network policies.
[0080] The Unified Data Management (UDM) [124] is a network function that
15 centralizes the management of subscriber data, including authentication,
authorization, and subscription information.
[0081] The Application Function (AF) [126] is a network function that represents
external applications interfacing with the 5G core network to access network
20 capabilities and services.
[0082] The User Plane Function (UPF) [128] is a network function responsible for
handling user data traffic, including packet routing, forwarding, and QoS
enforcement.
25
[0083] The Data Network (DN) [130] refers to a network that provides data
services to user equipment (UE) in a telecommunications system. The data services
may include but are not limited to Internet services, private data network related
services.
30
21
[0084] FIG. 2 illustrates an exemplary block diagram of a computing device [200]
upon which the features of the present disclosure may be implemented in
accordance with exemplary implementation of the present disclosure. In an
implementation, the computing device [200] may also implement a method for
5 processing a traffic by a network Repository Function (NRF) from a Network
Function Consumer (NF Consumer) utilising the system. In another
implementation, the computing device [200] itself implements the method
processing a traffic by a network Repository Function (NRF) from a NF Consumer,
using one or more units configured within the computing device [200], wherein said
10 one or more units are capable of implementing the features as disclosed in the
present disclosure.
[0085] The computing device [200] may include a bus [202] or other
communication mechanism for communicating information, and a hardware
15 processor [204] coupled with bus [202] for processing information. The hardware
processor [204] may be, for example, a general-purpose microprocessor. The
computing device [200] may also include a main memory [206], such as a randomaccess memory (RAM), or other dynamic storage device, coupled to the bus [202]
for storing information and instructions to be executed by the processor [204]. The
20 main memory [206] also may be used for storing temporary variables or other
intermediate information during execution of the instructions to be executed by the
processor [204]. Such instructions, when stored in non-transitory storage media
accessible to the processor [204], render the computing device [200] into a specialpurpose machine that is customized to perform the operations specified in the
25 instructions. The computing device [200] further includes a read only memory
(ROM) [208] or other static storage device coupled to the bus [202] for storing static
information and instructions for the processor [204].
[0086] A storage device [210], such as a magnetic disk, optical disk, or solid-state
30 drive is provided and coupled to the bus [202] for storing information and
instructions. The computing device [200] may be coupled via the bus [202] to a
22
display [212], such as a cathode ray tube (CRT), Liquid crystal Display (LCD),
Light Emitting Diode (LED) display, Organic LED (OLED) display, etc. for
displaying information to a computer user. An input device [214], including
alphanumeric and other keys, touch screen input means, etc. may be coupled to the
5 bus [202] for communicating information and command selections to the processor
[204]. Another type of user input device may be a cursor controller [216], such as
a mouse, a trackball, or cursor direction keys, for communicating direction
information and command selections to the processor [204], and for controlling
cursor movement on the display [212]. This input device typically has two degrees
10 of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allow
the device to specify positions in a plane.
[0087] The computing device [200] may implement the techniques described
herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware
15 and/or program logic which in combination with the computing device [200] causes
or programs the computing device [200] to be a special-purpose machine.
According to one implementation, the techniques herein are performed by the
computing device [200] in response to the processor [204] executing one or more
sequences of one or more instructions contained in the main memory [206]. Such
20 instructions may be read into the main memory [206] from another storage medium,
such as the storage device [210]. Execution of the sequences of instructions
contained in the main memory [206] causes the processor [204] to perform the
process steps described herein. In alternative implementations of the present
disclosure, hard-wired circuitry may be used in place of or in combination with
25 software instructions.
[0088] The computing device [200] also may include a communication interface
[218] coupled to the bus [202]. The communication interface [218] provides a twoway data communication coupling to a network link [220] that is connected to a
30 local network [222]. For example, the communication interface [218] may be an
integrated services digital network (ISDN) card, cable modem, satellite modem, or
23
a modem to provide a data communication connection to a corresponding type of
telephone line. As another example, the communication interface [218] may be a
local area network (LAN) card to provide a data communication connection to a
compatible LAN. Wireless links may also be implemented. In any such
5 implementation, the communication interface [218] sends and receives electrical,
electromagnetic or optical signals that carry digital data streams representing
various types of information.
[0089] The computing device [200] can send messages and receive data, including
10 program code, through the network(s), the network link [220] and the
communication interface [218]. In the Internet example, a server [230] might
transmit a requested code for an application program through the Internet [228], the
ISP [226], the local network [222], the host [224] and the communication interface
[218]. The received code may be executed by the processor [204] as it is received,
15 and/or stored in the storage device [210], or other non-volatile storage for later
execution.
[0090] The present disclosure is implemented by a system [300] (as shown in FIG.
3), a system [400] (as shown in FIG. 4) and a system [500] (as shown in FIG. 5). In
20 an implementation, the system [300], the system [400] and the system [500] may
include the computing device [200] (as shown in FIG. 2). It is further noted that the
computing device [200] is able to perform the steps of a method [600] (as shown in
FIG. 6), a method [700] (as shown in FIG. 7) and a method [800] (as shown in FIG.
8).
25
[0091] Referring to FIG. 3, an exemplary block diagram of a system [300] for
processing a traffic by a Network Repository Function (NRF) from a NF Consumer
is shown, in accordance with the exemplary implementations of the present
disclosure. The system [300] comprises at least one transceiver unit [302], at least
30 one identification unit [304], at least one processing unit [306] and at least one
detection unit [308]. Also, all of the components/ units of the system [300] are
24
assumed to be connected to each other unless otherwise indicated below. As shown
in the FIG. 3 all units shown within the system should also be assumed to be
connected to each other. Also, in FIG. 3 only a few units are shown, however, the
system [300] may comprise multiple such units or the system [300] may comprise
5 any such numbers of said units, as required to implement the features of the present
disclosure. Further, in an implementation, the system [300] may be present in a user
device to implement the features of the present disclosure. In an implementation,
the system [300] may reside in a server or a network entity. In yet another
implementation, the system [300] may reside partly in the server/ network entity.
10
[0092] The system [300] is configured for processing a traffic by a Network
Repository Function (NRF) from a NF Consumer, with the help of the
interconnection between the components/units of the system [300].
15 [0093] The NF Consumer is associated with a first network operator and sends a
discovery request to a second network operator.
[0094] A Public Land Mobile Network (PLMN) is a network established and
operated by an administration for the specific purpose of providing land mobile
20 communication services to the public. It provides communication possibilities for
mobile users. For communications between mobile and fixed users, interworking
with a fixed network is necessary. A PLMN may provide service in one, or a
combination, of frequency bands. As a rule, a PLMN is limited by the borders of a
country. Depending on national regulations there may be more than one PLMN per
25 country. A relationship exists between each subscriber and his/her home PLMN
(HPLMN). If communications are handled over another PLMN, this PLMN is
referred to as the visited PLMN (VPLMN). Each PLMN is assigned an identifier
(ID). The PLMN ID consists of two parts: a mobile country code (MCC) and a
mobile network code (MNC).
30
25
[0095] The transceiver unit [302] is configured to receive, at a Network Repository
Function (NRF), the traffic from the NF Consumer. The traffic comprises a plurality
of NF discovery requests. When the NRF receives the discovery requests from NF
Consumer instances, the NRF provides the information of the available NF
5 instances fulfilling certain criteria (e.g., supporting a given service). The NF Service
Consumer shall send an HTTP GET request to a resource Unifor Resource
Identifier (URI). The URI is determined by the NF Consumer instance. The variable
{nfInstanceID} represents an identifier, provided by the NF Consumer, that shall
be globally unique inside the PLMN of the NRF where the NF Consumer is being
10 registered. The input filter criteria for the discovery request shall be included in
query parameters. On success, "200 OK" shall be returned by the NRF. The
response body shall contain a validity period, during which the search result can be
cached by the NF Service Consumer, and an array of NF Profile objects, that satisfy
the search filter criteria (e.g., all NF Instances offering a certain NF Service name).
15 The NF profile consists of general parameters of the NF Instance, and also the
parameters of the different services exposed by the NF Instance.
[0096] The identification unit [304] is configured to identify, at the NRF, a plurality
of Internet Protocol (IP) and Ports combination associated with one or more
20 Security Edge Protection Proxy (SEPPs). The SEPP is a non-transparent proxy and
supports message filtering and policing on inter-PLMN control plane interfaces.
The SEPP protects the connection between NF Consumers and NF Producers from
a security perspective. The SEPP also performs topology hiding. The SEPP applies
the above functionality to every control plane message in inter-PLMN signalling,
25 acting as a service relay between the actual NF Producer and the actual NF
Consumer. For both NF Producer and NF Consumer, the result of the service
relaying is equivalent to a direct service interaction. The one or more SEPPs are
configured to maintain any correlation, routing to a peer SEPP or a peer NF,
blacklisting or whitelisting a public land mobile network (PLMN), setting a rate
30 limit, and the like. Further, each of the IP and Port combination from the plurality
of IP and Port combinations is assigned a weight and a priority. The priority
26
determines as to which IP and Port combination will receive the traffic first. For
example, for entries with higher priority (Priority = 1 is highest and 100 is lowest)
should receive traffic first. The weight determines the distribution of traffic at that
combination. For example, when multiple SEPP IP:Port entries have same priority,
5 traffic should be load balanced as per provided weight i.e. if two entries are present
with same priority but with weight 50 and 40, messages should be split in ration of
50:40 between the two targets. An exemplary table listing sample entries for the
SEPP IP:Port entries is shown below:
SEPP IP and Port
combination
Weight (0 – 100) Priority (1-100)
IP1:Port1 50 1
IP2:Port1 40 1
IP1:Port2 20 2
IP2:Port2 40 3
10
[0097] Based on the above, the identification unit [304] is configured to select, at
the NRF, an IP and Port combination from the plurality of IP and Port combinations
associated with the one or more SEPPs based on the assigned weight and priority.
The traffic may be received based on the priority where 1 corresponds to highest
15 level of priority and 100 corresponds to lowest level of priority. For instance, based
on the above table, the IP1:Port1 may receive the traffic before other IP and Port
combinations. For traffic calculation purpose, target with “0” weight should be
considered unavailable and if only single target with “0” weight is available, traffic
should be catered by lower priority targets.
20
[0098] The transceiver unit [302] is further configured to transmit, from the NRF,
the traffic to the selected IP and the Port combination. As described earlier, it is
understood that the selected IP and Port combination will have the highest assigned
priority.
25
27
[0099] Further, the identification unit [304], at the NRF selects the next available
lower priority IP Port, in an event one or more higher priority IP Ports are
unavailable. The identification unit [304], at the NRF, selects the next available
lower priority IP and Port combination, in an event one or more higher priority IP
5 and Port combinations are unavailable. For example, when all of higher priority
targets become unavailable, targets provided with lower priority based on assigned
weights should cater to the traffic.
[0100] The identification unit [304], at the NRF, selects the one or more higher
10 priority IP and Port combinations, in an event the one or more higher priority IP
and Port combinations are available when the traffic at the one or more higher
priority IP and Port combinations falls below a threshold. The NRF retries to send
the traffic to higher priority IP and Port combinations once combinations catering
to existing traffic goes down.
15
[0101] Further, the transceiver unit [302] at the NRF triggers an alarm if the
plurality of IP and Port combinations is not reachable. The NRF keeps ping-pong
communication with all the instances of the SEPP. When a response is not received
from an instance and the request timed out, the instance is said to be not reachable.
20 In a condition when the plurality of SEPP IP:Ports are overloaded with traffic and
they are not able to take on any more traffic, they do not respond and become
unreachable. When the plurality of SEPP IP:Ports are not reachable and the NRF is
not able to forward the traffic, the transceiver unit [302] at the NRF transmits an
error code to the NF consumer. Further, a detection unit [308] at the NRF keeps
25 counters for successful and unsuccessful discovery requests and response based on
the availability and unavailability of the SEPP IP:Port combinations.
[0102] The NRF provides an automated selection and a command-line based
selection for switching the traffic between the plurality of IP and Port combinations.
30 For the automated selection, a processing unit [306] at the NRF runs a configurable
timer, based on which the NRF tries to create connection towards a primary IP and
28
Port combination based on the assigned priority. If the primary IP and Port
combination is available and up, the NRF sends the traffic to this combination. In
case the primary IP and Port combination is not available, the NRF should again
retry to establish connection based on the configurable timer. For the command5 line based selection, the NRF should provide a command for switching the traffic
on a selected IP and Port combination.
[0103] Referring to FIG. 4 an exemplary block diagram of a system for processing
subscribe notifications from a Network Repository Function (NRF) to a Roaming
10 Partner (RP) Network Function (NF), in accordance with exemplary
implementations of the present disclosure is shown. The system [400] comprises at
least one verification unit [402], at least one processing unit [404] and at least one
transceiver unit [406]. Further, the system [400] is in communication with a
Security Edge Protection Proxy (SEPP) [408] which comprises a processing unit
15 [410]. Also, all of the components/ units of the system [400] are assumed to be
connected to each other unless otherwise indicated below. As shown in the FIG. 4
all units shown within the system should also be assumed to be connected to each
other. Also, in FIG. 4 only a few units are shown, however, the system [400] may
comprise multiple such units or the system [400] may comprise any such numbers
20 of said units, as required to implement the features of the present disclosure. In an
implementation, the system [400] may reside in a server or a network entity. In yet
another implementation, the system [400] may reside partly in the server/ network
entity.
25 [0104] The verification unit [402] is configured to check at the NRF, one or more
subscribe conditions for a subscription of the RP NF. The RP NF needs to be
registered at the RP NRF to avail services and notifications. The Network Function
Consumers (NF Consumers) can subscribe to notifications from the NRF related to
NF instances in the same PLMN or in a different PLMN. The NF Consumers have
30 to create a subscription so they can be notified when NF Instances of a given set,
following certain filter criteria are registered/deregistered in the NRF or when their
29
profile is modified. The NF also has to a create a subscription to a specific NF
Instance so it can request to be notified when the profile of such NF Instance is
modified or when the NF Instance is deregistered from NRF. The subscription
request body shall include the data indicating the type of notifications that the NF
5 Consumer is interested in receiving; it also contains a callback URI, where the NF
Service Consumer shall be prepared to receive the actual notification from the NRF
and it may contain a validity time, suggested by the NF Consumer, representing the
time span during which the subscription is desired to be kept active. The request
body contains the input parameters for the subscription. These parameters include,
10 e.g.: Target NF type, Target Service Name, Callback URI of the Requester NF,
PLMN ID, etc. The subscription to notifications on NF Instances in a different
PLMN is done by creating a resource under the collection resource "subscriptions",
in the NRF of the Home PLMN. The PLMN ID shall be included when the NF
consumer in one PLMN requests a service access authorization for an NF producer
15 from a different PLMN. When present, this parameter shall contain the PLMN ID
of the target PLMN (i.e., PLMN ID of the NF producer). The NRF in the present
disclosure is in a Home or Serving PLMN and the RP NF is in a visiting PLMN.
Therefore, the NF instances registered with the NRF are in Home PLMN and the
RP NF requesting services is in a different PLMN. Based on the subscription
20 request, the NRF in the Home PLMN returns a ‘subscriptionID’ identifying the
created subscription. Further, the one or more subscribe conditions may be defined
by a number of parameters. The ‘NfInstanceIdListCond’ parameter which describes
subscription to a list of NF instances. The ‘NfTypeCond’ parameter which
describes subscription to a set of NF instances, identified by their NF type. The
25 parameter ‘ServiceNameCond’ which describes subscription to a set of NF
instances that offer a certain service name. These are some examples for the
parameters which describe the one or more conditions which are checked by the
NRF before responding back with the status notification. In an implementation, the
NRF may check the "reqNfType" and "reqNfFqdn" input attributes in the
30 subscription request body. The ‘reqNfType’ contains the NF type of the NF
Consumer, i.e. RP NF, that is requesting the creation of the subscription. The NRF
30
shall use it for authorizing the request. The ‘reqNfFqdn’ contains the FQDN of the
NF Consumer, i.e. RP NF, that is requesting the creation of the subscription. The
NRF shall use it for authorizing the request.
5 [0105] If the one or more subscribe conditions are met, the processing unit [404] is
configured to generate, at the NRF, a status notification for the RP NF. The status
notification is generated at the NRF if the one or more subscribe conditions are met
for an existing subscription of RP NF. The ‘NFStatusNotify’ service operation is
used by the NRF to generate the status notification for RP NF. The
10 ‘NFStatusNotify’ allows the NRF to notify subscribed NF Instances (i.e. RP NF) of
changes on the status of NF Instances. This service operation can be invoked
directly between the NRF and an NF Instance in a different PLMN (without
involvement of the NRF in that PLMN).
15 [0106] After the status notification is generated, the processing unit [404] is
configured to modify, at the NRF, the status notification by placing a callback
Uniform Resource Identifier (URI). To modify the status notification by placing the
callback URI, the transceiver unit [406] is configured to receive a status subscribe
request from an RP NRF at the NRF, where the RP NRF is in a different PLMN.
20 The service operation ‘NFStatusSubscribe’ allows an NF to subscribe to changes
on the status of NF Instances registered in NRF. It also allows an SCP Instance to
subscribe to changes on the status of other SCP Instances registered in NRF. This
service operation can be invoked by an NF Instance in a different PLMN (via the
local NRF in that PLMN). It cannot be invoked by an SCP instance in a different
25 PLMN. Further, the transceiver unit [406] is configured to transmit, from the NRF,
a subscribe response to a Security Edge Protection Proxy (SEPP) [408]. The SEPP
[408] is in the Home or Serving PLMN. Furthermore, the processing unit [404], is
configured to modify, at the SEPP, the callback URI in the subscribe response. The
Callback URI should be modified so that notification messages from the NRF are
30 sent towards the SEPP rather than directly towards RP NF. The transceiver unit
[406] is further configured to receive, from the SEPP [408] at the NRF, the modified
31
subscribe response containing the modified Callback URI. The processing unit
[404] is further configured to identify, at the NRF, the Callback URI from the
modified subscribe response. The method focuses on using the same modified
Callback URI for subscription response. Thereafter, the transceiver unit [406]
5 transmits, from the NRF the modified status notification to the RP NF. Further, it
is to be noted that the RP NF is registered in the RP NRF.
[0107] The processing unit [410], at the one or more SEPPs [408], also applies a
topology hiding to the Callback URI and one or more discovered NF profiles
10 included in the modified subscribe response. The topology hiding refers to a
technique to conceal network topology from unauthorized users to enhance security
of the network. In this way, the network functions outside the trust domain of the
home PLMN have no view of the URI (Uniform Resource Identifiers).
15 [0108] FIG. 5 illustrates an exemplary block diagram of a system for managing a
subscription request at one or more Network Repository Functions (NRFs), in
accordance with exemplary implementations of the present disclosure. The system
[500] comprises at least one transceiver unit [502], at least verification unit [504]
and at least one processing unit [506]. Also, all of the components/ units of the
20 system [500] are assumed to be connected to each other unless otherwise indicated
below. As shown in the FIG. 5, all units shown within the system should also be
assumed to be connected to each other. Also, in FIG. 5 only a few units are shown,
however, the system [500] may comprise multiple such units or the system [500]
may comprise any such numbers of said units, as required to implement the features
25 of the present disclosure. Further, in an implementation, the system [500] may be
present in a user device to implement the features of the present disclosure. In an
implementation, the system [500] may reside in a server or a network entity. In yet
another implementation, the system [500] may reside partly in the server/ network
entity.
30
32
[0109] The transceiver unit [502], is configured to receive, at a first NRF from the
one or more NRFs, the subscription request from one or more Security Edge
Protection Proxy (SEPPs). The subscription request body shall include the data
indicating the type of notifications that the one or more NRFs are interested in
5 receiving; it also contains a callback URI, where the one or more NRFs shall be
prepared to receive the actual notification from the first NRF and it may contain a
validity time, suggested by the one or more NRFs, representing the time span during
which the subscription is desired to be kept active. The subscription request may
also include additional parameters indicating the list of attributes in the NF Profiles
10 to be monitored (or to be excluded from monitoring), in order to determine whether
a notification from the first NRF should be sent, or not, when any of those attributes
is changed in the profiles. The one or more NRFs may request the creation of a
subscription to a specific NF Instance, or to a set of NF Instances, where the set is
determined according to different criteria specified in the request body, in the
15 "subscrCond" attribute of the "SubscriptionData" object type included in the
subscription request. The subscription request shall include a PLMN ID when
subscribing to NF services in a different PLMN. When included, this parameter
shall contain the PLMN ID(s) of the requester NF, i.e. the one or more NRFs.
20 [0110] The verification unit [504] is configured to check at the first NRF, a Public
Land Mobile Network Identifier (PLMN ID) and a Network Identifier (NID)
associated with the subscription request. The PLMN ID comprises the mobile
country code (MCC) and the mobile network code (MNC). The NID attribute
contains the target NID that, together with the PLMN ID attribute, identifies the
25 Stand-alone Non-Public Network (SNPN) of the NF Instance(s) whose status is
requested to be monitored.
[0111] The processing unit [506] is configured to identify, at the first NRF, one of
a positive status and a negative status based on determining if the PLMN associated
30 with the PLMN ID is served by the first NRF. An NRF can be configured with
multiple PLMN IDs and shall support registering, updating and deregistering the
33
profile of Network Function (NF) Instances from any of these PLMN IDs. The
positive status refers to determining that the PLMN associated with the PLMN ID
is configured with/served by the first NRF. The negative status refers to determining
that the PLMN associated with the PLMN ID is not configured with /not served by
5 the first NRF.
[0112] The processing unit [506] is further configured to process, at the first NRF,
the subscription request based on the positive status. Once, the processing unit [506]
has identified that the first NRF is configured to serve the PLMN associated with
10 the PLMN ID, the first NRF processes the subscription request. The processing unit
[506] is further configured to generate, at the first NRF, a response comprising a
subscription ID. The subscription ID comprises the MCC and the MNC. Further,
the transceiver unit [502] is configured to forward, from the first NRF the generated
response to the one or more SEPPs.
15
[0113] The transceiver unit [502] is further configured to forward, from the first
NRF the subscription request to a second NRF from the one or more NRFs, based
on the negative status. The subscription request is forwarded to the second NRF
based on identifying that the PLMN associated with the PLMN ID is served by the
20 second NRF.
[0114] In an exemplary implementation of the present disclosure, the transceiver
unit [502], is configured to receive, at the first NRF, a message from the one or
more SEPPs, wherein the message comprises the subscription ID. Thereafter, the
25 processing unit [506] determines, at the first NRF, one of a positive status and a
negative status, based on the MCC and MNC derived from the subscription ID.
Further, the message is one of a status unsubscribe message and a status update
message.
30 [0115] The processing unit [506] is configured to determine, at the first NRF, one
of a positive status and a negative status, based on the MCC and MNC derived from
34
the subscription ID. The processing unit [506] then processes the message at the
first NRF, based on the positive status. The positive status is determined when the
MCC and MNC combination indicates the PLMN ID associated with the first NRF.
5 [0116] The transceiver unit forwards, from the first NRF, the message to the second
NRF based on the negative status. The negative status is determined when the MCC
and MNC combination indicates PLMN ID associated with the second NRF.
[0117] Further, the transceiver unit [502], transmits from the first NRF, an error
10 code to the one or more SEPPs if the PLMN associated with the PLMN ID fails to
be processed at the first NRF and the second NRF. In such a case, the NRF keeps
counters for successful and unsuccessful NFStatusUnSubscribe and Update
NFStatusSubscribe request/response for RP PLMN.
15 [0118] In an exemplary implementation of the present disclosure, following two
scenarios are described below. The first scenario relates to a case when the NRF
receives an unsubscribe/update subscribe message directly from a SEPP. In this
case MCC+MNC should be appended already and the NRF (first NRF) should
make decision to either process locally or forward to other NRF (Second NRF)
20 based on MCC/MNC derived from SubscriptionID. In case, MCC/MNC
combination indicates local NRF (first NRF) only, NRF should remove the
MCC/MNC and lookup for Subscription ID. In case MCC/MNC is of another NRF
(second NRF), message should be forwarded accordingly. The second scenario
describes when the NRF (first NRF) indirectly receives UnSubscribe/ Update
25 Subscribe message from a SEPP. In this case, MCC+MNC may or may not be
present as part of SubscriptionID at target NRF (first NRF). In case, MCC/MNC
combination indicates local NRF (first NRF) only, NRF should remove the
MCC/MNC and lookup for Subscription ID. In case MCC/MNC is not present,
NRF should assume that message is for local NRF (first NRF) only and should
30 process accordingly. In case MCC/MNC is of another NRF (second NRF), message
35
should be forwarded accordingly. Further, it is to be noted that NRF is able to check
for SubscriptionID both with/without SubscriptionID.
[0119] Referring to FIG. 6, an exemplary method flow diagram [600] for
5 processing a traffic by a network Repository Function (NRF) from a NF Consumer,
in accordance with exemplary implementations of the present disclosure is shown.
In an implementation the method [600] is performed by the system [300]. Further,
in an implementation, the system [300] may be present in a server device to
implement the features of the present disclosure. Also, as shown in FIG. 6, the
10 method [600] starts at step [602].
[0120] At step [604], the method comprises receiving, by a transceiver unit [302],
at a network repository function (NRF), the traffic from the NF Consumer. The
traffic comprises a plurality of NF discovery requests. The Nnrf_NFDiscovery
15 service allows a NF Instance (or NF Consumer) to discover other NF Instances with
the potential services they offer, by querying the NRF. The NF Consumer is
associated with a first network operator and sends a discovery request to a second
network operator.
20 [0121] At step [606], the method comprises identifying, by an identification unit
[304], at the NRF, a plurality of Internet Protocol (IP) and Ports combination
associated with one or more Security Edge Protection Proxy (SEPP). The SEPP is
a non-transparent proxy and supports message filtering and policing on inter-PLMN
control plane interfaces. The SEPP protects the connection between NF Consumers
25 and NF Producers from a security perspective. The SEPP also performs topology
hiding. The SEPP applies the above functionality to every control plane message in
inter-PLMN signalling, acting as a service relay between the actual NF Producer
and the actual NF Consumer. For both NF Producer and NF Consumer, the result
of the service relaying is equivalent to a direct service interaction. The one or more
30 SEPPs are configured to maintain any correlation, routing to a peer SEPP or a peer
NF, blacklisting or whitelisting a public land mobile network (PLMN), setting a
36
rate limit, and the like. Further, each of the IP and Port combination from the
plurality of IP and Port combinations is assigned a weight and a priority. The
priority determines as to which IP and Port combination will receive the traffic first.
For example, for entries with higher priority (Priority = 1 is highest and 100 is
5 lowest) should receive traffic first. The weight determines the distribution of traffic
at that combination. For example, when multiple SEPP IP:Port entries have same
priority, traffic should be load balanced as per provided weight i.e. if two entries
are present with same priority but with weight 50 and 40, messages should be split
in ration of 50:40 between the two targets. An exemplary table listing sample entries
10 for the SEPP IP:Port entries is shown below:
SEPP IP and Port
combination
Weight (0 – 100) Priority (1-100)
IP1:Port1 50 1
IP2:Port1 40 2
IP1:Port2 20 3
IP2:Port2 40 4
[0122] Next, at Step [608], the identification unit [304] is configured to select, at
the NRF, an IP and Port combination from the plurality of IP and Port combinations
15 associated with the one or more SEPPs based on the assigned weight and priority.
The traffic may be received based on the priority where 1 corresponds to highest
level of priority and 100 corresponds to lowest level of priority. For instance, based
on the above table, the IP1:Port1 may receive the traffic before other IP and Port
combinations. For traffic calculation purpose, target with “0” weight should be
20 considered unavailable and if only single target with “0” weight is available, traffic
should be catered by lower priority targets.
[0123] If a first IP and Port combination and a second IP and Port combination from
the plurality of IP and Port combinations have the same priority, the traffic is
25 distributed between the first IP and Port combination and the second IP and Port
37
combination based on the weight associated with each of the first IP and Port
combination and the second IP and Port combination. In one example, if the priority
of one or more IP and Port combinations is same, the identification unit [304] may
split the traffic on the one or more IP and Port combinations based on the weight.
5 For instance, if two IP and Port combinations have same priority but the weight is
50 and 40, messages should be split in ration of 50:40 between the two IP and Port
combination. The selected IP and Port combination is assigned the highest priority.
[0124] Further, at step [610], the method comprises transmitting, by the transceiver
10 unit [302], from the NRF, the traffic to the selected the IP and the Port combination.
As described earlier, it is understood that the selected IP and Port combination will
have the highest assigned priority.
[0125] Further, the identification unit [304], at the NRF selects the next available
15 lower priority IP Port, in an event one or more higher priority IP Ports are
unavailable. The identification unit [304], at the NRF, selects the next available
lower priority IP and Port combination, in an event one or more higher priority IP
and Port combinations are unavailable. For example, when all of higher priority
targets become unavailable, targets provided with lower priority based on assigned
20 weights should cater to the traffic.
[0126] The identification unit [304], at the NRF, selects the one or more higher
priority IP and Port combinations, in an event the one or more higher priority IP
and Port combinations are available when the traffic at the one or more higher
25 priority IP and Port combinations falls below a threshold. The NRF retries to send
the traffic to higher priority IP and Port combinations once combinations catering
to existing traffic goes down.
[0127] Further, the transceiver unit [302] at the NRF triggers an alarm if the
30 plurality of IP and Port combinations is not reachable. The NRF keeps ping-pong
communication with all the instances of the SEPP. When a response is not received
38
from an instance and the request timed out, the instance is said to be not reachable.
In a condition when the plurality of SEPP IP:Ports are overloaded with traffic and
they are not able to take on any more traffic, they do not respond and become
unreachable. When the plurality of SEPP IP:Ports are not reachable and the NRF is
5 not able to forward the traffic, the transceiver unit [302] at the NRF transmits an
error code to the NF consumer. Further, a detection unit [308] at the NRF keeps
counters for successful and unsuccessful discovery requests and response based on
the availability and unavailability of the SEPP IP:Port combinations.
10 [0128] The NRF provides an automated selection and a command-line based
selection for switching the traffic between the plurality of IP and Port combinations.
For the automated selection, a processing unit [306] at the NRF runs a configurable
timer, based on which the NRF tries to create connection towards a primary IP and
Port combination based on the assigned priority. If the primary IP and Port
15 combination is available and up, the NRF sends the traffic to this combination. In
case the primary IP and Port combination is not available, the NRF should again
retry to establish connection based on the configurable timer. For the commandline based selection, the NRF should provide a command for switching the traffic
on a selected IP and Port combination.
20
[0129] The method [600] herein terminates at step [612].
[0130] Referring to FIG. 7, an exemplary method flow diagram [700] for
processing subscribe notifications from a Network Repository Function (NRF) to a
25 roaming partner (RP) Network Function (NF), in accordance with exemplary
implementations of the present disclosure is shown. In an implementation the
method [700] is performed by the system [400]. Further, in an implementation, the
system [400] may be present in a server device to implement the features of the
present disclosure. Also, as shown in FIG. 7, the method [700] starts at step [702].
30
39
[0131] At step [704], the method comprises checking, by a verification unit [402],
at the NRF, one or more subscribe conditions for a subscription of the RP NF. The
RP NF is registered at the RP NRF. The one or more subscribe conditions may be
defined by a number of parameters. The ‘NfInstanceIdListCond’ parameter which
5 describes subscription to a list of NF instances. The ‘NfTypeCond’ parameter
which describes subscription to a set of NF instances, identified by their NF type.
The parameter ‘ServiceNameCond’ which describes subscription to a set of NF
instances that offer a certain service name. These are some examples for the
parameters which describe the one or more conditions which are checked by the
10 NRF before responding back with the status notification. In an implementation, the
NRF may check the "reqNfType" and "reqNfFqdn" input attributes in the
subscription request body. The ‘reqNfType’ contains the NF type of the NF
Consumer, i.e. RP NF, that is requesting the creation of the subscription. The NRF
shall use it for authorizing the request. The ‘reqNfFqdn’ contains the FQDN of the
15 NF Consumer, i.e. RP NF, that is requesting the creation of the subscription. The
NRF shall use it for authorizing the request.
[0132] Next at step [706], the method comprises generating, by a processing unit
[404], at the NRF, a status notification for the RP NF, based on the checking of the
20 one or more subscribe conditions. The status notification is generated at the NRF if
the one or more subscribe conditions are met for an existing subscription of RP NF
stored at the NRF. The ‘NFStatusNotify’ service operation is used by the NRF to
generate the status notification for RP NF. The ‘NFStatusNotify’ allows the NRF
to notify subscribed NF Instances (i.e. RP NF) of changes on the status of NF
25 Instances. This service operation can be invoked directly between the NRF and an
NF Instance in a different PLMN (without involvement of the NRF in that PLMN).
[0133] Next at step [708], the method comprises modifying, by the processing unit
[404], at the NRF, the status notification by adding a callback Uniform Resource
30 Identifier (URI) to the status notification. The callback URI refers to a specific URI
to define a callback endpoint. The endpoint corresponds to a device where a
40
response or notification is received back after checking that the one or more
subscribe conditions are met. In one example, the NRF places the callback URI
received during subscription under headers of Authority and Path. To modify the
status notification by placing the callback URI, the transceiver unit [406] is
5 configured to receive a status subscribe request from an RP NRF at the NRF, where
the RP NRF is in a different PLMN. Further, the transceiver unit [406] is configured
to transmit, from the NRF, a subscribe response to a Security Edge Protection Proxy
(SEPP). The SEPP is in the Home or Serving PLMN. Furthermore, the processing
unit [404], is configured to modify, at the SEPP, the callback URI in the subscribe
10 response. The Callback URI should be modified so that notification messages from
the NRF are sent towards the SEPP rather than directly towards RP NF. The
transceiver unit [406] is further configured to receive from the SEPP at the NRF,
the modified subscribe response containing the modified Callback URI. The
processing unit [404] is further configured to identify, at the NRF, the Callback URI
15 from the modified subscribe response. The method focuses on using the same
modified Callback URI for subscription response. Thereafter, the transceiver unit
[406] transmits, from the NRF the modified status notification to the RP NF.
Further, it is to be noted that the RP NF is registered in the RP NRF.
20 [0134] The status subscribe request allows the RP NF to receive notifications about
the status changes of other NFs. The status change may be one of a registration,
deregistration, profile change, and the like. The status subscribe request includes
but may not be limited to a NF instance identifier (ID), the one or more subscribe
conditions, the notification endpoint and the like.
25
[0135] The processing unit [404], at the one or more SEPPs, also applies a topology
hiding to the Callback URI and one or more discovered NF profiles included in the
modified subscribe response. The topology hiding refers to a technique to conceal
network topology from unauthorized users to enhance security of the network. In
30 this way, the network functions outside the trust domain of the home PLMN have
no view of the URI (Uniform Resource Identifiers).
41
[0136] Further the method comprises forwarding, by the transceiver unit [406],
from the NRF, a subscribe response to Security Edge Protection Proxy (SEPPs). In
one example, when an NF Service Consumer subscribes to a set of NFs, a change
5 in the profile of the monitored NF instance may result in the NF becoming a part of
the NF set or stops becoming a part of the NF set. In such case, the NRF shall use
the "NF_PROFILE_CHANGED" event type in the notification.
[0137] The method further comprises modifying, by the processing unit [404],
10 where the processing unit [404] is located at the SEPP [408], the callback URI in
the subscribe response. The method further comprises transmitting, by a transceiver
unit [406], from the SEPP to the NRF, the modified subscribe response comprising
the callback URI. Furthermore, the method comprises identifying, by the processing
unit [404], at the NRF, the callback URI from the modified subscribe response. The
15 method includes applying, by the processing unit [404], at the SEPPS, a topology
hiding to the callback URI and one or more discovered NF profiles included in the
modified subscribe response.
[0138] Further, at step [710], the method comprises transmitting, by the transceiver
20 unit [406], from the NRF the modified status notification to the RP NF.
[0139] Referring to FIG. 8, an exemplary method flow diagram [800] for
processing subscribe notifications from a Network Repository Function (NRF) to a
roaming partner (RP) Network Function (NF), in accordance with exemplary
25 implementations of the present disclosure is shown. In an implementation the
method [800] is performed by the system [500]. Further, in an implementation, the
system [500] may be present in a server device to implement the features of the
present disclosure. Also, as shown in FIG. 8, the method [800] starts at step [802].
30 [0140] At step [804], the method comprises receiving, by a transceiver unit [502],
at a first NRF from the one or more NRFs, a subscription request from one or more
42
Security Edge Protection Proxy (SEPPs). The subscription request body shall
include the data indicating the type of notifications that the one or more NRFs are
interested in receiving; it also contains a callback URI, where the one or more NRFs
shall be prepared to receive the actual notification from the first NRF and it may
5 contain a validity time, suggested by the one or more NRFs, representing the time
span during which the subscription is desired to be kept active. The subscription
request may also include additional parameters indicating the list of attributes in the
NF Profiles to be monitored (or to be excluded from monitoring), in order to
determine whether a notification from the first NRF should be sent, or not, when
10 any of those attributes is changed in the profiles. The one or more NRFs may request
the creation of a subscription to a specific NF Instance, or to a set of NF Instances,
where the set is determined according to different criteria specified in the request
body, in the "subscrCond" attribute of the "SubscriptionData" object type included
in the subscription request. The subscription request shall include a PLMN ID when
15 subscribing to NF services in a different PLMN. When included, this parameter
shall contain the PLMN ID(s) of the requester NF, i.e. the one or more NRFs.
[0141] Next at step [806], the method comprises checking, by a verification unit
[504], at the first NRF, a Public Land Mobile Network Identifier (PLMN ID) and a
20 Network Identifier (NID) associated with the subscription request. The PLMN ID
comprises the mobile country code (MCC) and the mobile network code (MNC).
The NID attribute contains the target NID that, together with the PLMN ID
attribute, identifies the Stand-alone Non-Public Network (SNPN) of the NF
Instance(s) whose status is requested to be monitored.
25
[0142] Further at step [808], the method comprises identifying, by a processing unit
[506], at the first NRF, one of a positive status and a negative status. An NRF can
be configured with multiple PLMN IDs and shall support registering, updating and
deregistering the profile of Network Function (NF) Instances from any of these
30 PLMN IDs. The positive status refers to determining that the PLMN associated with
the PLMN ID is configured with/served by the first NRF. The negative status refers
43
to determining that the PLMN associated with the PLMN ID is not configured with
/not served by the first NRF.
[0143] Further at step [810], if the status is the positive status, the method
5 comprises processing, by a processing unit [506], at the first NRF, the subscription
request. Once, the processing unit [506] has identified that the first NRF is
configured to serve the PLMN associated with the PLMN ID, the first NRF
processes the subscription request. The processing unit [506] is further configured
to generate, at the first NRF, a response comprising a subscription ID. The
10 subscription ID comprises the MCC and the MNC. Further, the transceiver unit
[502] is configured to forward, from the first NRF the generated response to the one
or more SEPPs.
[0144] The transceiver unit [502] is further configured to forward, from the first
15 NRF the subscription request to a second NRF from the one or more NRFs, based
on the negative status. The subscription request is forwarded to the second NRF
based on identifying that the PLMN associated with the PLMN ID is served by the
second NRF.
20 [0145] The method further comprises generating, by the processing unit [506], at
the first NRF, a response comprising a subscription identifier (ID) if the one or more
subscription requests is received from the SEPP. The subscription ID comprises the
MCC and the MNC. To generate the response, the processing unit [506] checks if
the request is received from the SEPP only. In one example, if the request is not
25 received from the SEPP, the response may not be generated. Further, the method
includes forwarding, by the transceiver unit [502], from the first NRF the generated
response to the one or more SEPPs.
[0146] In an exemplary implementation of the present disclosure, the transceiver
30 unit [502], is configured to receive, at the first NRF, a message from the one or
more SEPPs, wherein the message comprises the subscription ID. Thereafter, the
44
processing unit [506] determines, at the first NRF, one of a positive status and a
negative status, based on the MCC and MNC derived from the subscription ID.
Further, the message is one of a status unsubscribe message and a status update
message.
5
[0147] The processing unit [506] is configured to determine, at the first NRF, one
of a positive status and a negative status, based on the MCC and MNC derived from
the subscription ID. The processing unit [506] then processes the message at the
first NRF, based on the positive status. The positive status is determined when the
10 MCC and MNC combination indicates the PLMN ID associated with the first NRF.
[0148] The transceiver unit forwards, from the first NRF, the message to the second
NRF based on the negative status. The negative status is determined when the MCC
and MNC combination indicates PLMN ID associated with the second NRF.
15
[0149] Further, the transceiver unit [502], transmits from the first NRF, an error
code to the one or more SEPPs if the PLMN associated with the PLMN ID fails to
be processed at the first NRF and the second NRF. In such a case, the NRF keeps
counters for successful and unsuccessful NFStatusUnSubscribe and Update
20 NFStatusSubscribe request/response for RP PLMN.
[0150] The method [800] terminates at step [814].
[0151] Referring to FIG. 9, an implementation of a call flow diagram [900] for
25 processing subscribe notifications from a Network Repository Function (NRF) to a
roaming partner (RP) Network Function (NF), in accordance with exemplary
implementations of the present disclosure is shown.
[0152] At Step [1], the NRF [902] of a serving PLMN sends a NFStatusNotify
30 request service operation towards a SEPP [408]. The NFStatusNotify service
operation allows the NRF [902] to notify subscribed NF of changes on the status of
45
NF Instances. This service operation can be invoked directly between the NRF and
an NF Instance in a different PLMN (without involvement of the local NRF in that
PLMN). Further, the NRF [902] and the SEPP [408] are in the Home or Serving
PLMN. The NRF [902] send the NFStatusNotify request to SEPP [408] in response
5 to the subscribe request from a Roaming Partner (RP) Network Function (NF).
After the NRF [902] has verified the subscription conditions in the subscribe
request, the NRF [902] send the NFStatusNotify request to the SEPP [408]. The
NRF [902] may check the one or more subscribe conditions for a subscription of
the RP NF. The one or more subscribe conditions may be met or may not met. If
10 the one or more subscribe conditions are met, a status notification for the RP NF is
generated at the NRF [902].
[0153] The SEPP [408], on receiving the NFStatusNotify request from the NRF
[902], modifies the callback URI included in the request. The Callback URI should
15 be modified so that notification messages from the NRF are sent towards the SEPP
rather than directly towards RP NF.
[0154] At Step [2], the modified subscribe response is transmitted from the SEPP
[408] to the NRF [902], the modified subscribe response comprising the modified
20 callback URI.
[0155] Referring to FIG. 10, another implementation of a call flow diagram [1000]
to notify for subscribe notifications from a Network Repository Function (NRF) to
a roaming partner (RP) Network Function (NF), in accordance with exemplary
25 implementations of the present disclosure is shown.
[0156] At Step [1], a NFStatusSubscribe Create Request received at a Security
Edge Protection Proxy (SEPP) is sent to a Service Communication Proxy (SCP)
[1002]. Then at Step [2], the SCP [1002] forwards the subscription request to the
30 First NRF [1004]. The subscription request shall include a PLMN ID when
46
subscribing to NF services in a different PLMN. When included, this parameter
shall contain the PLMN ID(s) of the requester NF, i.e. the one or more NRFs.
[0157] The First NRF [1004], checks the Public Land Mobile Network Identifier
5 (PLMN ID) and a Network Identifier (NID) associated with the subscription
request. The PLMN ID comprises the mobile country code (MCC) and the mobile
network code (MNC). The NID attribute contains the target NID that, together with
the PLMN ID attribute, identifies the Stand-alone Non-Public Network (SNPN) of
the NF Instance(s) whose status is requested to be monitored. An NRF can be
10 configured with multiple PLMN IDs and shall support registering, updating and
deregistering the profile of Network Function (NF) Instances from any of these
PLMN IDs. Therefore, the First NRF [1004] determines if the PLMN associated
with the PLMN ID is served by the First NRF [1004] or not. If it is determined that
the PLMN associated with the PLMN ID is not configured with /not served by the
15 first NRF [1004], then the First NRF [1004] forwards the request to the Second
NRF [1006] at Step [3]. If it is determined that the PLMN associated with the
PLMN ID is configured with / served by the first NRF [1004], then the First NRF
[1004] serves the requests locally.
20 [0158] Next, the request gets processed at the Second NRF [1006] and then the
Second NRF [1006] transmits a NFStatusSubscribe Response to the First NRF
[1004] at Step [4]. The response comprises a subscription ID. The subscription ID
comprises the MCC and the MNC.
25 [0159] At Step [5], the First NRF [1004] forwards the response to the SCP [1002],
which then forwards the response to SEPP [408] at Step [6].
[0160] Referring to FIG. 11, an implementation of a call flow diagram [1100] for
managing subscriptions at one or more Network Repository Functions (NRFs),
30 where message is for unsubscribing, in accordance with exemplary
implementations of the present disclosure is shown.
47
[0161] The first NRF [1104] receives an NFStatusUnSubscribe request from the
SEPP [408] via the SCP [1102] at Steps [1] and [2]. The NFStatusUnsubscribe
request allows an NF instance to unsubscribe to changes on the status of NF
5 registered in an NRF. The NFStatus Unsubscribe operation may be invoked by an
NF Instance in a different PLMN (via a local NRF in that PLMN) for changes on
the status of NF Instances. Further the NFStatusUnsubscribe request contains the
SubscriptionID of the already created subscription.
10 [0162] The mobile country code (MCC) and the mobile network code (MNC) may
already be added in the of NFStatusUnSubscribe message. The NRF makes
decision to either process locally or forward to a second NRF based on the MCC
and the MNC derived from Subscription ID. Where the MCC and the MNC
combination indicates a local NRF, the NRF should remove the MCC and the MNC
15 and lookup for Subscription ID. In another example, if the MCC and the MNC is
of another NRF, the message should be forwarded to the other NRF accordingly.
[0163] If the First NRF [1104] determines that the NFStatusUnsubscribe request
cannot be processed locally, it forwards the NFStatusUnsubscribe request to Second
20 NRF [1106] at Step [3].
[0164] Next at Step [4], the Second NRF [1106] send back NFStatusUnsubscribe
response which is further forwarded by the First NRF [1104] at Step [5] to SCP
[1006], which then forwards the same to SEPP [408] at Step [6].
25
[0165] In an exemplary implementation of the present disclosure, following two
scenarios are described below. The first scenario relates to a case when the NRF
receives an unsubscribe/update subscribe message directly from a SEPP. In this
case MCC+MNC should be appended already and the NRF (first NRF) should
30 make decision to either process locally or forward to other NRF (Second NRF)
based on MCC/MNC derived from SubscriptionID. In case, MCC/MNC
48
combination indicates local NRF (first NRF) only, NRF should remove the
MCC/MNC and lookup for Subscription ID. In case MCC/MNC is of another NRF
(second NRF), message should be forwarded accordingly. The second scenario
describes when the NRF (first NRF) indirectly receives UnSubscribe/ Update
5 Subscribe message from a SEPP. In this case, MCC+MNC may or may not be
present as part of SubscriptionID at target NRF (first NRF). In case, MCC/MNC
combination indicates local NRF (first NRF) only, NRF should remove the
MCC/MNC and lookup for Subscription ID. In case MCC/MNC is not present,
NRF should assume that message is for local NRF (first NRF) only and should
10 process accordingly. In case MCC/MNC is of another NRF (second NRF), message
should be forwarded accordingly. Further, it is to be noted that NRF is able to check
for SubscriptionID both with/without SubscriptionID.
[0166] The present disclosure further discloses a non-transitory computer readable
15 storage medium storing instructions for processing a traffic by a network
Repository Function (NRF) from a NF Consumer, the instructions include
executable code which, when executed by one or more units of a system, cause a
transceiver unit to receive, at a network repository function (NRF), the traffic from
the NF Consumer. The instructions when executed by the system further cause an
20 identification unit to identify, at the NRF, a plurality of Internet Protocol (IP) and
Ports combination associated with one or more Security Edge Protection Proxy
(SEPP). Each of the IP Port from the plurality of IP Ports is assigned a weight and
a priority. The instructions when executed by the system further cause the
identification unit to select, at the NRF, an IP Port from the plurality of IP Ports
25 associated with the one or more SEPPs based on the assigned weight and priority.
The instructions when executed by the system further cause the identification unit
to transmit, from the NRF, the traffic to the selected the IP and the Port.
[0167] Yet another aspect of the present disclosure may relate to a non-transitory
30 computer readable storage medium storing instructions for managing a subscription
request at one or more Network Repository Functions (NRFs), the instructions
49
include executable code which, when executed by one or more units of a system
cause a verification unit to check, at the NRF, one or more subscribe conditions for
a subscription of the RP NF. The instructions when executed by the system further
cause a processing unit to generate, at the NRF, a status notification for the RP NF,
5 based on the checking of the one or more subscribe conditions. The instructions
when executed by the system further cause the processing unit to modify, at the
NRF, the status notification by placing a callback Uniform Resource Identifier
(URI). The instructions when executed by the system further cause the transceiver
unit to transmit, from the NRF the modified status notification to the RP NF.
10
[0168] Yet another aspect of the present disclosure may relate to a non-transitory
computer readable storage medium storing instructions for managing a subscription
request at one or more Network Repository Functions (NRFs), the instructions
include executable code which, when executed by one or more units of a system
15 cause a transceiver unit to receive at a first NRF from the one or more NRFs, the
subscription request from one or more Security Edge Protection Proxy (SEPPs).
The instructions when executed by the system further cause a verification unit to
check, at the first NRF, a Public Land Mobile Network Identifier (PLMN ID) and
a Network Identifier (NID) associated with the subscription request. The
20 instructions when executed by the system further cause a processing unit to identify,
at the first NRF, one of a positive status and a negative status based on determining
if the PLMN associated with the PLMN ID is served by the first NRF. The
instructions when executed by the system further cause the processing unit to
process, at the first NRF, the subscription request based on the positive status. The
25 instructions when executed by the system further cause the transceiver unit to
forward, from the first NRF the subscription request to a second NRF from the one
or more NRFs based on the negative status.
[0169] As is evident from the above, the present disclosure provides a technically
30 advanced solution for processing a traffic by a network Repository Function (NRF)
from a NF Consumer. The present solution provides ability to integrate with
50
Security Edge Protection Proxy (SEPP) via Service Communication Proxy (SCP).
The present disclosure further provides ability to cater to requests from Local NF
for In-roamers. The present disclosure provides ability to cater to Requests from
Roaming Partners for Out-roamers.
5
[0170] While considerable emphasis has been placed herein on the disclosed
implementations, it will be appreciated that many implementations can be made and
that many changes can be made to the implementations without departing from the
principles of the present disclosure. These and other changes in the implementations
10 of the present disclosure will be apparent to those skilled in the art, whereby it is to
be understood that the foregoing descriptive matter to be implemented is illustrative
and non-limiting.
[0171] Further, in accordance with the present disclosure, it is to be acknowledged
15 that the functionality described for the various components/units can be
implemented interchangeably. While specific embodiments may disclose a
particular functionality of these units for clarity, it is recognized that various
configurations and combinations thereof are within the scope of the disclosure. The
functionality of specific units as disclosed in the disclosure should not be construed
20 as limiting the scope of the present disclosure. Consequently, alternative
arrangements and substitutions of units, provided they achieve the intended
functionality described herein, are considered to be encompassed within the scope
of the present disclosure.
51
We Claim:
1. A method [600] for processing a traffic by a network Repository
Function (NRF) from a Network Function Consumer (NF Consumer),
5 the method comprising:
- receiving, by a transceiver unit [302], at a network repository
function (NRF), the traffic from the NF Consumer;
- identifying, by an identification unit [304], at the NRF, a plurality
of Internet Protocol (IP) and Port combinations associated with
10 one or more Security Edge Protection Proxy (SEPP), wherein each
of the IP Port from the plurality of IP and Port combinations is
assigned a weight and a priority;
- selecting, by the identification unit [304], at the NRF, an IP and
Port combination from the plurality of IP and Port combinations
15 associated with the one or more SEPPs based on the assigned
weight and priority; and
- transmitting, by the transceiver unit [302], from the NRF, the
traffic to the selected IP and the Port combination.
20 2. The method [600] as claimed in claim 1, wherein the traffic comprises
a plurality of NF discovery requests.
3. The method [600] as claimed in claim 2, wherein the NF Consumer is
associated with a first network operator and sends a discovery request
25 to a second network operator.
4. The method [600] as claimed in claim 1, wherein if a first IP and Port
combination and a second IP and Port combination from the plurality of
IP and Port combinations have the same priority, distributing the traffic
30 between the first IP and Port combination and the second IP and Port
52
combination based on the weight associated to each of the first IP and
Port combination and the second IP and Port combination.
5. The method [600] as claimed in claim 1, wherein, the method further
5 comprises selecting, by the identification unit [304], at the NRF, the next
available lower priority IP and Port combination, in an event one or
more higher priority IP Ports are unavailable.
6. The method [600] as claimed in claim 5, wherein the method further
10 comprises selecting, at the identification unit [304], at the NRF, the one
or more higher priority IP and Port combinations, in an event the one or
more higher priority IP and Port combinations are available when the
traffic at the one or more higher priority IP and Port combinations falls
below a threshold.
15
7. The method [600] as claimed in claim 1, wherein the NRF provides an
automated selection and a command-line based selection for switching
the traffic between the plurality of IP Ports, wherein the automated
selection comprises running a configurable timer, based on which the
20 NRF selects an IP and Port combination.
8. The method [600] as claimed in claim 1, wherein the method further
comprises transmitting, by the transceiver unit [302], at the NRF, an
error code to the NF consumer, if the plurality of IP and Port
25 combinations is unavailable based on the traffic and triggering, an alarm
if the plurality of IP and Port combinations is not reachable.
9. A method [700] for processing subscribe notifications from a Network
Repository Function (NRF) to a roaming partner (RP) Network
30 Function (NF) and, the method comprising:
53
- checking, by a verification unit [402], at the NRF, one or more
subscribe conditions for a subscription of the RP NF;
- generating, by a processing unit [404], at the NRF, a status
notification for the RP NF, based on the checking of the one or
5 more subscribe conditions;
- modifying, by the processing unit [404], at the NRF, the status
notification by adding a callback Uniform Resource Identifier
(URI) to the status notification; and
- transmitting, by the transceiver unit [406], from the NRF the
10 modified status notification to the RP NF.
10. The method [700] as claimed in claim 9, wherein modifying the status
notification by placing the callback URI comprises:
- receiving, by a transceiver unit [406], at the NRF, a status
15 subscribe request from an RP NRF;
- forwarding, by the transceiver unit [406], from the NRF, a
subscribe response to a Security Edge Protection Proxy (SEPP);
- modifying, by a processing unit [404], at the SEPP, a callback URI
in the subscribe response;
20 - transmitting, by a transceiver unit [406], from the SEPP to the
NRF, the modified subscribe response comprising the callback
URI; and
- identifying, by the processing unit [404], at the NRF, the callback
URI from the modified subscribe response.
25
11. The method [700] as claimed in claimed 9, wherein the status
notification is generated at the NRF if the one or more subscribe
conditions are met for an existing subscription of RP NF stored at the
NRF.
30
54
12. The method [700] as claimed in claim 11, wherein the RP NF is
registered at the RP NRF.
13. The method [700] as claimed in claim 10, wherein, the processing unit
5 [404], at the one or more SEPPs, applies a topology hiding to the
callback URI and one or more discovered NF profiles included in the
modified subscribe response.
14. A method [800] for managing a subscription request at one or more
10 Network Repository Functions (NRFs), the method comprising:
- receiving, by a transceiver unit [502], at a first NRF from the one
or more NRFs, the subscription request from a Security Edge
Protection Proxy (SEPP);
- checking, by a verification unit [504], at the first NRF, a Public
15 Land Mobile Network Identifier (PLMN ID) and a Network
Identifier (NID) associated with the subscription request;
- identifying, by a processing unit [506], at the first NRF, one of a
positive status and a negative status based on determining if the
PLMN associated with the PLMN ID is served by the first NRF;
20 - processing, by a processing unit [506], at the first NRF, the
subscription request based on the positive status;
- forwarding, by the transceiver unit [502], from the first NRF the
subscription request to a second NRF from the one or more NRFs
based on the negative status;
25 - generating, by the processing unit [506], at the first NRF, a
response comprising a subscription identifier (ID); and
- forwarding, by the transceiver unit [502], from the first NRF the
generated response to the SEPP.
30
55
15. The method [800] as claimed in claim 14, wherein forwarding the
subscription request to the second NRF is based on identifying that the
PLMN is served by the second NRF.
5 16. The method [800] as claimed in claim 14, wherein the PLMN ID and
the subscription ID comprise a mobile country code (MCC) and a
mobile network code (MNC).
17. The method [800] as claimed in claim 14, wherein the transceiver unit
10 [502], transmits from the first NRF, an error code to the SEPP if the
PLMN associated with the PLMN ID fails to be processed by the first
NRF and the second NRF.
18. The method [800] as claimed in claim 16, the method further comprises:
15 - receiving, by a transceiver unit [502], at the first NRF, a message
from the SEPP, wherein the message comprises the subscription
ID and wherein the message is one of a status unsubscribe message
and a status update message;
- determining, by the processing unit [506], at the first NRF, one of
20 a positive status and a negative status, based on the MCC and
MNC derived from the subscription ID;
- processing, by the processing unit [506], at the first NRF, the
message based on the positive status; and
- forwarding, by the transceiver unit [502], from the first NRF, the
25 message to the second NRF based on the negative status.
19. The method [800] as claimed in claim 18, wherein the positive status is
determined when the MCC and MNC combination indicates PLMN ID
associated with the first NRF.
30
56
20. The method [800] as claimed in claim 18, wherein the negative status is
determined when the MCC and MNC combination indicates PLMN ID
associated with the second NRF.
5 21. The method [800] as claimed in claim 19, wherein the first NRF
removes the MCC and MNC from the subscription ID if the message is
processed at the first NRF.
22. A system [300] for processing a traffic by a network Repository
10 Function (NRF) from a Network Function Consumer (NF Consumer),
the system comprising:
- a transceiver unit [302], configured to receive, at a network
repository function (NRF), the traffic from the NF Consumer;
- an identification unit [304], configured to identify, at the NRF, a
15 plurality of Internet Protocol (IP) and Ports combination
associated with one or more Security Edge Protection Proxy
(SEPP), wherein each of the IP Port from the plurality of IP Ports
is assigned a weight and a priority;
- the identification unit [304], configured to select, at the NRF, an
20 IP and Port combination from the plurality of IP and Port
combinations associated with the one or more SEPPs based on the
assigned weight and priority; and
- the transceiver unit [302], configured to transmit, from the NRF,
the traffic to the selected IP and port combination.
25
23. The system [300] as claimed in claim 22, wherein the traffic comprises
a plurality of NF discovery requests.
24. The system [300] as claimed in claim 22, wherein the NF Consumer is
30 associated with a first network operator and sends a discovery request
to a second network operator.
57
25. The system [300] as claimed in claim 22, wherein if a first IP and Port
combination and a second IP and Port combination from the plurality of
IP and Port combinations have the same priority, distributing the traffic
5 between the first IP and Port combination and the second IP and Port
combination based on the weight associated with each of the first IP and
Port combination and the second IP and Port combination.
26. The system [300] as claimed in claim 22, wherein, the identification unit
10 [304], at the NRF selects the next available lower priority IP and Port
combination, in an event one or more higher priority IP and Port
combinations are unavailable.
27. The system [300] as claimed in claim 22, wherein the identification unit
15 [304], at the NRF selects the one or more higher priority IP and Port
combinations, in an event the one or more higher priority IP and Port
combinations are available when the traffic at the one or more higher
priority IP and Port combinations falls below a threshold.
20 28. The system [300] as claimed in claim 22, wherein the NRF provides an
automated switching and a command-line based switching for switching
the traffic between the plurality of IP and Port combinations, wherein
for the automated switching a processing unit [306] at the NRF runs a
configurable timer, based on which the NRF selects an IP and Port
25 combination.
29. The system [300] as claimed in claim 22, wherein the transceiver unit
[302] at the NRF transmits an error code to the NF consumer, if the
plurality of IP and Port combinations is unavailable based on the traffic
30 and triggers an alarm if the plurality of IP and Port combinations is not
reachable.
58
30. A system [400] for processing subscribe notifications from a Network
Repository Function (NRF) to a roaming partner (RP) Network
Function (NF) and, the system comprising:
5 - a verification unit [402], configured to check, at the NRF, one or
more subscribe conditions for a subscription of the RP NF;
- a processing unit [404], configured to generate, at the NRF, a
status notification for the RP NF, based on the checking of the one
or more subscribe conditions;
10 - the processing unit [404], configured to modify, at the NRF, the
status notification by placing a callback Uniform Resource
Identifier (URI); and
- the transceiver unit [406], configured to transmit, from the NRF
the modified status notification to the RP NF.
15
31. The system [400] as claimed in claim 30, wherein modifying the status
notification by placing the callback URI comprises:
- the transceiver unit [406], further configured to:
o receive, at the NRF, a status subscribe request from an RP
20 NRF;
o transmit, from the NRF, a subscribe response to a Security
Edge Protection Proxy (SEPP);
- the processing unit [404], configured to modify, at the SEPP, a
callback URI in the subscribe response;
25 - the transceiver unit [406], further configured to transmit, from the
SEPP to the NRF, the modified subscribe response containing the
callback URI; and
- the processing unit [404], further configured to identify, at the NRF,
the callback URI from the modifies subscribe response.
30
59
32. The system [400] as claimed in claimed 30, wherein the status
notification is generated at the NRF if the one or more subscribe
conditions are met for an existing subscription of RP NF.
5 33. The system [400] as claimed in claim 32, wherein the RP NF is
registered at the RP NRF.
34. The system [400] as claimed in claim 31, wherein, the processing unit
[404], at the SEPP, applies a topology hiding to the callback URI and
10 one or more discovered NF profiles included in the modified subscribe
response.
35. A system [500] for managing a subscription request at one or more
Network Repository Functions (NRFs), the system comprising:
15 - a transceiver unit [502], configured to receive, at a first NRF from
the one or more NRFs, the subscription request from one or more
Security Edge Protection Proxy (SEPPs);
- a verification unit [504], configured to check, at the first NRF, a
Public Land Mobile Network Identifier (PLMN ID) and a Network
20 Identifier (NID) associated with the subscription request;
- a processing unit [506], configured to identify, at the first NRF,
one of a positive status and a negative status based on determining
if the PLMN associated with the PLMN ID is served by the first
NRF;
25 - the processing unit [506], configured to process, at the first NRF,
the subscription request based on the positive status; and
- the transceiver unit [502], configured to forward, from the first
NRF the subscription request to a second NRF from the one or
more NRFs based on the negative status;
30 - the processing unit [506], configured to generate, at the first NRF,
a response comprising a subscription ID; and
60
- the transceiver unit [502], configured to forward, from the first
NRF the generated response to the one or more SEPPs.
36. The system [500] as claimed in claim 35, wherein forwarding the
5 subscription request to the second NRF is based on identifying that the
PLMN is served by the second NRF.
37. The system [500] as claimed in claim 35, wherein the PLMN ID and
subscription ID comprise a mobile country code (MCC) and a mobile
10 network code (MNC).
38. The system [500] as claimed in claim 35, wherein the transceiver unit
[502], transmits from the first NRF, an error code to the one or more
SEPPs if the PLMN associated with the PLMN ID fails to be processed
15 at the first NRF and the second NRF.
39. The system [500] as claimed in claim 37, the system further comprises:
- the transceiver unit [502], configured to receive, at the first NRF,
a message from the SEPP, wherein the message comprises the
20 subscription ID and wherein the message is one of a status
unsubscribe message and a status update message;
- the processing unit [506], configured to determine, at the first
NRF, one of a positive status and a negative status, based on the
MCC and MNC derived from the subscription ID;
25 - the processing unit [506], configured to process, at the first NRF,
the message based on the positive status;
- the transceiver unit [502], configured to forward, from the first
NRF, the message to the second NRF based on the negative status.
61
40. The system [500] as claimed in claim 39, wherein the positive status is
determined when the MCC and MNC combination indicates PLMN ID
associated with the first NRF.
5 41. The system [500] as claimed in claim 39, wherein the negative status is
determined when the MCC and MNC combination indicates PLMN ID
associated with the second NRF.
42. The system [500] as claimed in claim 40, wherein the first NRF removes
10 the MCC and MNC from the subscription ID if the message is processed
at the first NRF.