Enhanced hop-by-hop security

Abstract

Embodiments of the present disclosure relate to methods, apparatuses and computer readable storage media for hop-by-hop security. One proposed method includes receiving, at a first apparatus and from a second apparatus associated with a first network function, a message directed from the first network function to a second network function, the message including a first signature and network function information, the network function information including at least identification information of the first network function; updating the message with a second signature specific to a traffic communication proxy implemented by the first apparatus based on successful verification of the first signature; and sending the updated message to a third apparatus associated with the second network function, the updated message including at least the second signature and the network function information.

Description

Technical Field

[0001] Embodiments of this disclosure generally relate to the telecommunications field, and more specifically, to apparatus, methods, and computer-readable storage media for enhanced hop-by-hop security. Background Technology

[0002] In 3GPP Release 16 (Rel-16), the Service-Based Architecture (SBA) over the 5G Core Network (5GC) has been extended from direct communication to indirect communication between two Network Functions (NFs). This means that at least one Service Communication Agent (SCP) may be located in the communication path between two NFs. The SCP is an intermediate function that encompasses delegated NF discovery to help resolve target NF producer instances and delegated routing to help route control plane messages between the two NFs.

[0003] In indirect communication, there are no direct connections between NFs. Communication between NFs is protected hop-by-hop. For example, an NF acting as a service consumer (hereinafter referred to as "NF consumer" or "NFc") can establish a secure conduit to an SCP (hereinafter referred to as "SCPc"). C Secure conduits can be established to another SCP (hereinafter referred to as "SCPp"), and SCPp can establish secure conduits to NFs (hereinafter referred to as "NF producers" or "NFp") that act as service producers. This indirect communication between NFs alters and expands the security model of communication. Summary of the Invention

[0004] Typically, exemplary embodiments of this disclosure provide apparatus, methods, and computer-readable storage media for enhanced hop-by-hop security.

[0005] In a first aspect, a first apparatus is provided. The first apparatus includes: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code are configured, together with the at least one processor, to cause the first apparatus to: receive, from a second apparatus associated with a first network function, a message from the first network function to a second network function, the message including a first signature and network function information, the network function information including at least identification information of the first network function; update the message with a second signature of a service communication agent implemented by the first apparatus based on successful verification of the first signature; and send the updated message to a third apparatus associated with the second network function, the updated message including at least the second signature and the network function information.

[0006] In a second aspect, a second apparatus is provided. The second apparatus includes: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code are configured, together with the at least one processor, to enable the second apparatus to: generate a signature based on network function information, the network function information including at least identification information of a first network function, the signature being specific to a first network function implemented by the second apparatus; generate a message from the first network function to a second network function, the message including the signature and the network function information; and send the message to a first apparatus configured to implement a service communication proxy connected to the first network function.

[0007] In a third aspect, a third means is provided. The third means includes: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code are configured, together with the at least one processor, to cause the third means to: receive from a first means configured to implement a service communication agent a message from a first network function to a second network function implemented by the third means; verify a signature in the message specific to the service communication agent, the message further including network function information, the network function information including at least identification information of the first network function; and, based on successful verification of the signature, obtain the identification information of the first network function from the message.

[0008] In a fourth aspect, a method is provided. The method includes: receiving, at a first device and from a second device associated with a first network function, a message pointing from the first network function to a second network function, the message including a first signature and network function information, the network function information including at least identification information of the first network function; updating the message with a second signature of a service communication agent implemented by the first device based on successful verification of the first signature; and sending the updated message to a third device associated with the second network function, the updated message including at least the second signature and the network function information.

[0009] In a fifth aspect, a method is provided. The method includes: generating a signature at a second device based on network function information, the network function information including at least identification information of a first network function, the signature being specific to a first network function implemented by the second device; generating a message pointing from the first network function to a second network function, the message including the signature and the network function information; and sending the message to a first device configured to implement a service communication proxy connected to the first network function.

[0010] In a sixth aspect, a method is provided. The method includes: receiving, at a third device and from a first device configured to implement a service communication proxy, a message from a first network function to a second network function implemented by the third device; verifying a service communication proxy-specific signature in the message, the message further including network function information, the network function information including at least identification information of the first network function; and obtaining the identification information of the first network function from the message based on successful verification of the signature.

[0011] In a seventh aspect, a first apparatus is provided, the first apparatus comprising: a module for receiving a message from a second apparatus associated with a first network function, the message including a first signature and network function information, the network function information including at least identification information of the first network function; a module for updating the message with a second signature of a service communication agent implemented by the first apparatus based on successful verification of the first signature; and a module for sending the updated message to a third apparatus associated with the second network function, the updated message including at least the second signature and the network function information.

[0012] In an eighth aspect, a second apparatus is provided, the second apparatus comprising: a module for generating a signature based on network function information, the network function information including at least identification information of a first network function, the signature being specific to a first network function implemented by the second apparatus; a module for generating a message from the first network function to a second network function, the message including the signature and the network function information; and a module for sending the message to a first apparatus configured to implement a service communication proxy connected to the first network function.

[0013] In a ninth aspect, a third apparatus is provided, the third apparatus comprising: a module for receiving from a first apparatus configured to implement a service communication proxy a message from a first network function to a second network function implemented by the third apparatus; a module for verifying a signature in the message specific to the service communication proxy, the message further comprising network function information, the network function information including at least identification information of the first network function; and a module for obtaining the identification information of the first network function from the message based on successful verification of the signature.

[0014] In a tenth aspect, a non-transitory computer-readable medium is provided, comprising program instructions for causing a device to at least execute the method according to the fourth aspect above.

[0015] In an eleventh aspect, a non-transitory computer-readable medium is provided, comprising program instructions for causing a device to at least execute the method according to the fifth aspect above.

[0016] In a twelfth aspect, a non-transitory computer-readable medium is provided, comprising program instructions for causing a device to at least execute the method according to the sixth aspect above.

[0017] It should be understood that the summary section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0018] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of some exemplary embodiments of the present disclosure in the accompanying drawings, in which:

[0019] Figure 1 A block diagram is shown of an example environment in which some example embodiments of the present disclosure may be implemented;

[0020] Figure 2 An interactive diagram illustrating an example process for hop-by-hop security in indirect communication according to some example embodiments of the present disclosure is shown;

[0021] Figure 3 A schematic diagram illustrating an example header during indirect communication is shown, according to some example embodiments of the present disclosure;

[0022] Figure 4 An interactive diagram illustrating an example process for end-to-end authentication in indirect communication according to some example embodiments of the present disclosure is shown;

[0023] Figure 5 A schematic diagram illustrating an example header during indirect communication is shown, according to some example embodiments of the present disclosure;

[0024] Figure 6 A flowchart of an example method according to some example embodiments of this disclosure is shown;

[0025] Figure 7 A flowchart of an example method according to some example embodiments of this disclosure is shown;

[0026] Figure 8 A flowchart of an example method according to some example embodiments of this disclosure is shown;

[0027] Figure 9 A simplified block diagram of an apparatus suitable for implementing embodiments of the present disclosure is shown; and

[0028] Figure 10A block diagram of an example computer-readable medium according to some example embodiments of the present disclosure is shown.

[0029] In all the accompanying drawings, the same or similar reference numerals denote the same or similar elements. Detailed Implementation

