WO2021224545A1 - Enhanced registration in communication networks - Google Patents

Enhanced registration in communication networks Download PDF

Info

Publication number
WO2021224545A1
WO2021224545A1 PCT/FI2021/050290 FI2021050290W WO2021224545A1 WO 2021224545 A1 WO2021224545 A1 WO 2021224545A1 FI 2021050290 W FI2021050290 W FI 2021050290W WO 2021224545 A1 WO2021224545 A1 WO 2021224545A1
Authority
WO
WIPO (PCT)
Prior art keywords
function
network
registration
token
application function
Prior art date
Application number
PCT/FI2021/050290
Other languages
French (fr)
Inventor
Pradyumna Ram PRASAD
Harish MURALIDHARA
Nagendra Bykampadi
Krishnamurthy MAHADEVAIAH
Original Assignee
Nokia Technologies Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Technologies Oy filed Critical Nokia Technologies Oy
Publication of WO2021224545A1 publication Critical patent/WO2021224545A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44Program or device authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • H04W12/069Authentication using certificates or pre-shared keys
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08Access security
    • H04W12/084Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60Context-dependent security
    • H04W12/61Time-dependent

Definitions

  • Various example embodiments relate in general to communication networks, such as core networks of cellular communication systems, and more specifically, to enhanced registration in such networks.
  • Registration to services is needed in various communication networks. Registration needs to be enabled for example in core networks of cellular communication systems, such as in 5 G core networks developed by the 3rd Generation Partnership Project, 3GPP. Using 5G as an example, in 5G core networks at least non-trusted 3 rd party Application Functions, AFs, should be able to register to some services and improvements are needed for that. Also, in general there is a need to provide improved methods, apparatuses and computer programs for registration in communication networks, such as in 5G core networks, and in other networks in the future as well.
  • a first method comprising, receiving, by a network exposure function, onboarding information from an application function, said onboarding information comprising information about the application function, upon receiving said onboarding information, transmitting by the network exposure function a registration request to a network repository function on behalf of the application function, responsive to transmitting the registration request, receiving by the network exposure function a registration response indicating successful registration from the network repository function, the registration response comprising an identity token associated with registration of the application function, wherein the identity token is to be used for all subsequent communication with the network repository function by the application function and transmitting an onboarding response to the application function, the onboarding response comprising the identity token.
  • Example embodiments of the first method may comprise at least one feature from the following bulleted list:
  • the registration request comprises a field indicating that the registration request is associated with a registration of a third party
  • the identity token comprises an issuer field indicating that an issuer of the identity token is the network repository function and a subject field indicating that a subject of the identity token is the application function;
  • the identity token comprises an expiry time indicating a time after which the identity token will not be valid and an issue time indicating when the identity token was issued;
  • a second method comprising receiving, by a network repository function, a registration request from a network exposure function, wherein the registration request is associated with an application function; responsive to receiving the registration request, determining by the network repository function that the application function can be registered and registering the application function and transmitting a registration response indicating successful registration, wherein the registration response comprises an identity token associated with registration of the application function and the identity token is to be used for all subsequent communication with the network repository function by the application function.
  • Example embodiments of the second method may comprise at least one feature from the following bulleted list:
  • the registration request comprises a field indicating that the registration request is associated with a registration of a third party
  • the identity token comprises an issuer field indicating that an issuer of the identity token is the network repository function and a subject field indicating that a subject of the identity token is the application function;
  • the identity token comprises an expiry time indicating a time after which the identity token will not be valid and an issue time indicating when the identity token was issued;
  • Example embodiments of the first or the second method may comprise at least one feature from the following bulleted list: • the application function is a non-trusted third party application function;
  • the network exposure function and the network repository function operate according to at least one standard specification defined by a 3 rd Generation Partnership Project, 3GPP;
  • the network exposure function and the network repository function are in a core network of a cellular communication network
  • the core network is a 5G core network.
  • an apparatus comprising one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform the first method.
  • the at least one memory and the computer program code may be configured to, with the at least one processing core, cause the apparatus at least to perform, receive, by a network exposure function, onboarding information from an application function, said onboarding information comprising information about the application function, transmit by the network exposure function a registration request to a network repository function on behalf of the application function upon receiving said onboarding information, receive, responsive to transmitting the registration request, by the network exposure function a registration response indicating successful registration from the network repository function, the registration response comprising an identity token associated with registration of the application function, wherein the identity token is to be used for all subsequent communication with the network repository function by the application function and transmit an onboarding response to the application function, the onboarding response comprising the identity token.
  • an apparatus comprising one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform the second method.
  • the at least one memory and the computer program code may be further configured to, with the at least one processing core, cause the apparatus at least to perform, receive, by a network repository function, a registration request from a network exposure function, wherein the registration request is associated with an application function, determine, responsive to receiving the registration request, by the network repository function that the application function can be registered and registering the application function and transmit a registration response indicating successful registration, wherein the registration response comprises an identity token associated with registration of the application function and the identity token is to be used for all subsequent communication with the network repository function by the application function.
  • an apparatus comprising means for performing the first method.
  • the apparatus may comprise means for receiving, by a network exposure function, onboarding information from an application function, said onboarding information comprising information about the application function, means for transmitting by the network exposure function a registration request to a network repository function on behalf of the application function upon receiving said onboarding information, means for receiving, responsive to transmitting the registration request, by the network exposure function a registration response indicating successful registration from the network repository function, the registration response comprising an identity token associated with registration of the application function, wherein the identity token is to be used for all subsequent communication with the network repository function by the application function and means for transmitting an onboarding response to the application function, the onboarding response comprising the identity token.
  • an apparatus comprising means for performing the second method.
  • the apparatus may comprise means for receiving, by a network repository function, a registration request from a network exposure function, wherein the registration request is associated with an application function, means for determining, responsive to receiving the registration request, by the network repository function that the application function can be registered and registering the application function and means for transmitting a registration response indicating successful registration, wherein the registration response comprises an identity token associated with registration of the application function and the identity token is to be used for all subsequent communication with the network repository function by the application function.
  • non-transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least perform the method of the first aspect.
  • non-transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least perform the method of the second aspect.
  • a computer program configured to perform the method of the first aspect.
  • a computer program configured to perform the method of the second aspect.
  • FIGURE 1 illustrates a system in accordance with at least some example embodiments
  • FIGURE 2 illustrates a first process in accordance with at least some example embodiments
  • FIGURE 3 illustrates a second process in accordance with at least some example embodiments
  • FIGURE 4 illustrates an example apparatus capable of supporting at least some example embodiments
  • FIGURE 5 illustrates a flow graph of a first method in accordance with at least some example embodiments.
  • FIGURE 6 illustrates a flow graph of a second method in accordance with at least some example embodiments.
  • the procedures described herein enable registration for example for non- trusted 3 rd party Application Functions, AFs, in communication networks, such as in 5G core networks or in other core networks.
  • the network may comprise a Network Repository Function, NRF, and a Network Exposure Function, NEF.
  • registration of a non-trusted 3 rd party AF may be enabled by registering information about the non-trusted 3 rd party at the NRF during onboarding, with/at a Common Application Programming Interface Framework, CAPIF, for example.
  • CAPIF Common Application Programming Interface Framework
  • the NRF may provide an identity token to the non-trusted 3 rd party AF in response to a registration request, wherein the identity token is to be used for all further, subsequent communication with the NRF by the non-trusted 3 rd party AF, directly or via the NEF.
  • the identity token may be used in subsequent access token requests.
  • FIGURE 1 illustrates an exemplary network scenario in accordance with at least some example embodiments of the present invention.
  • the exemplary network scenario shown in FIGURE 1 comprises communication network 100, such as a core network of a cellular communication network like 5G network.
  • AF 102 may be located outside of communication network 100, i.e., AF 102 may be a non-trusted AF.
  • North bound interface, Nnef 103 may exist between AF 102 and NEF 104.
  • NEF 104 may be in communication network 100 and further comprise Application Exposure Function, AEF, 106 and CAPIF 108.
  • communication network 100 may also comprise NRF 110.
  • communication network 100 may further comprise at least one of Access and Mobility Function, AMF 112, User Data Repository, UDR 114, Unified Data Management, UDM 116, and Session Management Function, SMF 118.
  • AF 102, NEF 104 and NRF 110 may be Network Functions, NFs.
  • a NF may refer to an operational and/or a physical entity.
  • An NF may be a specific network node or element, or a specific function or set of functions carried out by one or more entities, such as Virtual Network Functions, VNFs. At least some embodiments of the present invention may be applied in containerized deployments as well.
  • One physical node may be configured to perform functionalities of plural NFs.
  • AF 102 may not be a NF though as defined by the 3 GPP. Instead, AF 102 may be a complement to the NF. AF 102 may be a non-trusted 3 rd party AF, e.g., for an enterprise.
  • AF 102 may be an AF as defined in the 3GPP standard specification TS 29.517.
  • OAuth based authorization and token exchange may be applied between NFs.
  • NRF 110 may be or perform functionalities of an OAuth server.
  • NRF 110 may be an NRF as defined in the 3GPP standard specification TS 29.510, wherein token and management end points of NRFs are defined.
  • NEF 104 which may expose 3GPP network capabilities to AF 102 via RESTful Application Programming Interfaces, APIs, may be a NEF as defined in the 3GPP standard specification TS 29.522.
  • dashed line between AF 102 and NEF 104 may demonstrate a trust based on Transport Layer Security, TLS, certificates.
  • CAPIF 106 may trust AF 102 based on TLS certificates.
  • AF 102 may further trust end points of CAPIF 106 to authorize services provided by AEF 108.
  • NEF 104 may be an entry point to communication network 100 for AF 102 and in general for all AFs.
  • NEF 104 may demonstrate existing trust among core NFs, e.g., due to common root certificates and access tokens provided by NRF 110 for accessing services.
  • NFs such as NRF 110 may trust NEF 104 based on pre-provisioned certificates used for communication.
  • NFs may also register with NRF 110 and use access tokens provided by NRF 110 to provide and request for access of different services.
  • this chain of trust may be leveraged to allow 3 rd party AFs, particularly non- trusted 3 rd party AFs, to register themselves in communication network 100, such as a in 5G core network.
  • Nnef 103 may exist between AF 102 and NEF 106, AF 102 would need to contact either CAPIF 106 or NRF 110 to get to an endpoint of NEF 104.
  • CAPIF 106 or NRF 110 should be already aware of AF 102 before providing the endpoint of NEF 104 or granting an access token for AF 102, wherein the access token can be used to access the services of NEF 104 or a NF producer which is associated with NEF 104.
  • NRF 110 So when NRF 110 must issue an access token based on specific parameters of AF 102, NRF 110 would need to rely on local configurations.
  • Embodiments of the present invention therefore provide network configurability for issuing an access token, instead of local configurations, and registration of AF 102 with NRF 110.
  • embodiments of the present invention effectively restrict non-trusted 3 rd party AFs to access only a certain set of NEFs to access services provided by communication network 100, such as 5G core network, thereby ensuring that AF 102 cannot perform an attack on all the NEFs and cause a denial of service to all other AFs.
  • a chain of trust between NFs may be leveraged to dynamically register information about AF 102 in NRF 110, for example during onboarding of AF 102.
  • NRF 110 may provide a token retrieval service and if AF 102 requests an access token from CAPIF 106, CAPIF 106 may act as a proxy and forward an access token request to an AccessToken end point of NEF 104, i.e., to NRF 110.
  • duplication of token retrieval function at CAPIF 106 and NRF 110 may be avoided by having a single authorization registry, such as NRF 110.
  • non-trusted 3 rd party AFs such as AF 102
  • a list of identities of NEFs, a list of NEF instance identities or an identity of a set of NEFs may be added to an access token provided to AF 102 and a NEF, such as NEF 104, may verify upon receiving a service request from AF 102 that an identity of the NEF is in the list of identities of NEFs, the list of NEF instance identities or the identity of the set of NEFs corresponds to NEF 104 (i.e., the set comprises NEF 104) and AF 102 is therefore allowed to access services of the NEF. This is necessary to make sure that traffic and QoS of one AF do not influence QoS of another AF, thereby improving QoS handling in communication network 100.
  • the identity token may be provided to AF 102 by NRF 110, e.g., when AF 102 registers with NRF 110.
  • the identity token may be a JWT token.
  • the identity token should be used for all subsequent, i.e., later, communication with NRF 110 through CAPIF 106 AF, such as in access token requests.
  • FIGURE 2 illustrates a first process in accordance with at least some example embodiments.
  • AF 102 On the vertical axes are disposed, from the left to the right, AF 102, NEF 104 comprising CAPIF 106 and AEF 108, and NRF 110. Time advances from the top towards the bottom.
  • AF 102 may be a non-trusted 3 rd party AF.
  • AF 102 may transmit onboarding information to NEF 104, i.e., CAPIF 106 of NEF 104.
  • Said onboarding information may comprise information about AF 102, such as an instance identity, subscriber range and/or communication pattern of AF 102.
  • Said onboarding information may be transmitted in a message such as “PUT/api-invoker-management/vl/onboardedlnvokers (APIInvokerEnrolmentDetails(Aflnfo(Af[nstanceId, SubscriberRange, CommunicationPattem, ...))).
  • NEF 104 i.e., CAPIF 106 of NEF 104
  • NRF 110 may transmit a registration request to NRF 110 upon receiving said onboarding information.
  • the registration request may be transmitted on behalf of AF 102.
  • NRF 110 may receive the registration request associated with AF 102 at step 220.
  • the registration request may comprise said information about AF 102 as well. So CAPIF 106 may register said information about AF 102 (Aflnfo, an Aflnstanceld uniquely defining AF 102 and the field specifying that the registration request is a 3 rd party registration) to NRF 110 on behalf of AF 102.
  • NfProfile may be replaced with AfProfile.
  • NRF 110 may, responsive to receiving the registration request, determine that AF 102 can be registered and consequently register AF 102. NRF 110 may store information about AF 102 as well.
  • NRF 110 may transmit a registration response indicating successful registration to NEF 104, i.e., CAPIF 106 of NEF 104.
  • the registration response may comprise an identity token associated with registration of AF 102, wherein the identity is to be used for all further, subsequent communication with NRF 110 by AF 102.
  • the identity token may be used in subsequent access token requests later on.
  • the identity token may comprise an issuer field (, iss ) indicating that an issuer of the identity token is NRF 110 and a subject field (sub) indicating that a subject of the identity token is AF 102.
  • the identity token may comprise an expiry time (exp) and an issue time (iss). The identity token may not be valid after expiry of the expiry time and the issue time may indicate a time when the identity token was issued.
  • the identity token may be signed by NRF 110, e.g., by using its private key.
  • the identity token may be a JWT token for example and signature of NRF 110 may be used in a 3 rd part of the JWT token in such a case.
  • the JWT token may be a token as defined in the IETF RFC 7519. All the data and the header section of the identity token may be signed by NRF110.
  • NEF 104 i.e. , CAPIF 106 of NEF 104 may transmit an onboarding response to AF 102, the onboarding response comprising the identity token.
  • the onboarding response may be transmitted upon receiving the registration response.
  • the onboarding response may be in the following form: “201 Ok APIInvokerEnrolmentDetails, ((AfInfo(AfInstanceId, SubscriberRange,
  • FIGURE 3 illustrates a second process in accordance with at least some example embodiments.
  • AF 102 On the vertical axes are disposed, from the left to the right, AF 102, NEF 104 comprising CAPIF 106 and AEF 108, and NRF 110. Time advances from the top towards the bottom.
  • AF 102 may be a non-trusted 3 rd party AF.
  • AF 102 may transmit a token retrieval request to NEF 104, i.e., CAPIF 106 of NEF 104.
  • AF 102 may for example contact CAPIF 106 to fetch an OAuth token, to be used for accessing expected services of NEF 104 or some other NEF.
  • the token retrieval request may comprise the identity token.
  • NEF 104 i.e., CAPIF 106 of NEF 104 may forward the token retrieval request, such an OAuth request, of AF 102 to NRF 110.
  • the token retrieval request may comprise the identity token.
  • the token retrieval request may be in the following form: “GET/oauth2/token(AccessTokenReq(Id_token))”.
  • NRF 110 may use the identity token to validate an identity of AF 102 as known. That is to say, NRF 110 may verify the identity token at step 325 responsive to receiving the token retrieval request. NRF would verify the identity token successfully only if the signature in the identity token matches to a signature of NRF 110. Upon successfully verifying the identity token, NRF 110 may generate an access token for AF 102 considering the information (as part of information about AF 102 which was obtained from AF 102 via CAPIF 106 at step 220 of FIGURE 2). The access token may be used for accessing services of NEF 104 or some other NEF in a list of identities of NEFs that the application function is allowed to contact.
  • NRF 110 may transmit an access token response to NEF 104, i.e., CAPIF 106 of NEF 104 upon successful verification of the identity token.
  • NEF 104 i.e., CAPIF 106 of NEF 104
  • the access token response may comprise an access token.
  • the access token may comprise the list of identities of NEFs, the list of NEF instance IDs or the identity of the set of NEFs.
  • AF 102 may be allowed to contact and access services of NEFs that are on the list only.
  • the access token may also comprise at least one subject parameter as defined in IN202041009301.
  • NEF 104 i.e., CAPIF 106 of NEF 104
  • NEF 104 may forward the access token response to AF 102.
  • the access token response may be transmitted from NRF 110 to AF 102 via CAPIF 106 for example.
  • AF 102 may discover AEF end points, for example by using a discovery process defined in 3GPP standard specification T S29.222 (C APIF Disco ver_S ervice API) .
  • AF 102 may transmit a service request to NEF 104, i.e., AEF 108 of NEF 104.
  • the service request may comprise the access token signed by NRF 110. That is to say, AF 102 would use the received access token to request a service from NEF 104, i.e., AEF 108 of NEF 104.
  • NEF 104 i.e., AEF 108 of NEF 104
  • may verify e.g., in accordance with the 3GPP standard specification TS 33.510, section 13.3.2
  • NEF 104 i.e., AEF 108 of NEF 104
  • NEF 104 i.e., AEF 108 of NEF 104
  • NFProfile defined in TS29510_Nnrf_NFManagement.yaml may be modified as below: components: schemas:
  • NFProfile type: object required:
  • AFProfile may be defined in TS29510_Nnrf_NFManagement.yaml as follows:
  • AfProfile type: object required:
  • An identity token may be defined as follows:
  • IdToken type object properties: iss: type: string sub:
  • Nflnstances type: array items:
  • APIInvokerEnrolmentDetails type: object properties: aflnfo:
  • FIGURE 4 illustrates an example apparatus capable of supporting at least some example embodiments. Illustrated is device 400, which may comprise, for example, NEF 104 or NRF 110, or a device controlling functioning thereof.
  • processor 410 which may comprise, for example, a single- or multi-core processor wherein a single-core processor comprises one processing core and a multi-core processor comprises more than one processing core.
  • Processor 410 may comprise, in general, a control device.
  • Processor 410 may comprise more than one processor.
  • Processor 410 may be a control device.
  • Processor 410 may comprise at least one Application-Specific Integrated Circuit, ASIC.
  • Processor 410 may comprise at least one Field-Programmable Gate Array, FPGA.
  • Processor 410 may comprise an Intel Xeon processor for example. Processor 410 may be means for performing method steps in device 400, such as determining, causing transmitting and causing receiving. Processor 410 may be configured, at least in part by computer instructions, to perform actions.
  • a processor may comprise circuitry, or be constituted as circuitry or circuitries, the circuitry or circuitries being configured to perform phases of methods in accordance with example embodiments described herein.
  • circuitry may refer to one or more or all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of hardware circuits and software, such as, as applicable: (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a network function, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.
  • firmware firmware
  • circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware.
  • circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.
  • Device 400 may comprise memory 420.
  • Memory 420 may comprise random- access memory and/or permanent memory.
  • Memory 420 may comprise at least one RAM chip.
  • Memory 420 may comprise solid-state, magnetic, optical and/or holographic memory, for example.
  • Memory 420 may be at least in part accessible to processor 410.
  • Memory 420 may be at least in part comprised in processor 410.
  • Memory 420 may be means for storing information.
  • Memory 420 may comprise computer instructions that processor 410 is configured to execute. When computer instructions configured to cause processor 410 to perform certain actions are stored in memory 420, and device 400 overall is configured to run under the direction of processor 410 using computer instructions from memory 420, processor 410 and/or its at least one processing core may be considered to be configured to perform said certain actions.
  • Memory 420 may be at least in part comprised in processor 410.
  • Memory 420 may be at least in part external to device 400 but accessible to device 400.
  • Device 400 may comprise a transmitter 430.
  • Device 400 may comprise a receiver 440.
  • Transmitter 430 and receiver 440 may be configured to transmit and receive, respectively, information in accordance with at least one cellular standard, such as a standard defined by the 3GPP.
  • Transmitter 430 may comprise more than one transmitter.
  • Receiver 440 may comprise more than one receiver.
  • Transmitter 430 and/or receiver 440 may be configured to operate in accordance with a suitable communication standard.
  • Device 400 may comprise User Interface, UI, 450.
  • UI 450 may comprise at least one of a display, a keyboard, a touchscreen, a vibrator arranged to signal to a user by causing device 400 to vibrate, a speaker and a microphone.
  • a user may be able to operate device 400 via UI 450, for example to configure device 400 and/or functions it runs.
  • Processor 410 may be furnished with a transmitter arranged to output information from processor 410, via electrical leads internal to device 400, to other devices comprised in device 400.
  • Such a transmitter may comprise a serial bus transmitter arranged to, for example, output information via at least one electrical lead to memory 420 for storage therein.
  • the transmitter may comprise a parallel bus transmitter.
  • processor 410 may comprise a receiver arranged to receive information in processor 410, via electrical leads internal to device 400, from other devices comprised in device 400.
  • a receiver may comprise a serial bus receiver arranged to, for example, receive information via at least one electrical lead from receiver 440 for processing in processor 410.
  • the receiver may comprise a parallel bus receiver.
  • Device 400 may comprise further devices not illustrated in FIGURE 4. In some example embodiments, device 400 lacks at least one device described above. For example, device 400 may not have UI 450.
  • Processor 410, memory 420, transmitter 430, receiver 440 and/or UI 450 may be interconnected by electrical leads internal to device 400 in a multitude of different ways.
  • each of the aforementioned devices may be separately connected to a master bus internal to device 400, to allow for the devices to exchange information.
  • this is only one example and depending on the embodiment various ways of interconnecting at least two of the aforementioned devices may be selected without departing from the scope of the present invention.
  • FIGURE 5 is a flow graph of a first method in accordance with at least some example embodiments.
  • the phases of the illustrated first method may be performed by NEF 104, or CAPIF 106 of NEF 104, or by a control device configured to control the functioning thereof, possibly when installed therein.
  • the first method may comprise, at step 510, receiving, by a network exposure function, onboarding information from an application function, said onboarding information comprising information about the application function.
  • the first method may further comprise, at step 520, upon receiving said onboarding information, transmitting by the network exposure function a registration request to a network repository function on behalf of the application function.
  • the first method may comprise, responsive to transmitting the registration request, receiving by the network exposure function a registration response indicating successful registration from the network repository function, the registration response comprising an identity token associated with registration of the application function, wherein the identity token is to be used for all subsequent communication with the network repository function by the application function.
  • the first method may comprise, at step 540, transmitting an onboarding response to the application function, the onboarding response comprising the identity token.
  • FIGURE 6 is a flow graph of a second method in accordance with at least some example embodiments.
  • the phases of the illustrated second method may be performed by NRF 110, or by a control device configured to control the functioning thereof, possibly when installed therein.
  • the second method may comprise, at step 610, receiving, by a network repository function, a registration request from a network exposure function, wherein the registration request is associated with an application function.
  • the second method may also comprise, at step 620, determining, responsive to receiving the registration request, by the network repository function that the application function can be registered and registering the application function.
  • the second method may comprise, at step 630, transmitting a registration response indicating successful registration, wherein the registration response comprises an identity token associated with registration of the application function and the identity token is to be used for all subsequent communication with the network repository function by the application function.
  • an apparatus such as, for example, NEF 104 or NRF 110, or a device controlling functioning thereof, may comprise means for carrying out the example embodiments described above and any combination thereof.
  • a computer program may be configured to cause a method in accordance with the example embodiments described above and any combination thereof.
  • a computer program product embodied on a non-transitory computer readable medium, may be configured to control a processor to perform a process comprising the example embodiments described above and any combination thereof.
  • an apparatus such as, for example, NEF 104 or NRF 110, or a device controlling functioning thereof, may comprise at least one processor, and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to perform the example embodiments described above and any combination thereof.
  • At least some example embodiments find industrial application communication networks, such as in 5G core networks.
  • NEF Network Exposure Function NF Network Function
  • NFP NF Producer NRF Network Repository Function
  • QoS Quality of Service SBA Service-Based Architecture
  • SMF Session Management Function TFS Transport Fayer Security
  • UDM Unified Data Management UDR User Data Repository VNF Virtual Network Function

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

According to an example aspect of the present invention, there is provided a method comprising, receiving, by a network exposure function, onboarding information from an application function, said onboarding information comprising information about the application function, upon receiving said onboarding information, transmitting by the network exposure function a registration request to a network repository function on behalf of the application function, responsive to transmitting the registration request, receiving by the network exposure function a registration response indicating successful registration from the network repository function, the registration response comprising an identity token associated with registration of the application function, wherein the identity token is to be used for all subsequent communication with the network repository function by the application function and transmitting an onboarding response to the application function, the onboarding response comprising the identity token.

Description

ENHANCED REGISTRATION IN COMMUNICATION NETWORKS
FIELD
[0001] Various example embodiments relate in general to communication networks, such as core networks of cellular communication systems, and more specifically, to enhanced registration in such networks.
BACKGROUND
[0002] Registration to services is needed in various communication networks. Registration needs to be enabled for example in core networks of cellular communication systems, such as in 5 G core networks developed by the 3rd Generation Partnership Project, 3GPP. Using 5G as an example, in 5G core networks at least non-trusted 3rd party Application Functions, AFs, should be able to register to some services and improvements are needed for that. Also, in general there is a need to provide improved methods, apparatuses and computer programs for registration in communication networks, such as in 5G core networks, and in other networks in the future as well.
SUMMARY
[0003] According to some aspects, there is provided the subject-matter of the independent claims. Some example embodiments are defined in the dependent claims.
[0004] The scope of protection sought for various example embodiments of the invention is set out by the independent claims. The example embodiments and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various example embodiments of the invention.
[0005] According to a first aspect of the present invention, there is provided a first method comprising, receiving, by a network exposure function, onboarding information from an application function, said onboarding information comprising information about the application function, upon receiving said onboarding information, transmitting by the network exposure function a registration request to a network repository function on behalf of the application function, responsive to transmitting the registration request, receiving by the network exposure function a registration response indicating successful registration from the network repository function, the registration response comprising an identity token associated with registration of the application function, wherein the identity token is to be used for all subsequent communication with the network repository function by the application function and transmitting an onboarding response to the application function, the onboarding response comprising the identity token.
[0006] Example embodiments of the first method may comprise at least one feature from the following bulleted list:
• the registration request comprises a field indicating that the registration request is associated with a registration of a third party;
• the identity token comprises an issuer field indicating that an issuer of the identity token is the network repository function and a subject field indicating that a subject of the identity token is the application function;
• the identity token comprises an expiry time indicating a time after which the identity token will not be valid and an issue time indicating when the identity token was issued;
• the identity token is signed by the network repository function;
• receiving a token retrieval request from the application function, the token retrieval request comprising the identity token, forwarding the token retrieval request of the application function to the network repository function and responsive to forwarding the token retrieval request, receiving from the network repository function an access token response comprising an access token, wherein the access token comprises a list of identities of network exposure functions, a list of network exposure function instance identities or an identity of a set of network exposure functions, wherein the set comprises the network exposure function.
• receiving a service request from the application function, the service request comprising the access token signed by the network repository function, verifying that an identity of the network exposure function is in the list of identities of network exposure functions, the list of network exposure function instance identities or the identity of the set of network exposure functions and transmitting a service response indicating that the service request has been accepted. [0007] According to a second aspect of the present invention, there is provided a second method comprising receiving, by a network repository function, a registration request from a network exposure function, wherein the registration request is associated with an application function; responsive to receiving the registration request, determining by the network repository function that the application function can be registered and registering the application function and transmitting a registration response indicating successful registration, wherein the registration response comprises an identity token associated with registration of the application function and the identity token is to be used for all subsequent communication with the network repository function by the application function.
[0008] Example embodiments of the second method may comprise at least one feature from the following bulleted list:
• the registration request comprises a field indicating that the registration request is associated with a registration of a third party;
• the identity token comprises an issuer field indicating that an issuer of the identity token is the network repository function and a subject field indicating that a subject of the identity token is the application function;
• the identity token comprises an expiry time indicating a time after which the identity token will not be valid and an issue time indicating when the identity token was issued;
• signing, by the network repository function, the identity token;
• receiving, by the network repository function, a token retrieval request of the application function from the network exposure function, the token retrieval request comprising the identity token, responsive to receiving the token retrieval request, verifying the identity token by the network repository function and upon successful verification of the identity token, transmitting to the network exposure function an access token response comprising an access token, wherein the access token comprises a list of network exposure functions, a list of network exposure function instance identities or an identity of a set of network exposure functions, wherein the set comprises the network exposure function.
[0009] Example embodiments of the first or the second method may comprise at least one feature from the following bulleted list: • the application function is a non-trusted third party application function;
• the identity token is to be used in an access token request of the application function;
• the network exposure function and the network repository function operate according to at least one standard specification defined by a 3rd Generation Partnership Project, 3GPP;
• the network exposure function and the network repository function are in a core network of a cellular communication network;
• the core network is a 5G core network.
[0010] According to a third aspect of the present invention, there is provided an apparatus, comprising one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform the first method. The at least one memory and the computer program code may be configured to, with the at least one processing core, cause the apparatus at least to perform, receive, by a network exposure function, onboarding information from an application function, said onboarding information comprising information about the application function, transmit by the network exposure function a registration request to a network repository function on behalf of the application function upon receiving said onboarding information, receive, responsive to transmitting the registration request, by the network exposure function a registration response indicating successful registration from the network repository function, the registration response comprising an identity token associated with registration of the application function, wherein the identity token is to be used for all subsequent communication with the network repository function by the application function and transmit an onboarding response to the application function, the onboarding response comprising the identity token.
[0011] According to a fourth aspect of the present invention, there is provided an apparatus, comprising one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform the second method. The at least one memory and the computer program code may be further configured to, with the at least one processing core, cause the apparatus at least to perform, receive, by a network repository function, a registration request from a network exposure function, wherein the registration request is associated with an application function, determine, responsive to receiving the registration request, by the network repository function that the application function can be registered and registering the application function and transmit a registration response indicating successful registration, wherein the registration response comprises an identity token associated with registration of the application function and the identity token is to be used for all subsequent communication with the network repository function by the application function.
[0012] According to a fifth aspect of the present invention, there is provided an apparatus, comprising means for performing the first method. The apparatus may comprise means for receiving, by a network exposure function, onboarding information from an application function, said onboarding information comprising information about the application function, means for transmitting by the network exposure function a registration request to a network repository function on behalf of the application function upon receiving said onboarding information, means for receiving, responsive to transmitting the registration request, by the network exposure function a registration response indicating successful registration from the network repository function, the registration response comprising an identity token associated with registration of the application function, wherein the identity token is to be used for all subsequent communication with the network repository function by the application function and means for transmitting an onboarding response to the application function, the onboarding response comprising the identity token.
[0013] According to a sixth aspect of the present invention, there is provided an apparatus, comprising means for performing the second method. The apparatus may comprise means for receiving, by a network repository function, a registration request from a network exposure function, wherein the registration request is associated with an application function, means for determining, responsive to receiving the registration request, by the network repository function that the application function can be registered and registering the application function and means for transmitting a registration response indicating successful registration, wherein the registration response comprises an identity token associated with registration of the application function and the identity token is to be used for all subsequent communication with the network repository function by the application function. [0014] According to a seventh aspect of the present invention, there is provided non- transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least perform the method of the first aspect. According to an eighth aspect of the present invention, there is provided non-transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least perform the method of the second aspect.
[0015] According to a ninth aspect of the present invention, there is provided a computer program configured to perform the method of the first aspect. According to a tenth aspect of the present invention, there is provided a computer program configured to perform the method of the second aspect.
BRIEF DESCRIPTION OF THE DRAWINGS [0016] FIGURE 1 illustrates a system in accordance with at least some example embodiments;
[0017] FIGURE 2 illustrates a first process in accordance with at least some example embodiments;
[0018] FIGURE 3 illustrates a second process in accordance with at least some example embodiments; [0019] FIGURE 4 illustrates an example apparatus capable of supporting at least some example embodiments;
[0020] FIGURE 5 illustrates a flow graph of a first method in accordance with at least some example embodiments; and
[0021] FIGURE 6 illustrates a flow graph of a second method in accordance with at least some example embodiments.
EXAMPLE EMBODIMENTS
[0022] The procedures described herein enable registration for example for non- trusted 3rd party Application Functions, AFs, in communication networks, such as in 5G core networks or in other core networks. At least in the case of 5G core networks, the network may comprise a Network Repository Function, NRF, and a Network Exposure Function, NEF. According to some example embodiments of the present invention, registration of a non-trusted 3rd party AF may be enabled by registering information about the non-trusted 3rd party at the NRF during onboarding, with/at a Common Application Programming Interface Framework, CAPIF, for example. The NRF may provide an identity token to the non-trusted 3rd party AF in response to a registration request, wherein the identity token is to be used for all further, subsequent communication with the NRF by the non-trusted 3rd party AF, directly or via the NEF. For instance, the identity token may be used in subsequent access token requests.
[0023] FIGURE 1 illustrates an exemplary network scenario in accordance with at least some example embodiments of the present invention. The exemplary network scenario shown in FIGURE 1 comprises communication network 100, such as a core network of a cellular communication network like 5G network. AF 102 may be located outside of communication network 100, i.e., AF 102 may be a non-trusted AF. North bound interface, Nnef 103, may exist between AF 102 and NEF 104. NEF 104 may be in communication network 100 and further comprise Application Exposure Function, AEF, 106 and CAPIF 108. Moreover, communication network 100 may also comprise NRF 110. In some example embodiments, communication network 100 may further comprise at least one of Access and Mobility Function, AMF 112, User Data Repository, UDR 114, Unified Data Management, UDM 116, and Session Management Function, SMF 118.
[0024] AF 102, NEF 104 and NRF 110 may be Network Functions, NFs. In case of a 3rd Generation Partnership Project, 3GPP, Service-Based Architecture, SBA, of 5G core networks, a NF may refer to an operational and/or a physical entity. An NF may be a specific network node or element, or a specific function or set of functions carried out by one or more entities, such as Virtual Network Functions, VNFs. At least some embodiments of the present invention may be applied in containerized deployments as well. One physical node may be configured to perform functionalities of plural NFs. Examples of such network functions include a (radio) access or resource control or management function, session management or control function, interworking, data management or storage function, authentication function or a combination of one or more of these functions. In some example embodiments, AF 102 may not be a NF though as defined by the 3 GPP. Instead, AF 102 may be a complement to the NF. AF 102 may be a non-trusted 3rd party AF, e.g., for an enterprise.
[0025] AF 102 may be an AF as defined in the 3GPP standard specification TS 29.517. In some example embodiments, OAuth based authorization and token exchange may be applied between NFs. Thus, NRF 110 may be or perform functionalities of an OAuth server. NRF 110 may be an NRF as defined in the 3GPP standard specification TS 29.510, wherein token and management end points of NRFs are defined. In addition, NEF 104, which may expose 3GPP network capabilities to AF 102 via RESTful Application Programming Interfaces, APIs, may be a NEF as defined in the 3GPP standard specification TS 29.522.
[0026] Concerning the chain of trust in communication network 100, dashed line between AF 102 and NEF 104 may demonstrate a trust based on Transport Layer Security, TLS, certificates. For instance, CAPIF 106 may trust AF 102 based on TLS certificates. AF 102 may further trust end points of CAPIF 106 to authorize services provided by AEF 108. As shown in FIGURE 1, NEF 104 may be an entry point to communication network 100 for AF 102 and in general for all AFs.
[0027] Solid lines between NEF 104, NRF 110, AMF 112, UDR 114, UDM 116 and SMF 118 may demonstrate existing trust among core NFs, e.g., due to common root certificates and access tokens provided by NRF 110 for accessing services. NFs such as NRF 110 may trust NEF 104 based on pre-provisioned certificates used for communication. NFs may also register with NRF 110 and use access tokens provided by NRF 110 to provide and request for access of different services. In some example embodiments of the present invention, this chain of trust may be leveraged to allow 3rd party AFs, particularly non- trusted 3rd party AFs, to register themselves in communication network 100, such as a in 5G core network.
[0028] As North bound interface, Nnef 103, may exist between AF 102 and NEF 106, AF 102 would need to contact either CAPIF 106 or NRF 110 to get to an endpoint of NEF 104. On the other hand, CAPIF 106 or NRF 110 should be already aware of AF 102 before providing the endpoint of NEF 104 or granting an access token for AF 102, wherein the access token can be used to access the services of NEF 104 or a NF producer which is associated with NEF 104. [0029] So when NRF 110 must issue an access token based on specific parameters of AF 102, NRF 110 would need to rely on local configurations. Embodiments of the present invention therefore provide network configurability for issuing an access token, instead of local configurations, and registration of AF 102 with NRF 110. In addition, embodiments of the present invention effectively restrict non-trusted 3rd party AFs to access only a certain set of NEFs to access services provided by communication network 100, such as 5G core network, thereby ensuring that AF 102 cannot perform an attack on all the NEFs and cause a denial of service to all other AFs.
[0030] In some example embodiments of the present invention, a chain of trust between NFs may be leveraged to dynamically register information about AF 102 in NRF 110, for example during onboarding of AF 102. NRF 110 may provide a token retrieval service and if AF 102 requests an access token from CAPIF 106, CAPIF 106 may act as a proxy and forward an access token request to an AccessToken end point of NEF 104, i.e., to NRF 110. In some embodiments, duplication of token retrieval function at CAPIF 106 and NRF 110 may be avoided by having a single authorization registry, such as NRF 110.
[0031] Moreover, in some example embodiments, non-trusted 3rd party AFs, such as AF 102, may be enforced to gain entry to communication network 100 only through a certain set of predefined NEFs. For instance, a list of identities of NEFs, a list of NEF instance identities or an identity of a set of NEFs may be added to an access token provided to AF 102 and a NEF, such as NEF 104, may verify upon receiving a service request from AF 102 that an identity of the NEF is in the list of identities of NEFs, the list of NEF instance identities or the identity of the set of NEFs corresponds to NEF 104 (i.e., the set comprises NEF 104) and AF 102 is therefore allowed to access services of the NEF. This is necessary to make sure that traffic and QoS of one AF do not influence QoS of another AF, thereby improving QoS handling in communication network 100.
[0032] The identity token may be provided to AF 102 by NRF 110, e.g., when AF 102 registers with NRF 110. For instance, the identity token may be a JWT token. The identity token should be used for all subsequent, i.e., later, communication with NRF 110 through CAPIF 106 AF, such as in access token requests.
[0033] FIGURE 2 illustrates a first process in accordance with at least some example embodiments. On the vertical axes are disposed, from the left to the right, AF 102, NEF 104 comprising CAPIF 106 and AEF 108, and NRF 110. Time advances from the top towards the bottom. In some embodiments, AF 102 may be a non-trusted 3rd party AF.
[0034] At Step 210, AF 102 may transmit onboarding information to NEF 104, i.e., CAPIF 106 of NEF 104. Thus, AF 102 may register with NRF 110 via CAPIF 106, instead of registering with NRF 110 directly. Said onboarding information may comprise information about AF 102, such as an instance identity, subscriber range and/or communication pattern of AF 102. Said onboarding information may be transmitted in a message such as “PUT/api-invoker-management/vl/onboardedlnvokers (APIInvokerEnrolmentDetails(Aflnfo(Af[nstanceId, SubscriberRange, CommunicationPattem, ...))).
[0035] At step 220, NEF 104, i.e., CAPIF 106 of NEF 104, may transmit a registration request to NRF 110 upon receiving said onboarding information. The registration request may be transmitted on behalf of AF 102. Thus, NRF 110 may receive the registration request associated with AF 102 at step 220. [0036] In some example embodiments, the registration request may be in the following form: “POST nf-instances/{AflnstanceID}, (NfProfile(AfInfo, thirdPartyReg=true))”. That is to say, the registration request may comprise a field indicating that the registration request is associated with a registration of a third party, such as a non- trusted 3rd party AF. The registration request may comprise said information about AF 102 as well. So CAPIF 106 may register said information about AF 102 (Aflnfo, an Aflnstanceld uniquely defining AF 102 and the field specifying that the registration request is a 3rd party registration) to NRF 110 on behalf of AF 102. In some example embodiments, NfProfile may be replaced with AfProfile.
[0037] At step 225, NRF 110 may, responsive to receiving the registration request, determine that AF 102 can be registered and consequently register AF 102. NRF 110 may store information about AF 102 as well.
[0038] At step 230, NRF 110 may transmit a registration response indicating successful registration to NEF 104, i.e., CAPIF 106 of NEF 104. The registration response may comprise an identity token associated with registration of AF 102, wherein the identity is to be used for all further, subsequent communication with NRF 110 by AF 102. For instance, the identity token may be used in subsequent access token requests later on.
[0039] In some example embodiments, the identity token may comprise an issuer field (, iss ) indicating that an issuer of the identity token is NRF 110 and a subject field (sub) indicating that a subject of the identity token is AF 102. Alternatively, or in addition, the identity token may comprise an expiry time (exp) and an issue time (iss). The identity token may not be valid after expiry of the expiry time and the issue time may indicate a time when the identity token was issued.
[0040] The identity token may be signed by NRF 110, e.g., by using its private key. The identity token may be a JWT token for example and signature of NRF 110 may be used in a 3rd part of the JWT token in such a case. The JWT token may be a token as defined in the IETF RFC 7519. All the data and the header section of the identity token may be signed by NRF110.
[0041] In some example embodiments, the registration response may be in the following form: “201 ContextCreated, (NfProfile(AfInfo(Id_token,...), thirdPartyReg=true))”. That is to say, the registration response may comprise a field indicating that the registration response is associated with a registration of a third party as well.
[0042] At step 240, NEF 104, i.e. , CAPIF 106 of NEF 104 may transmit an onboarding response to AF 102, the onboarding response comprising the identity token. The onboarding response may be transmitted upon receiving the registration response. In some example embodiments, the onboarding response may be in the following form: “201 Ok APIInvokerEnrolmentDetails, ((AfInfo(AfInstanceId, SubscriberRange,
CommunicationPattem, Id token,...)))”.
[0043] FIGURE 3 illustrates a second process in accordance with at least some example embodiments. On the vertical axes are disposed, from the left to the right, AF 102, NEF 104 comprising CAPIF 106 and AEF 108, and NRF 110. Time advances from the top towards the bottom. Again, AF 102 may be a non-trusted 3rd party AF.
[0044] At step 310, AF 102 may transmit a token retrieval request to NEF 104, i.e., CAPIF 106 of NEF 104. AF 102 may for example contact CAPIF 106 to fetch an OAuth token, to be used for accessing expected services of NEF 104 or some other NEF. The token retrieval request may comprise the identity token. In some example embodiments, the token retrieval request may be in the following form: “(apiRoot)/capif- security/v 1 /securitis(securityId=Id_token)/token.
[0045] At step 320, NEF 104, i.e., CAPIF 106 of NEF 104 may forward the token retrieval request, such an OAuth request, of AF 102 to NRF 110. The token retrieval request may comprise the identity token. In some example embodiments, the token retrieval request may be in the following form: “GET/oauth2/token(AccessTokenReq(Id_token))”.
[0046] At step 325, NRF 110 may use the identity token to validate an identity of AF 102 as known. That is to say, NRF 110 may verify the identity token at step 325 responsive to receiving the token retrieval request. NRF would verify the identity token successfully only if the signature in the identity token matches to a signature of NRF 110. Upon successfully verifying the identity token, NRF 110 may generate an access token for AF 102 considering the information (as part of information about AF 102 which was obtained from AF 102 via CAPIF 106 at step 220 of FIGURE 2). The access token may be used for accessing services of NEF 104 or some other NEF in a list of identities of NEFs that the application function is allowed to contact.
[0047] At step 330, NRF 110 may transmit an access token response to NEF 104, i.e., CAPIF 106 of NEF 104 upon successful verification of the identity token. Thus, NEF 104, i.e., CAPIF 106 of NEF 104, may receive the access token response responsive to forwarding the token retrieval request. The access token response may comprise an access token. Moreover, the access token may comprise the list of identities of NEFs, the list of NEF instance IDs or the identity of the set of NEFs. AF 102 may be allowed to contact and access services of NEFs that are on the list only. The access token may also comprise at least one subject parameter as defined in IN202041009301.
[0048] At step 340, NEF 104, i.e., CAPIF 106 of NEF 104, may forward the access token response to AF 102. Hence the access token response may be transmitted from NRF 110 to AF 102 via CAPIF 106 for example. At step 345, AF 102 may discover AEF end points, for example by using a discovery process defined in 3GPP standard specification T S29.222 (C APIF Disco ver_S ervice API) . [0049] At step 350, AF 102 may transmit a service request to NEF 104, i.e., AEF 108 of NEF 104. The service request may comprise the access token signed by NRF 110. That is to say, AF 102 would use the received access token to request a service from NEF 104, i.e., AEF 108 of NEF 104.
[0050] At step 355, NEF 104, i.e., AEF 108 of NEF 104, may verify (e.g., in accordance with the 3GPP standard specification TS 33.510, section 13.3.2) that an identity of NEF 104 is in the list of identities of NEFs provided in the access token. If so, NEF 104, i.e., AEF 108 of NEF 104 may transmit a service response indicating that the service request has been accepted at step 360. Additionally, in some example embodiments, NEF 104, i.e., AEF 108 of NEF 104, may apply authorization and perform checks based on the at least one subject parameter as defined in IN202041009301.
[0051] According to some example embodiments of the present invention, some changes may be made to 3GPP standard specification TS 29.510. For instance, NFProfile defined in TS29510_Nnrf_NFManagement.yaml may be modified as below: components: schemas:
NFProfile: type: object required:
- nflnstanceld
- nfType
- nfStatus anyOf:
- required: [ fqdn ]
- required: [ ipv4Addresses ]
- required: [ ipv6Addresses ] properties: aflnfo:
$ref : '#/ components/ schemas/ Aflnfo' Aflnfo: type: array items:
" $ref ' : "/ components/schemas/Subj ectParameter"
[0052] According to some example embodiments of the present invention, if a separate structure is desired, AFProfile may be defined in TS29510_Nnrf_NFManagement.yaml as follows:
AfProfile: type: object required:
- aflnfo properties: aflnfo: $ref: '#/components/schemas/ Aflnfo'
[0053] An identity token may be defined as follows:
IdToken type: object properties: iss: type: string sub:
$ref: 'TS29571_CommonData.yaml#/components/schemas/NflnstanceId' exp:
$ref: 'TS29122_CommonData.yaml#/components/schemas/DurationSec' iat: type: integer required: - iss
- sub
- exp
- iat SubjectParameter: type: object required:
- subjectParameterType
- neflnstances properties: scheduledCommunicationTime:
$ref:
'TS29571_CommonData.yaml#/components/schemas/ScheduledCommunicationTimeRm' userLocation: $ref : TS29571 _CommonData.yaml#/ components/ schemas/UserLocation' supiRanges: type: array items:
$ref : '#/ components/schemas/ SupiRange' minltems: 1 gpsiRanges: type: array items:
$ref : '#/ components/ schemas/IdentityRange' minltems: 1 extemalGroupIdentifiersRanges : type: array items:
$ref : '#/ components/ schemas/IdentityRange' minltems: 1 subj ectParameterType : type: string enum: - USER LOCATION
- TIME OF DAY
- SUPI RANGE
- GPSI RANGE
- EXTERNAL GRP DENTITY RANGE neflnstances: oneOf:
- $ref: '#/components/schemas/NfSetCond'
- $ref: '#/components/schemas/N£Instances'
Nflnstances: type: array items:
$ref: TS2957 l_CommonData.yaml#/components/schemas/NfInstanceId' minltems: 1 idToken: type: string description: JWS Compact Serialized representation of JWS signed JSON object (IdToken) minltems: 1 maxltems: 1 anyOf: - properties: subj ectParameterType : const: USER LOCATION required: - userLocation
- properties: subj ectParameterType : const: TIME OF DAY required:
- scheduledCommunicationTime
- properties: subj ectParameterType : const: SUPI RANGE required:
- supiRanges
- properties: subj ectParameterType : const: GPSI RANGE required:
- gpsiRanges
- properties: subj ectParameterType : const: EXTERN AL GRP DENTITY RAN GE required:
- extemalGroupIdentifiersRanges
[0054] The below additions are proposed to the onboarding data defined in T S29222 C APIF API Invoker Management API .y ami components: schemas:
APIInvokerEnrolmentDetails : type: object properties: aflnfo:
”$ref":
"TS29510_Nnrf_NFManagement.yaml#/components/schemas/SubjectParameter"
[0055] FIGURE 4 illustrates an example apparatus capable of supporting at least some example embodiments. Illustrated is device 400, which may comprise, for example, NEF 104 or NRF 110, or a device controlling functioning thereof. Comprised in device 400 is processor 410, which may comprise, for example, a single- or multi-core processor wherein a single-core processor comprises one processing core and a multi-core processor comprises more than one processing core. Processor 410 may comprise, in general, a control device. Processor 410 may comprise more than one processor. Processor 410 may be a control device. Processor 410 may comprise at least one Application-Specific Integrated Circuit, ASIC. Processor 410 may comprise at least one Field-Programmable Gate Array, FPGA. Processor 410 may comprise an Intel Xeon processor for example. Processor 410 may be means for performing method steps in device 400, such as determining, causing transmitting and causing receiving. Processor 410 may be configured, at least in part by computer instructions, to perform actions.
[0056] A processor may comprise circuitry, or be constituted as circuitry or circuitries, the circuitry or circuitries being configured to perform phases of methods in accordance with example embodiments described herein. As used in this application, the term “circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of hardware circuits and software, such as, as applicable: (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a network function, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation. [0057] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.
[0058] Device 400 may comprise memory 420. Memory 420 may comprise random- access memory and/or permanent memory. Memory 420 may comprise at least one RAM chip. Memory 420 may comprise solid-state, magnetic, optical and/or holographic memory, for example. Memory 420 may be at least in part accessible to processor 410. Memory 420 may be at least in part comprised in processor 410. Memory 420 may be means for storing information. Memory 420 may comprise computer instructions that processor 410 is configured to execute. When computer instructions configured to cause processor 410 to perform certain actions are stored in memory 420, and device 400 overall is configured to run under the direction of processor 410 using computer instructions from memory 420, processor 410 and/or its at least one processing core may be considered to be configured to perform said certain actions. Memory 420 may be at least in part comprised in processor 410. Memory 420 may be at least in part external to device 400 but accessible to device 400.
[0059] Device 400 may comprise a transmitter 430. Device 400 may comprise a receiver 440. Transmitter 430 and receiver 440 may be configured to transmit and receive, respectively, information in accordance with at least one cellular standard, such as a standard defined by the 3GPP. Transmitter 430 may comprise more than one transmitter. Receiver 440 may comprise more than one receiver. Transmitter 430 and/or receiver 440 may be configured to operate in accordance with a suitable communication standard.
[0060] Device 400 may comprise User Interface, UI, 450. UI 450 may comprise at least one of a display, a keyboard, a touchscreen, a vibrator arranged to signal to a user by causing device 400 to vibrate, a speaker and a microphone. A user may be able to operate device 400 via UI 450, for example to configure device 400 and/or functions it runs. [0061] Processor 410 may be furnished with a transmitter arranged to output information from processor 410, via electrical leads internal to device 400, to other devices comprised in device 400. Such a transmitter may comprise a serial bus transmitter arranged to, for example, output information via at least one electrical lead to memory 420 for storage therein. Alternatively to a serial bus, the transmitter may comprise a parallel bus transmitter. Likewise processor 410 may comprise a receiver arranged to receive information in processor 410, via electrical leads internal to device 400, from other devices comprised in device 400. Such a receiver may comprise a serial bus receiver arranged to, for example, receive information via at least one electrical lead from receiver 440 for processing in processor 410. Alternatively to a serial bus, the receiver may comprise a parallel bus receiver.
[0062] Device 400 may comprise further devices not illustrated in FIGURE 4. In some example embodiments, device 400 lacks at least one device described above. For example, device 400 may not have UI 450.
[0063] Processor 410, memory 420, transmitter 430, receiver 440 and/or UI 450 may be interconnected by electrical leads internal to device 400 in a multitude of different ways. For example, each of the aforementioned devices may be separately connected to a master bus internal to device 400, to allow for the devices to exchange information. However, as the skilled person will appreciate, this is only one example and depending on the embodiment various ways of interconnecting at least two of the aforementioned devices may be selected without departing from the scope of the present invention.
[0064] FIGURE 5 is a flow graph of a first method in accordance with at least some example embodiments. The phases of the illustrated first method may be performed by NEF 104, or CAPIF 106 of NEF 104, or by a control device configured to control the functioning thereof, possibly when installed therein.
[0065] The first method may comprise, at step 510, receiving, by a network exposure function, onboarding information from an application function, said onboarding information comprising information about the application function. The first method may further comprise, at step 520, upon receiving said onboarding information, transmitting by the network exposure function a registration request to a network repository function on behalf of the application function. At step 530, the first method may comprise, responsive to transmitting the registration request, receiving by the network exposure function a registration response indicating successful registration from the network repository function, the registration response comprising an identity token associated with registration of the application function, wherein the identity token is to be used for all subsequent communication with the network repository function by the application function. Finally, the first method may comprise, at step 540, transmitting an onboarding response to the application function, the onboarding response comprising the identity token.
[0066] FIGURE 6 is a flow graph of a second method in accordance with at least some example embodiments. The phases of the illustrated second method may be performed by NRF 110, or by a control device configured to control the functioning thereof, possibly when installed therein.
[0067] The second method may comprise, at step 610, receiving, by a network repository function, a registration request from a network exposure function, wherein the registration request is associated with an application function. The second method may also comprise, at step 620, determining, responsive to receiving the registration request, by the network repository function that the application function can be registered and registering the application function. Finally, the second method may comprise, at step 630, transmitting a registration response indicating successful registration, wherein the registration response comprises an identity token associated with registration of the application function and the identity token is to be used for all subsequent communication with the network repository function by the application function.
[0068] It is to be understood that the embodiments disclosed are not limited to the particular structures, process steps, or materials disclosed herein, but are extended to equivalents thereof as would be recognized by those ordinarily skilled in the relevant arts. It should also be understood that terminology employed herein is used for the purpose of describing particular example embodiments only and is not intended to be limiting.
[0069] Reference throughout this specification to one example embodiment or an example embodiment means that a particular feature, structure, or characteristic described in connection with the example embodiment is included in at least one example embodiment. Thus, appearances of the phrases “in one example embodiment” or “in an example embodiment” in various places throughout this specification are not necessarily all referring to the same example embodiment. Where reference is made to a numerical value using a term such as, for example, about or substantially, the exact numerical value is also disclosed.
[0070] As used herein, a plurality of items, structural elements, compositional elements, and/or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, no individual member of such list should be construed as a de facto equivalent of any other member of the same list solely based on their presentation in a common group without indications to the contrary. In addition, various example embodiments and examples may be referred to herein along with alternatives for the various components thereof. It is understood that such example embodiments, examples, and alternatives are not to be construed as de facto equivalents of one another, but are to be considered as separate and autonomous representations.
[0071] In an example embodiment, an apparatus, such as, for example, NEF 104 or NRF 110, or a device controlling functioning thereof, may comprise means for carrying out the example embodiments described above and any combination thereof.
[0072] In an example embodiment, a computer program may be configured to cause a method in accordance with the example embodiments described above and any combination thereof. In an exemplary example embodiment, a computer program product, embodied on a non-transitory computer readable medium, may be configured to control a processor to perform a process comprising the example embodiments described above and any combination thereof.
[0073] In an example embodiment, an apparatus, such as, for example, NEF 104 or NRF 110, or a device controlling functioning thereof, may comprise at least one processor, and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to perform the example embodiments described above and any combination thereof.
[0074] Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more example embodiments. In the preceding description, numerous specific details are provided, such as examples of lengths, widths, shapes, etc., to provide a thorough understanding of example embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
[0075] While the forgoing examples are illustrative of the principles of the example embodiments in one or more particular applications, it will be apparent to those of ordinary skill in the art that numerous modifications in form, usage and details of implementation may be made without the exercise of inventive faculty, and without departing from the principles and concepts of the invention. Accordingly, it is not intended that the invention be limited, except as by the claims set forth below.
[0076] The verbs “to comprise” and “to include” are used in this document as open limitations that neither exclude nor require the existence of also un-recited features. The features recited in depending claims are mutually freely combinable unless otherwise explicitly stated. Furthermore, it is to be understood that the use of "a" or "an", that is, a singular form, throughout this document does not exclude a plurality.
INDUSTRIAL APPLICABILITY
[0077] At least some example embodiments find industrial application communication networks, such as in 5G core networks.
ACRONYMS FIST
3 GPP 3rd Generation Partnership Project AEF Application Exposure Function AF Application Function AMF Access and Mobility Function API Application Programming Interface
CAPIF Common API Framework
NEF Network Exposure Function NF Network Function NFP NF Producer NRF Network Repository Function QoS Quality of Service SBA Service-Based Architecture SMF Session Management Function TFS Transport Fayer Security UDM Unified Data Management UDR User Data Repository VNF Virtual Network Function
REFERENCE SIGNS FIST
Figure imgf000026_0001
Figure imgf000027_0001

Claims

WE CLAIM:
1. A method comprising:
- receiving, by a network exposure function, onboarding information from an application function, said onboarding information comprising information about the application function;
- upon receiving said onboarding information, transmitting by the network exposure function a registration request to a network repository function on behalf of the application function;
- responsive to transmitting the registration request, receiving by the network exposure function a registration response indicating successful registration from the network repository function, the registration response comprising an identity token associated with registration of the application function, wherein the identity token is to be used for all subsequent communication with the network repository function by the application function; and
- transmitting an onboarding response to the application function, the onboarding response comprising the identity token.
2. A method according to claim 1, wherein the registration request comprises a field indicating that the registration request is associated with a registration of a third party.
3. A method according to claim 1 or claim 2, wherein the identity token comprises an issuer field indicating that an issuer of the identity token is the network repository function and a subject field indicating that a subject of the identity token is the application function.
4. A method according to any of the preceding claims, wherein the identity token comprises an expiry time indicating a time after which the identity token will not be valid and an issue time indicating when the identity token was issued.
5. A method according to any of the preceding claims, wherein the identity token is signed by the network repository function.
6. A method according to any of the preceding claims, further comprising:
- receiving a token retrieval request from the application function, the token retrieval request comprising the identity token;
- forwarding the token retrieval request of the application function to the network repository function; and
- responsive to forwarding the token retrieval request, receiving from the network repository function an access token response comprising an access token, wherein the access token comprises a list of identities of network exposure functions, a list of network exposure function instance identities or an identity of a set of network exposure functions, wherein the set comprises the network exposure function.
7. A method according to claim 6, further comprising:
- receiving a service request from the application function, the service request comprising the access token signed by the network repository function;
- verifying that an identity of the network exposure function is in the list of identities of network exposure functions, the list of network exposure function instance identities or the identity of the set of network exposure functions; and
- transmitting a service response indicating that the service request has been accepted.
8. A method comprising:
- receiving, by a network repository function, a registration request from a network exposure function, wherein the registration request is associated with an application function;
- responsive to receiving the registration request, determining by the network repository function that the application function can be registered and registering the application function; and
- transmitting a registration response indicating successful registration, wherein the registration response comprises an identity token associated with registration of the application function and the identity token is to be used for all subsequent communication with the network repository function by the application function.
9. A method according to claim 8, wherein the registration request comprises a field indicating that the registration request is associated with a registration of a third party.
10. A method according to claim 8 or claim 9, wherein the identity token comprises an issuer field indicating that an issuer of the identity token is the network repository function and a subject field indicating that a subject of the identity token is the application function.
11. A method according to any of claims 8 to 10, wherein the identity token comprises an expiry time indicating a time after which the identity token will not be valid and an issue time indicating when the identity token was issued.
12. A method according to any of claims 8 to 11, further comprising:
- signing, by the network repository function, the identity token.
13. A method according to any of claim 8 to 12, further comprising:
- receiving, by the network repository function, a token retrieval request of the application function from the network exposure function, the token retrieval request comprising the identity token;
- responsive to receiving the token retrieval request, verifying the identity token by the network repository function; and
- upon successful verification of the identity token, transmitting to the network exposure function an access token response comprising an access token, wherein the access token comprises a list of network exposure functions, a list of network exposure function instance identities or an identity of a set of network exposure functions, wherein the set comprises the network exposure function.
14. A method according to any of the preceding claims, wherein the application function is a non-trusted third party application function.
15. A method according to any of the preceding claims, wherein the identity token is to be used in an access token request of the application function.
16. A method according to any of the preceding claims, wherein the network exposure function and the network repository function operate according to at least one standard specification defined by a 3rd Generation Partnership Project, 3GPP.
17. A method according to any of the preceding claims, wherein the network exposure function and the network repository function are in a core network of a cellular communication network.
18. A method according to claim 17, wherein the core network is a 5G core network.
19. An apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to perform:
- receive, by a network exposure function, onboarding information from an application function, said onboarding information comprising information about the application function;
- transmit by the network exposure function a registration request to a network repository function on behalf of the application function upon receiving said onboarding information;
- receive, responsive to transmitting the registration request, by the network exposure function a registration response indicating successful registration from the network repository function, the registration response comprising an identity token associated with registration of the application function, wherein the identity token is to be used for all subsequent communication with the network repository function by the application function; and
- transmit an onboarding response to the application function, the onboarding response comprising the identity token.
20. An apparatus according to claim 19, wherein the at least one memory and the computer program code are further configured to, with the at least one processing core, cause the apparatus at least to perform a method according to any of claims 2 - 7 or 14 - 18.
21. An apparatus comprising at least one processing core, at least one memory including computer program code, the at least one memory and the computer program code being configured to, with the at least one processing core, cause the apparatus at least to perform:
- receive, by a network repository function, a registration request from a network exposure function, wherein the registration request is associated with an application function;
- determine, responsive to receiving the registration request, by the network repository function that the application function can be registered and registering the application function; and
- transmit a registration response indicating successful registration, wherein the registration response comprises an identity token associated with registration of the application function and the identity token is to be used for all subsequent communication with the network repository function by the application function.
22. An apparatus according to claim 21, wherein the at least one memory and the computer program code are further configured to, with the at least one processing core, cause the apparatus at least to perform a method according to any of claims 9 - 18.
23. An apparatus comprising:
- means for receiving, by a network exposure function, onboarding information from an application function, said onboarding information comprising information about the application function;
- means for transmitting by the network exposure function a registration request to a network repository function on behalf of the application function upon receiving said onboarding information;
- means for receiving, responsive to transmitting the registration request, by the network exposure function a registration response indicating successful registration from the network repository function, the registration response comprising an identity token associated with registration of the application function, wherein the identity token is to be used for all subsequent communication with the network repository function by the application function; and - means for transmitting an onboarding response to the application function, the onboarding response comprising the identity token.
24. An apparatus according to claim 23, further comprising means for performing a method according to any of claims 2 - 7 or 9 - 18.
25. An apparatus comprising:
- means for receiving, by a network repository function, a registration request from a network exposure function, wherein the registration request is associated with an application function;
- means for determining, responsive to receiving the registration request, by the network repository function that the application function can be registered and registering the application function; and
- means for transmitting a registration response indicating successful registration, wherein the registration response comprises an identity token associated with registration of the application function and the identity token is to be used for all subsequent communication with the network repository function by the application function.
26. An apparatus according to claim 25, further comprising means for performing a method according to any of claims 9 - 18.
27. A non-transitory computer readable medium having stored thereon a set of computer readable instructions that, when executed by at least one processor, cause an apparatus to at least perform a method according to any claims 1 - 7 or 14 - 18, or 8 - 18.
28. A computer program configured to perform a method according to any of claims 1 - 7 or 14 - 18, or 8 - 18.
PCT/FI2021/050290 2020-05-05 2021-04-20 Enhanced registration in communication networks WO2021224545A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN202041019136 2020-05-05
IN202041019136 2020-05-05

Publications (1)

Publication Number Publication Date
WO2021224545A1 true WO2021224545A1 (en) 2021-11-11

Family

ID=78467858

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2021/050290 WO2021224545A1 (en) 2020-05-05 2021-04-20 Enhanced registration in communication networks

Country Status (1)

Country Link
WO (1) WO2021224545A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230179481A1 (en) * 2021-12-02 2023-06-08 Oracle International Corporation Methods, systems, and computer readable media for registering application functions using common application programming interface framework
US11709725B1 (en) 2022-01-19 2023-07-25 Oracle International Corporation Methods, systems, and computer readable media for health checking involving common application programming interface framework

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190251241A1 (en) * 2018-02-15 2019-08-15 Nokia Technologies Oy Security management for service authorization in communication systems with service-based architecture
WO2019194665A1 (en) * 2018-04-06 2019-10-10 Samsung Electronics Co., Ltd. Method and device for performing onboarding
WO2019194242A1 (en) * 2018-04-06 2019-10-10 Nec Corporation Security procedures for common api framework in next generation networks
US20190372962A1 (en) * 2018-05-31 2019-12-05 Oracle International Corporation Single sign-on enabled oauth token

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190251241A1 (en) * 2018-02-15 2019-08-15 Nokia Technologies Oy Security management for service authorization in communication systems with service-based architecture
WO2019194665A1 (en) * 2018-04-06 2019-10-10 Samsung Electronics Co., Ltd. Method and device for performing onboarding
WO2019194242A1 (en) * 2018-04-06 2019-10-10 Nec Corporation Security procedures for common api framework in next generation networks
US20190372962A1 (en) * 2018-05-31 2019-12-05 Oracle International Corporation Single sign-on enabled oauth token

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Functional architecture and information flows to support Common API Framework for 3GPP Northbound APIs; Stage 2 (Release 17)", 3GPP STANDARD; TECHNICAL SPECIFICATION; 3GPP TS 23.222, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG6, no. V17.0.0, 24 March 2020 (2020-03-24), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , pages 1 - 113, XP051861422 *
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security aspects of Common API Framework (CAPIF) for 3GPP northbound APIs (Release 16)", 3GPP STANDARD; TECHNICAL SPECIFICATION; 3GPP TS 33.122, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG3, no. V16.2.0, 31 December 2019 (2019-12-31), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , pages 1 - 30, XP051841007 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230179481A1 (en) * 2021-12-02 2023-06-08 Oracle International Corporation Methods, systems, and computer readable media for registering application functions using common application programming interface framework
US11765030B2 (en) * 2021-12-02 2023-09-19 Oracle International Corporation Methods, systems, and computer readable media for registering application functions using common application programming interface framework
US11709725B1 (en) 2022-01-19 2023-07-25 Oracle International Corporation Methods, systems, and computer readable media for health checking involving common application programming interface framework

Similar Documents

Publication Publication Date Title
CN111213339B (en) Authentication token with client key
TWI668976B (en) Method and device for efficient policy enforcement using network tokens for services-user-plane approach
US8978100B2 (en) Policy-based authentication
US8661257B2 (en) Generic bootstrapping architecture usage with Web applications and Web pages
US10594695B2 (en) Authentication arrangement
JP7411774B2 (en) Techniques for certificate handling in the core network domain
US10986501B2 (en) Secure telephone identity (STI) certificate management system
EP3120591B1 (en) User identifier based device, identity and activity management system
CN110800331A (en) Network verification method, related equipment and system
US11425636B1 (en) Network function service subscription control
US20220191028A1 (en) Authorization of network request
US20220104162A1 (en) Authorization of network node
US20220116400A1 (en) Authorization in communication networks
WO2021224545A1 (en) Enhanced registration in communication networks
WO2021140272A1 (en) Verification of access tokens with network repository functions in core networks
US11503012B1 (en) Client authentication using a client certificate-based identity provider
WO2021099675A1 (en) Mobile network service security management
WO2021165925A1 (en) Key management
WO2021165194A1 (en) Key management
US20230030315A1 (en) Network Security
WO2021224544A1 (en) Registration in communication networks
WO2021079023A1 (en) Inter-mobile network communication security
EP3852339A1 (en) Enabling quality of service for trusted 3rd party network functions in core networks
EP4181465A1 (en) Network security
EP4354798A1 (en) Enhanced security in communication networks

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21800725

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21800725

Country of ref document: EP

Kind code of ref document: A1