[0030] The principles of this disclosure will now be described with reference to some exemplary embodiments. It should be understood that the description of these embodiments is for illustrative purposes only and to assist those skilled in the art in understanding and implementing this disclosure, and does not impose any limitation on the scope of this disclosure. This disclosure described herein can be implemented in various ways besides those described below.

[0031] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0032] References to "an embodiment," "embodiment," "example embodiment," etc., in this disclosure indicate that the described embodiment may include a specific feature, structure, or characteristic, but not every embodiment necessarily includes that specific feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Additionally, when a specific feature, structure, or characteristic is described in connection with an embodiment, it is assumed that implementing such a feature, structure, or characteristic in conjunction with other embodiments is within the knowledge of those skilled in the art, whether explicitly described or not.

[0033] It should be understood that although the terms “first” and “second” may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, without departing from the scope of the exemplary embodiments, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0034] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that, when used herein, the terms “comprising,” “including,” “having,” and / or “containing” specify the presence of stated features, elements, and / or components, etc., but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.

[0035] As used in this application, the term "circuit" may refer to one or more of the following:

[0036] (a) Pure hardware circuit implementations (e.g., implementations in analog and / or digital circuits only) and

[0037] (b) A combination of hardware circuitry and software, such as (if applicable):

[0038] (i) A combination of analog and / or digital hardware circuitry with software / firmware, and

[0039] (ii) Any part of a hardware processor (including a digital signal processor) with software, software, and memory, which work together to enable a device such as a mobile phone or server to perform various functions, and

[0040] (c) Hardware circuitry and / or processor (e.g., microprocessor or part of a microprocessor) that requires software (e.g. firmware) for operation, but the software may not exist when it is not required for operation.

[0041] This definition of "circuit" applies to all uses of the term in this application (including in any claim). As another example, as used in this application, the term "circuit" also covers only implementations of hardware circuits or processors and their accompanying software and / or firmware. For example, where applicable to a particular claim element, the term "circuit" also covers baseband integrated circuits for mobile devices or similar integrated circuits in servers, cellular network devices, or other computing or network devices.

[0042] As used herein, the term "communication network" refers to a network that conforms to any suitable communication standard, such as Long Term Evolution (LTE), LTE-A Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed ​​Packet Access (HSPA), Narrowband Internet of Things (NB-IoT), New Radio (NR), etc. Furthermore, communication between terminal devices and network devices in a communication network can be performed according to any suitable generation of communication protocol (including but not limited to first-generation (1G), second-generation (2G), 2.5G, 2.75G, third-generation (3G), fourth-generation (4G), 4.5G, future fifth-generation (5G) communication protocols, and / or any other currently known or to be developed in the future). Embodiments of this disclosure can be applied to a variety of communication systems. Given the rapid development of communications, there will certainly be future types of communication technologies and systems that embody the future types of this disclosure. The scope of this disclosure should not be limited to the systems described above only.

[0043] As mentioned above, in 5GC SBA, communication between NFs is protected under hop-by-hop security based on a transitive trust model (e.g., A trusts B, C trusts B, therefore C trusts A). While this model may be sufficient in statically configured, physically isolated, and point-to-point 4G networks, it is insufficient in 5GC, which is entirely cloud-native and where virtualized NFs share hardware with other NFs and there is no physical isolation between NFs. Therefore, a mechanism is needed that enables the receiving NF to reliably authenticate the sending NF within the virtualized network.

[0044] Embodiments of this disclosure provide a solution for hop-by-hop security. In this solution, a sending NF (e.g., NFc) can send a message (e.g., a service request) to a receiving NF (e.g., NFp) for a first SCP (e.g., SCPc). The message may include a signature specific to the sending NF and network function information of the sending NF. The network function information may include an identifier of the sending NF (e.g., the NF instance ID of the sending NF) and may also include time information (e.g., a timestamp) related to the transmission of the message. In some example embodiments, the network function information may further include certificate information of the sending NF specific to the private key used in generating the signature. After successfully verifying the signature specific to the sending NF, the first SCP can update the message by replacing the signature of the sending NF with its own signature or inserting its own signature into the message. In the case of replacing the signature of the sending NF, the network function information (e.g., including identification information, time information, etc.) is digitally signed to generate the signature of the first SCP. When inserting a signature for the first SCP, the network function information (e.g., including identification information, time information, and certificate information) and the signature of the sending NF are digitally signed to generate the signature for the first SCP; alternatively, only the signature of the sending NF is digitally signed.

[0045] The first SCP then sends the updated message to the second SCP (e.g., SCPp). After successfully verifying the first SCP's signature, the second SCP can further update the message by replacing the first SCP's signature with its own. The second SCP can then send the further updated message to the receiving NF. After successfully verifying the second SCP's signature, the receiving NF can obtain the sending NF's identification information. If the receiving message contains the sending NF's signature, the receiving NF will also verify the sending NF's signature. In some example embodiments, the signature and network function information can be carried in a header inserted into the message.

[0046] In another scenario, the sending NF and the receiving NF can communicate directly (i.e., there is no SCP between them), such as in the case of a notification message from an NF producer to an NF consumer. In this case, the receiving NF verifies the signature of the sending NF.

[0047] In the proposed solution, the addition of signature and network functions (e.g., a specially customized header for NF instances) and related modifications at intermediate nodes (e.g., first and second SCPs) enable the receiving NF to reliably determine the identifier of the sending NF (e.g., NF instance ID, fully qualified domain name (FQDN), etc.). The proposed solution does not violate Rel-15 and is backward compatible, thus also working across networks.

[0048] Now for reference Figure 1 It shows a block diagram of an environment 100 in which some example embodiments of the present disclosure may be implemented. Figure 1 An example environment 100 for indirect communication scenarios is shown.

[0049] like Figure 1 As shown, environment 100 includes NFs 110 and 120, SCP 130 connected to NF 110, and SCP 140 connected to NF 120. SCPs 130 and 140 can be implemented in the same physical device or different physical devices. NFs 110 and 120 can be implemented in the same physical device or different physical devices. In some example embodiments, NFs 110 and 120, SCPs 130 and 140, and other components can be implemented at the same node. For example, the SCP can be located in the same location as a Network Repository Function (NRF), and the SCP (instance) can also be located in the same location as a Security Edge Protection Agent (SEPP). In some example embodiments, NFs 110 and 120, SCPs 130 and 140, and one or more of the NRF, SEPP, etc., can be run as a service by a third party, and therefore messages can be routed to and from the third party.

[0050] For illustrative purposes only, NF 110 may also be referred to as "First NF 110" and NF 120 may also be referred to as "Second NF 120" hereinafter. SCP 130 connected to First NF 110 may also be referred to as "First SCP 130" and SCP 140 connected to Second NF 120 may also be referred to as "Second SCP 140". In some example embodiments, NF 110 may act as a service consumer, requesting services from NF 120, which acts as a service producer. In such example embodiments, First NF 110 may be referred to as "NFc 110" and Second NF 120 may also be referred to as "NFp 120". Therefore, First SCP 130 connected to NFc 110 may be referred to as "SCPc 130" and Second SCP 140 connected to NFp 120 may also be referred to as "SCPp 140".

[0051] like Figure 1 As shown, the first NF 110 and the second NF 120 are not directly connected to each other. SCPs 130 and 140 act as intermediate nodes between NF110 and NF 120. It should be understood that... Figure 1 The number of SCPs shown is for illustrative purposes only and is not a limitation; fewer or more SCPs may exist between NF110 and 120. In some example embodiments, there may be only one SCP between NF110 and 120. For example, in the case where the first NF 110 acts as an NF service consumer requesting services from the second NF 120 (i.e., NRF), both NFs 110 and 120 may be connected to the same SCP. In some example embodiments, there may be more than two SCPs between NFs 110 and 120.

[0052] It should be understood that network environment 100 is shown for illustrative purposes only and does not imply any limitation on the scope of this disclosure. Embodiments of this disclosure can also be applied to environments with different architectures.

[0053] Figure 2 An interactive diagram of an example process 200 for hop-by-hop security in indirect communication, according to some example embodiments of this disclosure, is shown. Figure 2 As shown, process 200 may involve, for example, Figure 1 The images show NF 110, SCP 130, SCP 140, and NF 120.

[0054] It should be understood that although process 200 (and process 400 described below) involves NF 110, SCP 130 and SCP 140, and NF 120, such as hop-by-hop security between “NFc->SCPc->SCPp->NFp”, the same mechanism can also be used in other communication directions or scenarios. For example, the mechanism can be used in the direction from “NFp” to “NFc”, and then, for example, allow NFc to verify the NFp identifier used for the callback URI. Furthermore, the mechanism can potentially be used in scenarios of “NFc->SCPc->NRF” and scenarios of “NRF1->NRF2->NRF3”. For example, when routing Nnrf service application programming interface (API) requests through one or more intermediate forwarding NRFs, the mechanism can be used to verify the identifier of NFc through hierarchical NRF settings, and also to identify NRFs to each other in this case. Therefore, in some example embodiments, the receiving NF can be an NRF.

[0055] In some example embodiments, as premise for the detailed procedures described below, mutual authentication is performed between NF 110 and SCP 130 (step 201), between SCP 130 and SCP 140 (step 202), and between NF 120 and SCP 140 (step 203). For example, a Transport Layer Security (TLS) handshake process can be performed for mutual authentication. This allows the establishment of secure connections using TLS (hereinafter also referred to as “TLS connections”) between NF 110 and SCP 130, between SCP 130 and SCP 140, and between SCP 140 and NF 120. For example, during the TLS handshake between NF 110 and SCP 130, the client certificate of NF 110 can be provided or indicated to SCP 130. SCP 140 and NF 120 can then obtain their respective client certificates. In the example procedures of this disclosure, the TLS handshake certificates can be used to bind the lower transport layer to the upper application layer, thereby providing better security.

[0056] First NF 110 may intend to send a message to second NF 120. In this document, such a message can be referred to as a message from first NF 110 to second NF 120. For example, if first NF 110 acts as NFc and second NF 120 acts as NFp, such a message could be a service request. If first NF 110 acts as NFp and second NF 120 acts as NFc, such a message could be a notification message. Figure 2 In the example shown, the first NF 110 can also be referred to as the transmitting NF 110, and the second NF 120 can also be referred to as the receiving NF 120.

[0057] To support enhanced hop-by-hop security, a signature and network function information (NF information) for sending NF 110 can be inserted into the message pointing to receiving NF 120. The NF information includes at least identification information for sending NF 110, which can be used to identify the NF instance sending NF 110. In some example embodiments, this identification information can be the NFInstanceId of sending NF 110, the NF Set ID (if the set to which sending NF 110 belongs), or both. NFInstanceId can represent an identifier provided by the NF, which should be globally unique within the Public Land Mobile Network (PLMN) of the NRF to which the NF is registered. The NFSet ID is a globally unique set of equivalent and interchangeable CP NFs from a given network, providing distribution, redundancy, and scalability.

[0058] In some example embodiments, for replay protection purposes, the NF information may also include time information related to the transmission of the message. As an example, a timestamp based on RFC 7321 or RFC 3161 may be added as time information. In some example embodiments, in addition to adding a timestamp, the sending NF 110 may also add delay information, such as "AcceptableDelay," which provides guidance to the receiving NF 120 regarding what is considered a valid time window. In some example embodiments, alternatively, the receiving NF 120 may determine an acceptable time window based on estimates such as hop-by-hop delay. In some example embodiments, the NF information may further include type information of the sending NF 110 and certificate information of the sending NF 110, which will be referenced below. Figure 4 and 5 Provide a detailed description.

[0059] Sending NF 110 generates a 205 signature. For example, sending NF 110 can generate a signature based on the NF information to be sent and the private key used to send NF 110. This digital signature can be generated using the private key corresponding to the public key in the TLS certificate. Alternatively, the operator can provide a new certificate to generate the digital signature. Furthermore, this means that the new certificate is available to all entities that need to verify the signature.

[0060] Then, sending NF 110 can generate a message including NF information and a signature specific to sending NF 110. This message (e.g., a service request) is sent to 210 or forwarded to the first SCP 130, with sending NF 110 communicating with the first SCP 130 and having established a secure TLS-based connection.

[0061] NF information and signatures can be sent in the header inserted into the message (e.g., a service request). See now. Figure 3 , Figure 3 A schematic diagram 300 illustrates an example header during indirect communication according to some example embodiments of the present disclosure. In this example, a sample HTTP custom header 310 (hereinafter referred to as the header) named "3gpp-Sbi-SendingNFInfo" may be inserted by sending NF 110, where Sbi is an abbreviation for a service-based interface. Furthermore, in this example, sending NF 110 acts as NFc, and the message sent 210 is a service request.

[0062] The “NFInstanceInfo” field 311 represents identification information, which in this example is the NFInstanceId of NFC 110. The “Timestamp” field 312 represents time information. The “Signature” field 313 of the header 310 contains a signature appended by the sending NF 110 to the “NFInstanceInfo” and “Timestamp”. The signature in the “Signature” field 313 can be generated by signing the content or a digest of the content of the “NFInstanceInfo” and “Timestamp” using the private key of the sending NF 110 (which is shown as “PrNFc” in the example). It should be understood that the signature in the “Signature” field 313 is merely an example and is not limiting. For example, if the sending NF is NFp, the private key of NFp (e.g., PrNFp) can be used for signing purposes.

[0063] Despite Figure 3 The algorithm used to generate the signature is not shown, but it can also be included in header 310, for example, in the "Algorithm" field. Such a header or a similar header can also be referred to as a Secure Hypertext Transfer Protocol (HTTP) header.

[0064] It should be understood that Figure 3 The “3gpp-Sbi-SendingNFInfo” header shown is merely exemplary and is not limiting. Other headers, such as “Forwarded” as defined in RFC 7239, may be used.

[0065] In some example embodiments, as described above, the NF information may include type information for sending NF 110, such as the NF type. Sending NF 110 may also be included in "3GPP-SBI-Sending". NFThe NF type is sent in the "Info header" 310. The NF type can be sent in the "NFInstanceInfo" field 311 of header 310 or in an additional field.

[0066] In the “3gpp-Sbi-SendingNFInfo” header 310, the “Timestamp” field 312 is used. Alternatively, the existing “3gpp-Sbi-Sender-Timestamp” header (e.g., as defined in Section 5.2.3.3.2 of TS29.500) can be used to carry time information. In this case, sending NF 110 can add two headers: a “3gpp-Sbi-SendingNFInfo” header including identification information such as NFInstanceInfo (and optional certificate information for end-to-end authentication, as described below) and a “3gpp-Sbi-Sender-Timestamp” header. Furthermore, in this case, a signature can be included, such as... Figure 3 The “3gpp-Sbi-SendingNFInfo” header shown may be included in a separate header.

[0067] In the exemplary embodiments of this disclosure, signatures and various types of NF information, such as identification information, time information, NF type information, and certificate information, can all be sent in the same header or in different headers. Signatures and various types of NF information can also be sent in the message in forms other than headers.

[0068] Now for reference Figure 2 The first SCP 130 connected to the sending NF 110 can perform the discovery, selection, and access token request process 215. After receiving a message from the sending NF 110, the first SCP 130 verifies the signature in the message 220. For example, the first SCP 130 can use the public key of the sending NF 110, which is available in a TLS client certificate provided by the sending NF 110 during the TLS handshake, to verify the signature in the HTTP header. Alternatively, if the signature is generated based on a new certificate, the public key available in the new certificate can be used. Figure 3 As shown in the example, the signature in the “Signature” field 313 can be verified by the first SCP 130 (which is SCPc in this case).

[0069] If the signature is successfully verified, SCP 130 updates message 225. SCP 130 then sends the updated message to 230 or forwards it to SCP 140, with SCP 130 having already established a mutually authenticated TLS connection with SCP 140.

[0070] In some example embodiments, to update the message, the first SCP 130 can generate its own signature and replace the signature of the sending NF 110 in the message (e.g., in the HTTP header) with its own signature. Reference Figure 3 Compared to example header 310, example header 320 in the updated message has changed. The “NFInstanceInfo” field 311 and the “Timestamp” field 312 remain unchanged. In the “Signature” field 323, the signature of NF 110 is replaced by the signature of the first SCP 130. In this example, the signature in the “Signature” field 323 can be generated by signing the content or a digest of the content of “NFInstanceInfo” and “Timestamp” with the private key of the first SCP 130 (which is shown as “PrSCPc” in the example).

[0071] Still referencing Figure 2 After receiving the updated message from the first SCP 130, the second SCP 140 verifies the signature in the updated message 235, which is the signature of the first SCP 130. The second SCP 140 can verify the signature in the HTTP header using the public key of the first SCP 130, which is available in the TLS client certificate (provided by the first SCP 130 during the TLS handshake). Figure 3 As shown in the example, the signature in the “Signature” field 323 can be verified by the second SCP 140 (which is SCPp in this case).

[0072] If the signature is successfully verified, the second SCP 140 further updates the message 240. The second SCP 140 then sends or forwards the further updated message to the receiving NF 120, with which the second SCP 140 has established a mutually authenticated TLS connection. In the case of a service request, the receiving NF 120 can act as an NFp, or in the case of a notification message, it can act as an NFc.

[0073] In some example embodiments, to update the message, the second SCP 140 can generate its own signature and replace the signature of the first SCP 130 in the message (e.g., in the HTTP header) with its own signature. Reference Figure 3Compared to example header 320, example header 330 in the further updated message has changed. The “NFInstanceInfo” field 311 and the “Timestamp” field 312 remain unchanged. In the “Signature” field 333, the signature of the first SCP 130 has been replaced by the signature of the second SCP 140. In this example, the signature in the “Signature” field 333 can be generated by signing the content or a digest of the “NFInstanceInfo” and “Timestamp” using the private key of the second SCP 140 (which is shown as “PrSCPp” in the example).

[0074] Still referencing Figure 2 After receiving a further updated message from the second SCP 140, the receiving NF 120 verifies the signature in the further updated message, i.e., the signature of the second SCP 140. The receiving NF 120 can verify the signature in the HTTP header using the public key of the second SCP 140, which is available in the TLS client certificate (which was provided by the second SCP 140 during the TLS handshake). Figure 3 As shown in the example, the signature in the “Signature” field 333 can be verified by the receiving NF 120 (which is NFp in this case).

[0075] In some example embodiments where the NF information includes time information, if the signature is successfully verified, the receiving NF 120 can perform a 255-time-window verification based at least in part on the time information. For example, if the message includes a timestamp, the receiving NF 120 can verify that the timestamp is within a certain time window, such as an acceptable time window. In such example embodiments, replay protection can be implemented. It should be understood that if the timestamp is still valid, but the certificate originally used for signing has expired or been revoked, the message (e.g., a service request) will no longer be valid / acceptable.

[0076] As described above, in some example embodiments, the time information may further include delay information, such as "AcceptableDelay". In such example embodiments, the receiving NF 120 may determine the effective time window based on the delay information. In some example embodiments, alternatively, the receiving NF 120 may determine the effective time window based on an estimate of hop-by-hop delay, etc.

[0077] After successfully verifying the signature and optional time information, the receiving NF retrieves the identification information of the sending NF 110 from the message received from the second SCP 140. For example, the receiving NF 120 can obtain this information from the header (e.g., Figure 3The header 330 shown in the figure obtains the NF Instance Id, NF Set Id, or FQDN of the NF 110 being sent.

[0078] Example procedure 200 is described regarding a configuration where two SCPs exist between two communicating NFs. It should be understood that the solution disclosed herein can also be applied to configurations where both the sending and receiving NFs are connected to the same SCP. In such a configuration, the SCP forwards updated messages to the receiving NF. An example of this scenario is when NFc requests service from NRF. Both NFc and NRF can be connected to the same SCP.

[0079] In some example embodiments, end-to-end (e2e) authentication can be enabled between two communicating NFs. This is useful when end-to-end authentication is required between two NFs for critical service operations. The solution disclosed herein can provide additional features of end-to-end authentication.

[0080] When e2e authentication is enabled, for example, the signature of the sending NF in the "Signature" field is forwarded end-to-end and verified by the receiving NF. This requires the receiving NF to have access to the sending NF's public key. Therefore, the sending NF's certificate information needs to be carried in the message from the sending NF to the receiving NF. For example, an additional "Cert" field can be used to carry the sending NF's certificate, such as a TLS certificate or a new certificate (if provided by the operator). The certificate (TLS certificate or newly provided certificate) is carried end-to-end and is available to the receiving NF. One or more intermediate nodes (such as SCPs) can append their signatures to the message, for example, in a new field called "SCP Signature". Similarly, when e2e authentication is enabled, the sending NF can be an NFC, or an NFp or NRF used to callback Uniform Resource Identifiers (URIs) or other notifications.

[0081] Therefore, in example implementations that enable end-to-end authentication, two additional fields may be required. Two example fields in the header, "Cert" and "SCP Signature," are shown below:

[0082] a) "Cert": <TLS certificate for sending NF> / / Added by sending NF or SCP connected to sending NF;

[0083] b) "SCP Signature": SIGN[3gpp-Sbi-SendingNFInfoNFInstanceInfo+Timestamp] SCP's private key.

[0084] Now for reference Figure 4This illustrates an interactive diagram of an example process 400 for e2e authentication in indirect communication according to some example embodiments of this disclosure. For example... Figure 4 As shown, process 400 may involve, for example... Figure 1 The images show NF 110, SCP 130, SCP 140, and NF 120.

[0085] Similar to a reference Figure 2 As described, in some example embodiments, as a prerequisite, mutual authentication 401 is performed between NF 110 and SCP 130, mutual authentication 402 is performed between SCP 130 and SCP 140, and then mutual authentication 403 is performed between NF 120 and SCP 140. For example, a TLS handshake process can be performed for mutual authentication. Such a process is consistent with the references... Figure 2 The process described is similar and will not be repeated here.

[0086] Sending NF 110 can be intended to send a message to receiving NF 120. For example, in the case where sending NF 110 acts as NFC and receiving NF 120 acts as NFp, such a message could be a service request.

[0087] The signature and NFinfo of the sending NF 110 can be inserted into the message pointing to the receiving NF 120. To enable e2e authentication, in addition to the identification and time information as described above, for example, the certificate information of the sending NF 110 needs to be included as part of the NF information. In some example embodiments, the sending NF 110 itself can insert the certificate information of the sending NF 110 into the message pointing to the receiving NF 120. In this case, the NF information can include at least the identification information and the certificate information of the sending NF 110, and may also include time information.

[0088] Sending NF 110 generates a 405 signature. For example, sending NF 110 can generate a signature based on the NF information to be sent and the private key used to send NF 110. This digital signature can be generated using the private key corresponding to the public key in the TLS certificate. Alternatively, the operator can provide a new certificate to generate the digital signature. Furthermore, this means that the new certificate is made available to all entities that need to verify the signature.

[0089] Then, sending NF 110 can generate a message including NF information and a signature specific to sending NF 110. The message (e.g., a service request) is sent to 410 or forwarded to the first SCP 130, with sending NF 110 communicating with the first SCP 130 and having established a secure TLS-based connection.

[0090] Similar to the above, NF information and signatures can be sent in the header inserted into the message. Now refer to... Figure 5 , Figure 5 A schematic diagram 500 is shown illustrating an example header during indirect communication according to some example embodiments of the present disclosure. In this example, an example header 510 named "3gpp-Sbi-SendingNFInfo" may be inserted by sending NF 110. Furthermore, in this example, sending NF 110 acts as NFc, and the message sent 210 is a service request.

[0091] The “NFInstanceInfo” field 511 and the “Timestamp” field 512 are related to... Figure 3 The “NFInstanceInfo” field 311 and the “Timestamp” field 312 are described similarly, and their descriptions will not be repeated here. The “Cert” field 513 represents certificate information. In this example, the “Cert” field 513 is shown as containing the client certificate that sent NF 110, i.e., “Client Certificate of NFc”.

[0092] The “Signature” field 514 of header 510 contains the signature appended by the sender NF 110 for “NFInstanceInfo”, “Timestamp”, and “Cert”. The signature in the “Signature” field 514 can be generated by signing the content or a digest of the content of “NFInstanceInfo”, “Timestamp”, and “Cert” using the private key of the sender NF 110 (which is shown as “PrNFc” in the example). Although in Figure 5 The algorithm used to generate the signature is not shown, but it can also be included in header 510, for example, in the "Algorithm" field. Such a header or similar headers can also be referred to as an HTTP header.

[0093] It should be understood that the above is for reference only. Figure 3 Other aspects described can also be applied to process 400.

[0094] Now for reference Figure 4 The first SCP 130 connected to sender NF 110 can perform the 415 Discover, Select, and Access Token Request procedure. After receiving a message from sender NF 110, the first SCP 130 verifies the signature in the 420 message. The first SCP 130 can verify the signature in the HTTP header using the public key of sender NF 110, which is available in the TLS client certificate (provided by sender NF 110 during the TLS handshake). For Figure 4As shown in the example, the signature in the “Signature” field 514 can be verified by the first SCP 130 (SCPc in this case).

[0095] If the signature is successfully verified, SCP 130 updates message 430. SCP 130 then sends the updated message to 435 or forwards it to SCP 140, establishing a mutually authenticated TLS connection between SCP 130 and SCP 140.

[0096] In such an example embodiment with e2e authentication enabled, in order to update a message, the first SCP 130 can generate its own signature (which may be referred to below as an SCP signature) and add the SCP signature to the message (e.g., in the HTTP header). Reference Figure 5 Compared to the example header 510, the example header 520 in the updated message has changed. The “NFInstanceInfo” field 511, the “Timestamp” field 512, the “Cert” field 513, and the “Signature” field 514 remain unchanged.

[0097] The “SCP Signature” field 525 is inserted by the first SCP 130. In this example, the SCP signature in the “SCP Signature” field 525 can be generated by signing the content or a digest of the content of “3gpp-Sbi-SendingNFInfo” with the private key of the first SCP 130 (which is shown as “PrSCPc” in the example). In other words, the SCP signature in the “SCP Signature” field 525 specific to the first SCP 130 can be generated based on the signature of the NF110 and the NF information, which in this example includes identification information (e.g., “NFInstanceInfo”), time information (e.g., “Timestamp”), and certificate information (e.g., “Cert”).

[0098] Still referencing Figure 4 After receiving the updated message from the first SCP 130, the second SCP 140 verifies the SCP signature in the updated message 440, which is the signature of the first SCP 130. The second SCP 140 can use the public key of the first SCP 130, which is available in the TLS client certificate (which was provided by the first SCP 130 during the TLS handshake), to verify the SCP signature in the HTTP header. Figure 5 As shown in the example, the signature in the “SCP Signature” field 525 can be verified by a second SCP 140, which in this case is SCPp.

[0099] If the SCP signature is successfully verified, the second SCP 140 further updates message 445. Then, the second SCP 140 sends the further updated message 450 or forwards it to receiving NF 120, with the second SCP 140 having established a mutually authenticated TLS connection with receiving NF 120.

[0100] In this example embodiment with e2e authentication enabled, in order to update a message, the second SCP 140 can generate its own SCP signature and replace the SCP signature of the first SCP 130 in the message (e.g., in the HTTP header) with its own SCP signature. Reference Figure 5 Compared to sample header 520, sample header 530 in the further updated message has changed. The “NFInstanceInfo” field 511, “Timestamp” field 512, “Cert” field 513, and “Signature” field 514 remain unchanged.

[0101] In the “SCP Signature” field 535, the SCP signature of the first SCP 130 is replaced by the SCP signature of the second SCP 140. In this example, the SCP signature in the “SCP Signature” field 535 can be generated by signing the content or a digest of the content of “3gpp-Sbi-SendingNFInfo” using the private key of the second SCP 140 (which is shown as “PrSCPp” in the example). In other words, the SCP signature specific to the second SCP 140 in the “SCP Signature” field 535 can be generated based on the signature of sending NF 110 and NF information, which in this example includes identification information (e.g., “NFInstanceInfo”), time information (e.g., “Timestamp”), and certificate information (e.g., “Cert”).

[0102] Still referencing Figure 4 After receiving a further updated message from the second SCP 140, the receiving NF 120 verifies the SCP signature in the further updated message, i.e., the SCP signature of the second SCP 140. The receiving NF 120 can verify the SCP signature in the HTTP header using the public key of the second SCP 140, which is available in the TLS client certificate (which was provided by the second SCP 140 during the TLS handshake). Figure 5 As shown in the example, the SCP signature in the “SCP Signature” field 535 can be verified by the receiving NF 120 (which is NFp in this case).

[0103] If the SCP signature of the second SCP 140 is successfully verified, the receiving NF 120 can obtain the certificate information of the sending NF 110, for example, the client certificate of the sending NF 110. Then, the receiving NF 120 verifies the signature of the sending NF 110. For example, as... Figure 5 As shown, the signature in the “Signature” field 514 can be verified by the receiving NF 120, for example, by using the client certificate that sent NF 110.

[0104] After successfully verifying the signature of the transmitted NF 110, the receiving NF retrieves the identification information of the transmitted NF 110 from the message forwarded by the second SCP 140. For example, the receiving NF 120 can obtain this information from the header (e.g., Figure 5 The header 530 shown retrieves the NF Instance Id, NF Set Id, or FQDN of the NF110 being sent.

[0105] In some example embodiments where the NF information includes time information, similar to the above references... Figure 2 As described, receiving NF 120 can perform time window verification.

[0106] In the above about Figure 4 In the description, the sending NF can attach its signature and client certificate to the HTTP header. This is sent to the receiving NF via an end-to-end (e2e) method. The receiving NF can use the public key obtained from the client certificate to verify the Proof of Possession, thus verifying the sending NF's signature. This enables end-to-end authentication, supporting scenarios where end-to-end authentication between two NFs is required for critical service operations.

[0107] In the above description, the certificate information of the sending NF is inserted into the message by the sending NF itself. Alternatively, in some other example embodiments, the certificate information of the sending NF may be inserted by an SCP with which the sending NF has communicated and with which a secure TLS-based connection has been established, or it may be inserted by an SCP acting as a side-car proxy for the NF. Still referring to... Figure 4 In such an example embodiment, the second SCP 130 may insert the certificate information for sending NF 110 into message 425. For example, the second SCP 130 may insert the client certificate for sending NF 110, acquired during the TLS handshake, into the message. Alternatively, if a different certificate is used for digital signatures, the operator may provide the inserted certificate separately.

[0108] The certificate information sent to NF 110 may be or include the client certificate that sent NF 110. Alternatively or additionally, the certificate information sent to NF 110 may include an address that enables the acquisition of the client certificate or the public key of the sending NF 110. For example, a Uniform Resource Locator (URL) can be inserted, pointing to a location where the receiving NF 120 can acquire the client's public key or client certificate. Instead of inserting a certificate, inserting an address (e.g., a URL) can reduce message overhead.

[0109] Despite Figure 2 and Figure 4 As not shown, for the first SCP 130, the second SCP 140, and the receiving NF 120, if signature verification fails or timestamp verification indicates a potential replay attack, the receiving entity or node may send an appropriate (secure) failure response to the receiving entity or node.

[0110] It should be understood that the proposed solution is not limited to NFC, but can also generally be used to identify the HTTP client that generates the notification. It provides a method for the recipient of communication (directly or indirectly) to identify the source of the communication.

[0111] Reference Figure 6-8 Further details are described based on exemplary embodiments of this disclosure.

[0112] Figure 6 A flowchart of an example method 600 according to some example embodiments of the present disclosure is shown. Method 600 can be implemented at any suitable device. For example, method 600 can be implemented at a first means configured to implement... Figure 1 SCP 130 or 140. For discussion purposes, references will be made to... Figure 1 To describe method 600.

[0113] In block 610, a first device receives a message from a second device associated with a first NF 110, pointing to a second NF 120. This message includes a first signature and network function information, which includes at least identification information of the first NF 110. In block 620, based on successful verification of the first signature, the first device updates the message with a second signature specific to the service communication agent implemented by the first device. In block 630, the first device sends the updated message to a third device associated with the second NF 120, the updated message including at least the second signature and network function information.

[0114] In some example embodiments, updating a message with a second signature includes: generating a second signature based on the private key of the network function information and the service communication agent; and replacing the first signature in the message with the second signature.

[0115] In some example embodiments, the network function information also includes certificate information for the first NF 110, the second device is configured to implement the first NF 110, and updating the message with the second signature includes: generating the second signature based at least on the first signature and the private key of the service communication agent; and inserting the second signature into the message.

[0116] In some example embodiments, the second device is configured to implement the first NF 110, and updating the message with the second signature includes: inserting the certificate information of the first NF 110 as part of the network function information into the message; generating the second signature based at least on the first signature and the private key of the service communication agent; and inserting the second signature into the message.

[0117] In some example embodiments, the network function information also includes certificate information for the first NF 110, the second device is configured to implement another service communication agent connecting to the first NF 110, and updating the message with the second signature includes: generating the second signature based at least on the first signature and the private key of the service communication agent; and replacing the first signature in the message with the second signature.

[0118] In some example embodiments, the message also includes a third signature specific to the first NF 110, and wherein the third device is configured to implement the second NF 120.

[0119] In some example embodiments, the certificate information of the first NF 110 includes at least one of the following: the client certificate of the first NF 110, or an address that enables the acquisition of the client certificate or public key of the first network device.

[0120] In some example embodiments, the network function information also includes at least one of the following: type information of the first NF110 or time information related to message transmission.

[0121] In some example embodiments, the identification information of the first NF 110 includes at least one of the following: the instance identifier of the first NF 110, the set identifier of the first NF 110, or the FQDN of the first NF 110.

[0122] Figure 7 A flowchart of an example method 700 according to some example embodiments of the present disclosure is shown. Method 700 can be implemented at any suitable device. For example, method 700 can be implemented at a second device configured to implement such... Figure 1 The receiving NF 110 in the middle. For discussion purposes, reference will be made to... Figure 1 Let's describe method 700.

[0123] At block 710, the second device generates a signature based on network function information, which includes at least identification information of the first NF 110, and the signature is specific to the first NF 110 implemented by the second device. At block 720, the second device generates a message from the first NF 110 to the second NF 120, the message including the signature and network function information. At block 730, the second device sends the message to a first device configured to implement a service communication proxy connecting to the first NF 110 or to implement the second NF 120.

[0124] In some example embodiments, the network function information also includes at least one of the following: certificate information of the first NF110, type information of the first NF110, or time information related to message transmission.

[0125] In some example embodiments, the certificate information of the first NF 110 includes at least one of the following: the client certificate of the first NF 110, or an address that enables the acquisition of the client certificate or public key of the first network device.

[0126] In some example embodiments, the identification information of the first NF 110 includes at least one of the following: the instance identifier of the first NF 110, the set identifier of the first NF 110, or the FQDN of the first NF 110.

[0127] Figure 8 A flowchart of an example method 800 according to some example embodiments of the present disclosure is shown. Method 800 can be implemented at any suitable device. For example, method 800 can be implemented at a third means configured to implement, as described above. Figure 1 The example shown is NF 120. For discussion purposes, reference will be made to... Figure 1 Let's describe method 800.

[0128] At block 810, the third device receives a message from the first device, configured to implement a service communication agent, pointing from the first NF110 to the second NF120 implemented by the third device. At block 820, the third device verifies a service communication agent-specific signature in the message, which also includes network function information, including at least the identification information of the first NF110. At block 830, based on successful signature verification, the third device retrieves the identification information of the first network function from the message.

[0129] In some example implementations, verifying a service communication agent-specific signature in the message includes using the service communication agent's public key to verify the signature.

[0130] In some example embodiments, the network function information also includes certificate information of the first NF 110, and obtaining identification information includes: obtaining certificate information from the message based on successful signature verification; using the obtained certificate information to verify another signature in the message specific to the first NF 110; and obtaining identification information of the first network function from the message based on successful verification of the other signature.

[0131] In some example embodiments, the certificate information of the first NF 110 includes at least one of the following: the client certificate of the first NF 110, or an address that enables the acquisition of the client certificate or public key of the first network device.

[0132] In some example embodiments, the network function information also includes time information related to message transmission, and the method further includes: performing time window verification based at least in part on the time information based on successful signature verification; and sending a failure response to a first device based on the determination of an invalid time window.

[0133] In some example embodiments, the identification information of the first NF 110 includes at least one of the following: the instance identifier of the first NF 110, the set identifier of the first NF 110, or the FQDN of the first NF 110.

[0134] In some example embodiments, the first means capable of performing method 600 may include modules for performing the various steps of method 600. These modules may be implemented in any suitable form. For example, the module may be implemented in a circuit or software module.

[0135] The first apparatus includes: a module for receiving a message from the first network function to the second network function from a second device associated with the first network function, the message including a first signature and network function information, the network function information including at least identification information of the first network function; a module for updating the message with a second signature specific to a service communication agent implemented by the first device based on successful verification of the first signature; and a module for sending the updated message to a third device associated with the second network function, the updated message including at least the second signature and the network function information.

[0136] In some example embodiments, the module for updating the message with the second signature includes: a module for generating the second signature based on the network function information and the private key of the service communication agent; and a module for replacing the first signature in the message with the second signature.

[0137] In some example embodiments, the network function information further includes certificate information for the first network function, the second device is configured to implement the first network function, and the module for updating the message with the second signature includes: a module for generating the second signature based at least on the first signature and the private key of the service communication agent; and a module for inserting the second signature into the message.

[0138] In some example embodiments, the second apparatus is configured to implement the first network function, and the module for updating the message with the second signature includes: a module for inserting certificate information of the first network function as part of the network function information into the message; a module for generating the second signature based at least on the first signature and the private key of the service communication agent; and a module for inserting the second signature into the message.

[0139] In some example embodiments, the network function information further includes certificate information of the first network function, the second device is configured to implement another service communication agent connected to the first network function, and the module for updating the message with the second signature includes: a module for generating the second signature based at least on the first signature and the private key of the service communication agent; and a module for replacing the first signature in the message with the second signature.

[0140] In some example embodiments, the message also includes a third signature specific to the first network function, and wherein a third means is configured to implement the second network function.

[0141] In some example embodiments, the certificate information of the first network function includes at least one of the following: the client certificate of the first network function, or an address that enables the acquisition of the client certificate or public key of the first network device.

[0142] In some example embodiments, the network function information further includes at least one of the following: type information of the first network function or time information related to the transmission of the message.

[0143] In some example embodiments, the identification information of the first network function includes at least one of the following: the instance identifier of the first network function, the set identifier of the first network function, or the FQDN of the first network function.

[0144] In some example embodiments, the second means capable of performing method 700 may include modules for performing the various steps of method 700. These modules may be implemented in any suitable form. For example, the module may be implemented in a circuit or software module.

[0145] The second device includes: a module for generating a signature based on network function information, the network function information including at least identification information of a first network function, the signature being specific to the first network function implemented by the second device; a module for generating a message from the first network function to a second network function, the message including the signature and the network function information; and a module for sending the message to the first device, the first device being configured to implement a service communication proxy connected to the first network function or to implement the second network function.

[0146] In some example embodiments, the network function information further includes at least one of the following: certificate information of the first network function, type information of the first network function, or time information related to the transmission of the message.

[0147] In some example embodiments, the certificate information of the first network function includes at least one of the following: the client certificate of the first network function, or an address that enables the acquisition of the client certificate or public key of the first network device.

[0148] In some example embodiments, the identification information of the first network function includes at least one of the following: the instance identifier of the first network function, the set identifier of the first network function, or the FQDN of the first network function.

[0149] In some example embodiments, the third means capable of performing method 800 may include modules for performing the various steps of method 800. These modules may be implemented in any suitable form. For example, the module may be implemented in a circuit or software module.

[0150] The third device includes: a module for receiving from a first device configured to implement a service communication agent a message from a first network function to a second network function implemented by the third device; a module for verifying a signature specific to the service communication agent in the message, the message further including network function information, the network function information including at least identification information of the first network function; and a module for obtaining the identification information of the first network function from the message based on successful signature verification.

[0151] In some example embodiments, the module for verifying a signature in the message specific to the service communication agent includes a module for verifying the signature using the public key of the service communication agent.

[0152] In some example embodiments, the network function information further includes certificate information of the first network function, and the module for obtaining the identification information includes: a module for obtaining certificate information from the message based on successful verification of the signature; a module for using the obtained certificate information to verify another signature in the message specific to the first network function; and a module for obtaining the identification information of the first network function from the message based on successful verification of the other signature.

[0153] In some example embodiments, the certificate information of the first network function includes at least one of the following: the client certificate of the first network function, or an address that enables the acquisition of the client certificate or public key of the first network device.

[0154] In some example embodiments, the network function information further includes time information related to the transmission of the message, and the third device further includes: a module for performing time window verification based at least in part on the time information based on the successful verification of the signature; and a module for sending a failure response to the first device based on the determination of an invalid time window.

[0155] In some example embodiments, the identification information of the first network function includes at least one of the following: the instance identifier of the first network function, the set identifier of the first network function, or the FQDN of the first network function.

[0156] Figure 9 This is a simplified block diagram of a device 900 suitable for implementing embodiments of the present disclosure. The device 900 can be provided to implement a communication device, such as... Figure 1 The SCP 130 or 140 shown receives NF 110 or transmits NF 120. As shown, the device 900 includes one or more processors 910, one or more memories 920 coupled to the processors 910, and one or more communication modules 940 coupled to the processors 910.

[0157] Communication module 940 is used for bidirectional communication. Communication module 940 has at least one antenna to facilitate communication. The communication interface can represent any interface necessary for communication with other network elements.

[0158] Processor 910 can be of any type suitable for a local technology network, and by way of non-limiting example, can include one or more of the following: general-purpose computer, special-purpose computer, microprocessor, digital signal processor (DSP), and processor based on a multi-core processor architecture. Device 900 can have multiple processors, such as application-specific integrated circuit chips, which are time-subordinate to a clock synchronized with the main processor.

[0159] Memory 920 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 924, electrically programmable read-only memory (EPROM), flash memory, hard disk, optical disc (CD), digital video disc (DVD), and other magnetic and / or optical storage. Examples of volatile memories include, but are not limited to, random access memory (RAM) 922 and other volatile memories that do not persist during power-off periods.

[0160] Computer program 930 includes computer-executable instructions that are executed by the associated processor 910. Program 930 may be stored in ROM 920. Processor 910 can perform any appropriate actions and processes by loading program 930 into RAM 920.

[0161] The embodiments of this disclosure can be implemented using program 930, such that device 900 can perform the reference... Figures 6 to 8 Any process discussed in this disclosure. Embodiments of this disclosure may also be implemented by hardware or by a combination of software and hardware.

[0162] In some embodiments, program 930 may be tangibly contained in a computer-readable medium, which may be included in device 900 (such as in memory 920) or other storage device accessible to device 900. Device 900 may load program 930 from the computer-readable medium into RAM 922 for execution. The computer-readable medium may include any type of tangible non-volatile storage device, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc. Figure 10 An example of a computer-readable medium 1000 in the form of a CD or DVD is shown. The computer-readable medium has a program 930 stored thereon.

[0163] It should be understood that future networks can leverage Network Functions Virtualization (NFV), a network architecture concept that proposes a method of virtualizing network node functions as "building blocks" or entities that can be operationally connected or linked together to provide services. Virtualized network functions (VNFs) can include one or more virtual machines running computer program code using standard or general-purpose type servers instead of custom hardware. Cloud computing or data storage can also be utilized. In radio communications, this might mean performing node operations, at least partially, in a central / centralized unit (CU) (e.g., a server, host, or node) operatively coupled to a distributed unit (DU) (e.g., a radio head / node). Alternatively, node operations may be distributed across multiple servers, nodes, or hosts. It should also be understood that the distribution of labor between core network operations and base station operations can vary depending on the implementation.

[0164] In one embodiment, the server can generate a virtual network through which it communicates with distributed units. Typically, virtual networking involves the process of combining hardware and software network resources and network functions into a single software-based management entity, i.e., the virtual network. Such a virtual network can provide flexible operational distribution between the server and wireless heads / nodes. In practice, any digital signal processing task can be performed in the CU or DU, and the boundaries of responsibility transferred between the CU and DU can be selected based on the implementation.

[0165] Therefore, in one embodiment, a CU-DU architecture is implemented. In this case, device 900 may be included in a central unit (e.g., control unit, edge cloud server, server) operatively coupled (e.g., via a wireless or wired network) to distributed units (e.g., remote wireless heads / nodes). That is, the central unit (e.g., edge cloud server) and distributed units may be independent devices communicating with each other via a wireless path or via a wired connection. Alternatively, they may be in the same entity communicating via a wired connection, etc. The edge cloud or edge cloud server may serve multiple distributed units or a radio access network. In one embodiment, at least some of the described processes may be performed by the central unit. In another embodiment, device 900 may alternatively be included in distributed units, and at least some of the described processes may be performed by the distributed units.

[0166] In one embodiment, the execution of at least some functions of device 900 can be shared between two physically separate devices (DU and CU) forming an operational entity. Therefore, it can be seen that the apparatus depicts an operational entity comprising one or more physically separate devices for performing at least some of the described processes. In one embodiment, such a CU-DU architecture can provide a flexible operational distribution between the CU and DU. In practice, any digital signal processing task can be performed in either the CU or the DU, and the boundaries of responsibility transferred between the CU and DU can be selected depending on the implementation. In one embodiment, device 900 controls the execution of the process regardless of the location of the apparatus or where the process / function is performed.

[0167] Generally, the various embodiments of this disclosure can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects can be implemented in hardware, while others can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of this disclosure are illustrated and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that the blocks, apparatuses, systems, techniques, or methods described herein can be implemented as non-limiting examples in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0168] This disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as those included in a program module, which execute in a device on a target real or virtual processor to perform the above-mentioned... Figure 6-8 Methods 600, 700, or 800 are described. Typically, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. The functionality of a program module can be combined or divided among program modules as required in the various embodiments. The machine-executable instructions used for the program module can execute within a local or distributed device. In a distributed device, the program module can reside on local and remote storage media.

[0169] Program code used to perform the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that, when executed by the processor or controller, the program code enables the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine as a stand-alone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0170] In the context of this disclosure, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, etc.

[0171] A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a computer-readable storage medium will include the following: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0172] Furthermore, although operations are described in a specific order, this should not be construed as requiring such operations to be performed in the specific order shown or in a sequential order, or to perform all shown operations to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure, but rather as descriptions of features specific to particular embodiments. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination.

[0173] Although this disclosure has been described in language specific to structural features and / or methodological actions, it should be understood that the disclosure as defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as exemplary forms for implementing the claims.

Claims

1. A service communication proxy entity connected to a first network function entity, the service communication proxy entity comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the service communication proxy entity to: receive, from a second apparatus associated with the first network function entity, a message directed from the first network function entity to a second network function entity, wherein the first network function entity is a sending network function and the second network function entity is a receiving network function, the message comprising a first signature and network function information, the network function information comprising at least identification information of the first network function entity; verify the first signature in the message; update the message with a second signature specific to the service communication proxy entity based on a successful verification of the first signature, the second signature being generated based on the network function information; and send the updated message to a third apparatus associated with the second network function entity, the updated message comprising at least the second signature and the network function information.

2. The service communication proxy entity of claim 1, wherein, the service communication proxy entity being further caused to: generate the second signature based on the network function information and a private key of the service communication proxy entity; and replace the first signature in the message with the second signature.

3. The serving communication proxy entity of claim 1, wherein, the network function information further comprising certificate information of the first network function entity, the second apparatus being configured to implement the first network function entity, and the service communication proxy entity being caused to: generate the second signature based on at least the first signature and a private key of the service communication proxy entity; and insert the second signature in the message.

4. The serving communication proxy entity of claim 1, wherein, the second apparatus being configured to implement the first network function entity, and the service communication proxy entity being further caused to: insert certificate information of the first network function entity as part of the network function information in the message; generate the second signature based on at least the first signature and a private key of the service communication proxy entity; and insert the second signature in the message. the network function information further comprising certificate information of the first network function entity, the second apparatus being configured to implement another service communication proxy entity connected to the first network function, and the service communication proxy entity being caused to:

5. The service communication proxy entity of claim 1, wherein, generate the second signature based on at least the first signature and a private key of the service communication proxy entity; and replace the first signature in the message with the second signature. the message further comprising a third signature specific to the first network function entity, and wherein the third apparatus is configured to implement the second network function entity.

6. The serving communication proxy entity of claim 5, wherein, the certificate information of the first network function entity comprising at least one of:

7. The serving communication proxy entity of claim 3, wherein, a client certificate of the first network function, or an address enabling retrieval of a client certificate or a public key of the first network function entity. the network function information further comprising at least one of:

8. The serving communication proxy entity of claim 1, wherein, ​ type information of the first network function entity, or time information about transmission of the message.

9. The serving communication proxy entity of claim 1, wherein, The identification information of the first network function comprises at least one of: an instance identifier of the first network function entity, a set identifier of the first network function entity, or a fully qualified domain name of the first network function entity.

10. A first network function entity for communication, comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the first network function entity to: generate a signature based on network function information, the network function information comprising at least identification information of the first network function entity, the signature being specific to the first network function entity; generate a message from the first network function entity to a second network function entity, wherein the first network function entity is a sending network function and the second network function entity is a receiving network function, the message comprising the signature and the network function information; and send the message to a service communication proxy entity connected to the first network function entity. The network function information further comprises at least one of:

11. The first network function entity of claim 10, wherein, certificate information of the first network function entity, type information of the first network function entity, or time information about transmission of the message. The certificate information of the first network function entity comprises at least one of:

12. The first network function entity of claim 11, wherein, a client certificate of the first network function entity, or an address enabling to get a client certificate or a public key of the first network function entity. The identification information of the first network function entity comprises at least one of:

13. The first network function entity of claim 10, wherein, an instance identifier of the first network function entity, a set identifier of the first network function entity, or a fully qualified domain name of the first network function entity.

14. A method for communication, comprising: generating, at a first network function entity, a signature based on network function information, the network function information comprising at least identification information of the first network function entity, the signature being specific to the first network function entity; generating, by the first network function entity, a message from the first network function entity to a second network function, wherein the first network function entity is a sending network function and the second network function entity is a receiving network function, the message comprising the signature and the network function information; and sending, by the first network function entity, the message to a service communication proxy entity connected to the first network function entity. The network function information further comprises at least one of: certificate information of the first network function entity, 15. The method of claim 14, wherein, type information of the first network function entity, or time information about transmission of the message. The certificate information of the first network function entity comprises at least one of: a client certificate of the first network function entity, or 16. The method of claim 15, wherein, an address enabling to get a client certificate or a public key of the first network function entity. ​ ​ 17. The method of claim 14, wherein, The identification information of the first network function entity comprises at least one of: an instance identifier of the first network function entity, a set identifier of the first network function entity, or a fully qualified domain name of the first network function entity.

Images