Identifying sip message encryption for inbound roaming devices

Abstract

The present disclosure provides a method for identifying that Session Initiation Protocol (SIP) message encryption is enabled for Voice over Long Term Evolution (VoLTE) communications for an inbound roaming device. A Lawful Intercept Mirror IP Multimedia Subsystem State Function (LMISF) device of a core network can receive a registration response message to an inbound roaming device that is forwarded by a Bearer Binding Intercept and Forwarding Function (BBIFF) device, where the message includes a security field, and based on the security field, the LMISF device can determine whether the inbound roaming device is configured to enable SIP message encryption. The LMISF device can determine the roaming operator domain based on the message, and then provide an alert to the communication service provider indicating that the roaming operator domain enables SIP message encryption.

Description

[0001] IDENTIFYING SIP MESSAGE ENCRYPTION FOR INBOUND ROAMING DEVICES

[0002] Technical Field

[0003] The present disclosure relates to a method for identifying that Session Initiation Protocol message encryption is enabled for Voice over Long Term Evolution (VoLTE) communications for an inbound roaming device in a wireless communication system. The disclosure also relates to a network node, a computer program and a carrier containing the computer program.

[0004] Background

[0005] The S8 Home Routing (S8HR) architecture has been selected by the Global System for Mobile Communications Association (GSMA) and Third Generation Partnership Program (3GPP) as a reference architecture for Internet Protocol Multimedia Subsystem (IMS) Roaming.

[0006] With S8HR IMS Roaming, the IMS Access Point Name (APN) is resolved to the Packet Data Network (PDN) Gateway (PGW) 110 in the Home Public Land Mobile Network (HPLMN) 104 as shown in Figure 1. In addition, Quality of Service (QoS) level roaming support is required to support IMS Voice and Video telephony (VoIMS), i.e. service specific QoS other than the default QoS are to be supported on the home - routed PDN connection for the IMS APN when roaming. IMS is supported by both the Visited Public Land Mobile Network (VPLMN) 102 and the HPLMN 104.

[0007] In Figure 1, the User Equipment is an inbounding roaming device 106 that belongs to HPLMN 104 and is roaming in VPLMN 102. When the inbound roaming device 106 attempts to make a call or have some other communication session with a third party (e.g., Party B) 108, the Serving Gateway (SGW) 114 in the VPLMN 102 interfaces with the PGW 110 in the HPLMN 104, which is the IMS APN.

[0008] HPLMN 104 and VPLMN 102 exchange information and provided that there is a roaming agreement, IMS roaming for the inbound roaming device 106 is enabled via S8HR considering local regulatory requirements in the VPLMN 102.

[0009] The HPLMN 104 should ensure, based on the roaming agreement, that IMS layer signaling, and media confidentiality protection is not activated to enable the VPLMN 102 to meet the local regulatory requirements. If the HPLMN 104 uses IMS layer signaling and media confidentiality protection on its network (e.g. for the HPLMN 104's own subscribers, for inbound roaming local breakout (LBO) IMS subscribers), then, based on the customer location retrieved through subscription to the Policy and Charging Rules Function (PCRF) 112, this protection shall be deactivated in the HPLMN 104 to support S8HR outbound roamers.

[0010] Regulatory requirements in the country of the VPLMN 102 may require support for Lawful Interception and Data Retention. Those functions require the VPLMN to handle at the application layer the VoLTE calls, to handle the communications identities and signaling.

[0011] Since there is no IMS node in the VPLMN 102, the interception of the VoLTE inbound roaming subscribers' traffic is only possible in the nodes of the Evolved Packet System (EPS) domain.

[0012] This implies that there is no possibility to retrieve the information about SIP identities, IMS signaling and payload, which poses severe limitations to the effectiveness of the interception of VoLTE calls for inbounding roamers.

[0013] To overcome this limitation, 3GPP has specified the Lawful Interception architecture in 3GPP TS 33.107 V17.0.0 (2022-03) and TR 33.827: Study on providing for Lawful Interception (LI) in the S8 Home Routing (S8HR) architecture for Voice over LTE (VoLTE) for the S8HR architecture, introducing in the network the following two new functional entities, LI Mirror IMS State Function (LMISF) and Bearer Binding Intercept and Forwarding Function (BBIFF) that make it possible to intercept the VoLTE calls to / from inbound roamers in the Evolved Packet Core (EPC) nodes, providing IMS- like interception.

[0014] The LMISF mirrors the home network's Session Border Gateway (SBG) functionality. It keeps a list of the IMS targets, generates "IMS-like" Intercept Related Information (IRI), triggers the Content of Communication (CC) interception for those VoLTE inbound roamers' communications related to the intercepted targets and sends them to the LI Mediation Function.

[0015] The BBIFF is a functionality in the Serving Gateway (S-GW), in the EPC network. It recognizes the IMS signaling packets related to the VoLTE inbound roamers' communications, captures the IMS media packets related to the intercepted targets and forwards them to the LMISF. Summary

[0016] An object of the invention is to determine whether inbound roaming devices can comply with Lawful Intercept (LI) data retention regulations.

[0017] The present disclosure provides a method for identifying that Session Initiation Protocol (SIP) message encryption is enabled for Voice over Long Term Evolution (VoLTE) communications for an inbound roaming device. A Lawful Intercept Mirror IP Multimedia Subsystem State Function (LMISF) device of a core network can receive a registration response message to an inbound roaming device that is forwarded by a Bearer Binding Intercept and Forwarding Function (BBIFF) device, where the message includes a security field, and based on the security field, the LMISF device can determine whether the inbound roaming device is configured to enable SIP message encryption. The LMISF device can determine the roaming operator domain based on the message, and then provide an alert to the communication service provider indicating that the roaming operator domain enables SIP message encryption.

[0018] In an embodiment, a method of for identifying that SIP message encryption is enabled for a VoLTE communication from an inbound roaming device performed by an LMISF device. The method includes receiving a registration response message, wherein the registration response message comprises a security field. The method also includes based on the security field, determining whether the inbound roaming device is configured to enable SIP message encryption. The method also includes in response to determining that SIP message encryption is enabled, determining a roaming operator domain based on the registration response message. The method also includes providing an alert to a communication service provider indicating that the roaming operator domain enables SIP message encryption.

[0019] In an embodiment, the method includes receiving, prior to receiving the registration response message, a registration request message associated with the inbound roaming device.

[0020] In an embodiment, the registration response message and the registration request message are received from a Bearer Binding Intercept and Forwarding Function (BBIFF) device that is an intermediary between the inbound roaming device and a Proxy Call Session Control Function (P-CSCF) device associated with the communication service provider. In an embodiment the registration request message was sent from the inbounding roaming device to the P-CSCF device, and the registration response message was sent from the P-CSCF device to the inbound roaming device.

[0021] In an embodiment the security field includes one of a parameter indicating a supported encryption algorithm, a parameter indicating no supported encryption algorithm, or a parameter indicating no supported encryption algorithm; or no parameter indicating a supported encryption algorithm.

[0022] In an embodiment, the determining that SIP message encryption is configured enabled is based on the security field comprising the parameter indicating the supported encryption algorithm.

[0023] In an embodiment, the method includes determining that the inbound roaming device is not configured to enable SIP message encryption based on the security field comprising the parameter indicating no supported encryption algorithm, or not comprising the parameter indicating a supported encryption algorithm.

[0024] In an embodiment, the method includes in response to determining that the inbound roaming device is not configured to enable SIP message encryption, taking no further action.

[0025] In an embodiment, the registration response message is an Authentication Challenge response.

[0026] In an embodiment, determining a roaming operator domain is based on a From header value that comprises an IP Multimedia Private Identity (IMPI) associated with a user of the inbound roaming device.

[0027] In an embodiment, a network node that implements an LMISF device is configured to identify that SIP message encryption is enabled for a VoLTE communication from an inbound roaming device. The network node includes processing circuitry that is configured to cause the network node to receive a registration response message, wherein the registration response message comprises a security field. The processing circuitry can also cause the network node to, based on the security field, determine whether the inbound roaming device is configured to enable SIP message encryption and in response to determining that SIP message encryption is enabled, determine a roaming operator domain based on the registration response message. The processing circuitry can also cause the network node to provide an alert to a communication service provider indicating that the roaming operator domain enables SIP message encryption.

[0028] In an embodiment a computer program can comprise instructions that when executed on at least one processor cause the processor to carry out the method described above. A carrier can also contain the computer program where the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

[0029] In an embodiment, an advantage provided by the methods and techniques disclosed herein is that the roaming solution implemented by a home network can comply with LI regulations and policies, and that a local network operator does not have any information of changes in partner roaming operator home networks that could imply encryption configuration settings for roaming subscribers. Additionally, the method allows the prompt detection of improper encryption configuration by roaming partners on the IMS home network.

[0030] Brief Description of the

[0031] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

[0032] Figure 1 illustrates an exemplary Voice Over LTE (VoLTE) roaming architecture according to an embodiment of the present disclosure;

[0033] Figure 2 illustrates a block diagram of an overview of a Lawful Intercept Mirror IP Multimedia Subsystem State Function (LMISF) device according to an embodiment of the present disclosure;

[0034] Figure 3 illustrates a message sequence chart for identifying that Session Initiation Protocol (SIP) message encryption is enabled for VoLTE communications from an inbound roaming device according to an embodiment of the present disclosure;

[0035] Figure 4 illustrates a flowchart of a method for identifying that SIP message encryption is enabled for VoLTE communications from an inbound roaming device according to an embodiment of the present disclosure;

[0036] Figure 5 illustrates one example of a cellular communications system according to some embodiments of the present disclosure; Figure 6 is a schematic block diagram of a radio access node according to some embodiments of the present disclosure;

[0037] Figure 7 is a schematic block diagram that illustrates a virtualized embodiment of the radio access node of Figure 6 according to some embodiments of the present disclosure; and

[0038] Figure 8 is a schematic block diagram of the radio access node of Figure 6 according to some other embodiments of the present disclosure.

[0039] Detailed Description

[0040] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

[0041] Network Node: As used herein, a "network node" can be any type of apparatus / device in a core network or any apparatus / device that implements a core network function. Some examples of a core network node include a computer or server host for e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P- GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like. In the following description, when stating that any of these functions, such as Lawful Intercept, LI, Mirror IP Multimedia Subsystem, IMS, State Function, LMISF, device, perform an action, such as receiving / determining / providing then it is to be understood that it is in practice the network node / computer / server host / device that hosts the LMISF performs the action.

[0042] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

[0043] The present disclosure provides a method for identifying that Session Initiation Protocol (SIP) message encryption is enabled for Voice over Long Term Evolution (VoLTE) communications for an inbound roaming device. A Lawful Intercept (LI) Mirror IP Multimedia Subsystem (IMS) State Function (LMISF) device of a core network can receive a registration response message to an inbound roaming device that is forwarded by a Bearer Binding Intercept and Forwarding Function (BBIFF) device, where the message includes a security field, and based on the security field, the LMISF device can determine whether the inbound roaming device is configured to enable SIP message encryption. The LMISF device can determine the roaming operator domain based on the message, and then provide an alert to the communication service provider indicating that the roaming operator domain enables SIP message encryption.

[0044] Some of the challenges of the traditional system are that 3GPP 33.107 reports: "A condition required for the operation of S8HR LI is that the IMS signaling messages and the media packets are not encrypted at Serving Gateway (SGW) BBIFF".

[0045] The LMISF analyzes the SIP signaling mirrored by the SGW / BBIFF and exchanged between roamers User Equipment (UE)'s and the Proxy Call Session Control Function (P- CSCF) located in their IMS Home Network.

[0046] In a live environment several Roaming Operators are generally available and handled at the same time by LMISF and if one of them has not disabled the encryption on this path the S8 Home Routing (S8HR) LI function fails for all the roamers belonging to that operator.

[0047] A mechanism to detect if any Roaming Operator has not disabled the encryption on the UE <-> P-CSCF path is needed in the LI S8HR Solution.

[0048] According to 3GPP 33.203 V17.1.1 (2022-03), the subscriber register to the IMS home network REGISTER I 4xx messages are always sent unencrypted and consequently the LMISF should always be able to read and analyze it.

[0049] The 3GPP TS 33.107 V17.0.0 (2022-03) gives this statement:

[0050] A condition required for the operation of S8HR LI is that the IMS signalling messages and the media packets are not encrypted at SGW / BBIFF."

[0051] This condition cannot be respected by a Roaming Partner Operator because of misconfiguration on the IMS Home side. The LMISF, as disclosed in the methods herein, will be able to detect this misalignment on encryption setting on IMS signaling messages and inform the Local Operator that it cannot perform the required actions.

[0052] The LMISF, upon analyzing the received 4xx REGISTER responses, can detect if SIP message encryption is enabled for that user belonging to a specific roaming partner operator and generate ad hoc event for the Local Operator.

[0053] In an embodiment, an advantage provided by the methods and techniques disclosed herein is that the roaming solution implemented by a home network can comply with LI regulations and policies, and that a local network operator does not have any information of changes in partner roaming operator home networks that could imply encryption configuration settings for roaming subscribers. Additionally, the method allows the prompt detection of improper encryption configuration by roaming partners on the IMS home network.

[0054] Figure 2 illustrates a block diagram of an overview of an LMISF device 202 according to an embodiment of the present disclosure. In the S8HR architecture, the LMISF device 202 provides the proprietary interfaces (Xia, Xib) towards the EPC nodes (i.e. S-GW / BBIFF 114) to receive the IMS signaling from the default bearers related to all VoLTE inbound roaming subscribers (e.g., inbound roaming device 106) and the media packets only for the intercepted targets from the dedicated bearers when the access point name (APN) is IMS.

[0055] LMISF device 202 receives over the proprietary Xl_l interface the IMS target identities from the ADMF 204. The LMISF device 202 retrieves the IMS signaling from the received signaling packets and, in case of traffic tied to an intercepted target, triggers the BBIFF 114 to send the media packets for the session to be intercepted. The IMS signaling and the media packets related to the intercepted targets are then sent over the proprietary X2 and X3 interfaces to the LI Mediation and Deliver functions (MDF) MDF1 206-1 and MDF2 206-2, which then provide the media packets to Law Enforcement Monitoring Function 208.

[0056] It's worth noting that to intercept the SIP signaling and the real time transport protocol (RTP) also in the VPLMN 102 it is a requirement for the operation of S8HR LI that IMS signaling messages and media packets are not encrypted (this is controlled by the HPLMN 104).

[0057] Turning off IMS level encryption (IP Security confidentiality protection) for outbound VoLTE roamers between UE and P-CSCF does not impact communication integrity protection. It should also be noted that IPSEC between UE and P-CSCF is still used, albeit with a null encryption algorithm.

[0058] Figure 3 illustrates a message sequence chart for identifying that SIP message encryption is enabled for VoLTE communications from an inbound roaming device 106 according to an embodiment of the present disclosure.

[0059] Before a user can get access to the IP Multimedia services at least one IP Multimedia Public Identity (IMPU) is registered and the IP Multimedia Private Identity (IMPI) should be authenticated in the IMS at an application level. To get registered, the inbound roaming device 106 sends a SIP REGISTER message at step 302 to the IMS Home Registrar Server via the P-CSCF 303, which will perform the authentication of the user.

[0060] With the Security Mechanism Agreement for the Session Initiation Protocol, commonly referred to as Sec-Agree, (defined in IETF RFC 3329 (2003): "Security Mechanism Agreement for the Session Initiation Protocol (SIP)") it allows the inbound roaming device 106 and the P-CSCF 303 to negotiate a common security mechanism for use between them.

[0061] The RFC defines three SIP headers, Security-Client, Security-Server, and Security-Verify that provide the ability for SIP user agents (UAs) and other SIP entities (servers, proxies, and registrars) to negotiate next-hop security mechanisms and then to negotiate security agreements during initial REGISTER transactions.

[0062] The Security-Client header contains one or more security mechanisms and associated parameters proposed by the initiating client, comprising the supported encryption algorithm list.

[0063] The Security-Server header contains the security mechanism chosen by the server, comprising the selected encryption algorithm, from those mechanisms proposed by the client.

[0064] As shown above, the initial REGISTER request is sent without any protection from the inbound roaming device 106 to the P-CSCF 303 at step 302. To guarantee that a common security mechanism can be established, the inbound roaming device 106 advertises the mechanisms it supports in this initial REGISTER request within the Security-Client header, which includes a list of supported mechanisms. The Proxy-Require header includes the option tag "sec-agree"; this indicates that the next hop proxy, in this case the P-CSCF 303, support the procedures for the Sip- Sec-Agree to process the request further.

[0065] Also, a Require header is included, indicating the sec-agree option tag. This is to be included by and it defines the Sip-Sec-Agree. The Require header is used in a corresponding way as the Proxy-Require header, but by the inbound roaming device 106 (not the proxy).

[0066] Sip-Sec-Agree-related headers in the initial REGISTER request

[0067] The P-CSCF 303 sends back a Security-Server header in the 401 (Unauthorized) response at step 306. The header includes the supported mechanisms from the P-CSCF 303.

[0068] Based on this information, both ends now know which common mechanisms are supported by the UE and the P-CSCF 303.

[0069] The Security-Server header in the 401 (Unauthorized) response

[0070] After receiving the 401 (Unauthorized) response at step 306 the inbound roaming device 106 can set up IPsec Security Associations (SAs). When this has been done, it can use these SAs to send the second REGISTER request over it at step 310. The second REGISTER request at step 310 from the inbound roaming device 106 repeats all the information necessary for authentication and registration, both of which are performed with the S-CSCF.

[0071] The inbound roaming device 106 and the P-CSCF 303 will then establish the security mechanism, which is in our case based on IPsec SAs. Afterwards, all messages between the two entities will be sent protected over these SAs (e.g., the 200 (OK) message at 314). Nevertheless, the initial REGISTER request and its response are still not protected.

[0072] The call flow described above for transport layer security (TLS) session setup during the registration procedure with the "Encrypt-algorithm" (ealg) parameter with "aes-cbc" value. If present, it defines the encryption algorithm. If the ealg parameter is present but does not include the "aes-cbc" value, there is no encryption supported. The value "aes-cbc" refers to the algorithm defined in IETF RFC 3602. Likewise, if there is no Encrypt-algorithm parameter present, the algorithm will be "null" - in other words, there is no encryption supported.

[0073] Encryption detection mechanism in LMSIF for LI S8HR solution As already explained, for the LI S8HR solution to work, encryption for trusted roaming networks should be disabled and then the P-CSCF of the Roaming Home network must enforce the configuration by offering in the Security-Server the ealg parameter set to NULL as the only encryption algorithm used for trusted networks. The ealg parameter is only available when sec-agree chooses "ipsec3gpp" as the security mechanism.

[0074] According to 3GPP TS 33.203 these REGISTER / 401 Unauthorized messages are always sent unencrypted and consequently the LMISF device 202 is always able to read and analyze it when the BBIFF 114 forwards each of the messages that pass by the SGW / BBIFF 114 at steps 302, 306, 310 and 314 to the LMISF device 202 at steps 304, 308, 312, and 316.

[0075] The following steps are performed by the LMISF device 202 to detect if the encryption is enabled for a particular roaming partner and eventually generate and event to inform and / or alert the Local Operator that the home network of the inbound roaming device 106 is configured incorrectly.

[0076] At step 308, the LMISF device 202 receives an Authentication Challenge message forwarded by the BBIFF 114 to the LMISF device 202. The Authentication Challenge message could be a 401 Unauthorized response to a REGISTER (or more in general a 4xx Auth_Challenge similar response), that was sent by the P-CSCF 303 to the inbound roaming device 106 at step 306 after the REGISTER Request was sent initially at step 302.

[0077] The LMISF device 202 analyzes the response detecting in the Security-Server field if the ealg parameter is present a. In case the ea / g parameter is not present or its value is “null” (i.e. ealg=null) the encryption is disabled and the LMISF encryption detection task will end (no more steps to perform). b. In case the ealg parameter value is different from “null” (i.e. ealg=aes-cbc) the encryption is enabled and the LMISF encryption detection task will continue.

[0078] The LMISF device 202 takes from the 4xx Response the "Front' header value that contains the IMPI (IP Multimedia Private Identity) of the user. The From header includes a SIP-URI (i.e., "sip: 123456789045@ims.mcZ.mcZ.3gppnetwork.org") from which the LMISF device 202 can extract the domain part that will provide the Roaming Operator domain (i.e., ims.mncXYZ.mccXYZ.3gppnetwork.org). Once the LMISF device 202 determines the operator domain, the LMISF device 202 can provide an alert to the network operator to the communication service provider of the home network that the roaming operator is misconfigured, and can provide the operator domain so that the communication service provider can determine which other devices are impacted, and can alert the roaming operator of the misconfiguration.

[0079] Figure 4 illustrates a flow chart of a method to that described above for identifying that SIP message encryption is enabled for VoLTE communications from an inbound roaming device according to an embodiment of the present disclosure.

[0080] At 402, the method can optionally include receiving, prior to receiving the registration response message, a registration request message associated with the inbound roaming device 106.

[0081] At 404, the method includes receiving a registration response message, wherein the registration response message comprises a security field. In an embodiment, the registration response message and the registration request message are received from BBIFF device 114 that is an intermediary between the inbound roaming device 106 and the P-CSCF device 303 associated with the communication service provider.

[0082] In an embodiment, the registration request message was sent from the inbounding roaming device to the P-CSCF device 303, and the registration response message was sent from the P-CSCF device 303to the inbound roaming device 106.

[0083] In an embodiment, the security field includes one of a parameter indicating a supported encryption algorithm, a parameter indicating no supported encryption algorithm, or no parameter indicating a supported encryption algorithm.

[0084] Based on the security field the method includes, at step 406, determining (406) whether the inbound roaming device 106 is configured to enable SIP message encryption. If there is a parameter indicating a supported encryption algorithm, the LMISF device 202 can determine that the inbound roaming device 106 is configured to enable SIP message encryption, and then, at step 408, the LMISF device 202 can determine a roaming operator domain based on the registration response message.

[0085] In an embodiment, the determining a roaming operator domain is based on a From header value that comprises an IP Multimedia Private Identity, IM PI, associated with a user of the inbound roaming device. Once the roaming operator domain is determined, the LMISF device 202, at step 410 can send an alert to a communication service provider indicating that the roaming operator domain enables SIP message encryption.

[0086] If on the other hand, the LMISF device 202 determines at step 412 that the inbound roaming device 106 is not configured to enable SIP message encryption due to the security field including a parameter indicating no supported encryption algorithm, or no parameter indicating a supported encryption algorithm, then no further action is taken.

[0087] In an embodiment, the registration response message is an Authentication Challenge response. In an embodiment, the registration response message is an Authentication Challenge response.

[0088] Figure 5 illustrates one example of a cellular communications system 500 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 500 is any 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC) or an Evolved Packet System (EPS) including an Evolved Universal Terrestrial RAN (E-UTRAN) and an Evolved Packet Core (EPC) in which a Law Enforcement Agency, LEA, might perform Lawful Interception of communications to or from target devices (e.g., UE 512). In this example, the RAN includes base stations 502-1 and 502-2, [which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC) and in the EPS include eNBs, controlling corresponding (macro) cells 504-1 and 504-2. The base stations 502-1 and 502-2 are generally referred to herein collectively as base stations 502 and individually as base station 502. Likewise, the (macro) cells 504-1 and 504-2 are generally referred to herein collectively as (macro) cells 504 and individually as (macro) cell 504. The RAN may also include a number of low power nodes 506-1 through 506-4 controlling corresponding small cells 508-1 through 508-4. The low power nodes 506-1 through 506-4 can be small base stations (such as pico or femto base stations) or RRHs, or the like. Notably, while not illustrated, one or more of the small cells 508-1 through 508-4 may alternatively be provided by the base stations 502. The low power nodes 506-1 through 506-4 are generally referred to herein collectively as low power nodes 506 and individually as low power node 506. Likewise, the small cells 508-1 through 508-4 are generally referred to herein collectively as small cells 508 and individually as small cell 508. The cellular communications system 500 also includes a core network 510, which in the 5G System (5GS) is referred to as the 5GC. The base stations 502 (and optionally the low power nodes 506) are connected to the core network 510. The core network 510 can include a network node 600 that can implement a network function such as LMISF 202 that can perform the techniques and methods disclosed herein.

[0089] The base stations 502 and the low power nodes 506 provide service to wireless communication devices 512-1 through 512-5 in the corresponding cells 504 and 508. The wireless communication devices 512-1 through 512-5 are generally referred to herein collectively as wireless communication devices 512 and individually as wireless communication device 512. In the following description, the wireless communication devices 512 are oftentimes UEs, but the present disclosure is not limited thereto.

[0090] Figure 6 is a schematic block diagram of a network node 600 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node 600 may be, for example, a network node that implements all or part of the functionality of LMISF device 202 as described herein. As illustrated, the network node 600 includes a control system 602 that includes one or more processors 604 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and / or the like), memory / computer readable storage medium 606, and a network interface 608. The one or more processors 604 are also referred to herein as processing circuitry.

[0091] The one or more processors 604 operate to provide one or more functions of a radio access node 600 as described herein. In some embodiments, the function(s) are implemented in one or more computer programs 610 that are stored, e.g., in the memory 606 and executed by the one or more processors 604.

[0092] Figure 7 is a schematic block diagram that illustrates a virtualized embodiment of the network node 600 according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes. Further, other types of network nodes may have similar virtualized architectures. Again, optional features are represented by dashed boxes.

[0093] As used herein, a "virtualized" network node is an implementation of the network node 600 in which at least a portion of the functionality of the network node 600 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the network node 600 may include the control system 602 and / or the one or more radio units 610, as described above. The control system 602 may be connected to the radio unit(s) 610 via, for example, an optical cable or the like. The network node 600 includes one or more processing nodes 700 coupled to or included as part of a network(s) 702. If present, the control system 602 or the radio unit(s) are connected to the processing node(s) 700 via the network 702. Each processing node 700 includes one or more processors 704 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory / computer readable storage medium 706, and a network interface 708.

[0094] In this example, functions 710 of the network node 600 described herein are implemented at the one or more processing nodes 700 or distributed across the one or more processing nodes 700 and the control system 602 and / or the radio unit(s) 610 in any desired manner. In some particular embodiments, some or all of the functions 710 of the network node 600 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 700. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 700 and the control system 602 is used in order to carry out at least some of the desired functions 710. Notably, in some embodiments, the control system 602 may not be included, in which case the radio unit(s) 610 communicates directly with the processing node(s) 700 via an appropriate network interface(s).

[0095] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of network node 600 or a node (e.g., a processing node 700) implementing one or more of the functions 710 of the network node 600 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0096] Figure 8 is a schematic block diagram of the network node 600 according to some other embodiments of the present disclosure. The network node 600 includes a LMISF device 202 which is implemented in software. The LMISF device 202 provides the functionality of the network node 600 described herein. This discussion is equally applicable to the processing node 700 of Figure 7 where the LMISF device 202 may be implemented at one of the processing nodes 700 or distributed across multiple processing nodes 700 and / or distributed across the processing node(s) 700 and the control system 602.

[0097] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0098] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0099] At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).

[0100] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

Claims

Claims1. A method for identifying that Session Initiation Protocol, SIP, message encryption is enabled for a Voice over Long Term Evolution, VoLTE, communication from an inbound roaming device (106) performed by a Lawful Intercept, LI, Mirror Internet Protocol, IP, Multimedia Subsystem, IMS, State Function, LMISF, device, (202) the method comprising: receiving (308, 404) a registration response message, wherein the registration response message comprises a security field; based on the security field, determining (406) whether the inbound roaming device (106) is configured to enable SIP message encryption; in response to determining that SIP message encryption is enabled, determining (408) a roaming operator domain based on the registration response message; and providing (410) an alert to a communication service provider indicating that the roaming operator domain enables SIP message encryption.

2. The method of claim 1, further comprising: receiving (304, 402), prior to receiving the registration response message, a registration request message associated with the inbound roaming device (106).

3. The method of any of claims 1 to 2, wherein the registration response message and the registration request message are received from a Bearer Binding Intercept and Forwarding Function, BBIFF, device that is an intermediary between the inbound roaming device (106) and a Proxy Call Session Control Function, P-CSCF, device (303) associated with the communication service provider.

4. The method of claim 3, wherein the registration request message was sent from the inbounding roaming device to the P-CSCF device (303), and the registration response message was sent from the P-CSCF device (303) to the inbound roaming device (106).

5. The method of any of claims 1 to 4, wherein the security field includes one of: a parameter indicating a supported encryption algorithm; a parameter indicating no supported encryption algorithm; orno parameter indicating a supported encryption algorithm.

6. The method of claim 5, wherein the determining that SIP message encryption is enabled is based on the security field comprising the parameter indicating the supported encryption algorithm.

7. The method of claim 5, further comprising: determining (412) that the inbound roaming device (106) is not configured to enable SIP message encryption based on the security field comprising the parameter indicating no supported encryption algorithm, or not comprising the parameter indicating a supported encryption algorithm.

8. The method of claim 5, in response to determining that the inbound roaming device (106) is not configured to enable SIP message encryption, taking no further action.

9. The method of any of claims 1 to 8, wherein the registration response message is an Authentication Challenge response.

10. The method of any of claims 1 to 9, wherein determining a roaming operator domain is based on a From header value that comprises an IP Multimedia Private Identity, IMPI, associated with a user of the inbound roaming device (106).

11. A network node (600) that implements a Lawful Intercept, LI, Mirror Internet Protocol, IP, Multimedia Subsystem, IMS, State Function, LMISF, device, (202) that is configured to identify that Session Initiation Protocol, SIP, message encryption is enabled for a Voice over Long Term Evolution, VoLTE, communication from an inbound roaming device (106), the network node comprising processing circuitry configured to cause the network node to: receive (308, 404) a registration response message, wherein the registration response message comprises a security field; based on the security field, determine (406) whether the inbound roaming device (106) is configured to enable SIP message encryption;in response to determining that SIP message encryption is enabled, determine (408) a roaming operator domain based on the registration response message; and provide (410) an alert to a communication service provider indicating that the roaming operator domain enables SIP message encryption.

12. The network node (600) of claim 11, wherein the processing circuitry is further configured to: receive (304, 402), prior to receiving the registration response message, a registration request message associated with the inbound roaming device (106).

13. The network node (600) of any of claims 11 to 12, wherein the registration response message and the registration request message are received from a Bearer Binding Intercept and Forwarding Function, BBIFF, device that is an intermediary between the inbound roaming device (106) and a Proxy Call Session Control Function, P-CSCF, device associated with the communication service provider.

14. The network node (600) of claim 13, wherein the registration request message was sent from the inbounding roaming device to the P-CSCF device, and the registration response message was sent from the P-CSCF device to the inbound roaming device (106).

15. The network node (600) of any of claims 11 to 14, wherein the security field includes one of: a parameter indicating a supported encryption algorithm; a parameter indicating no supported encryption algorithm; or no parameter indicating a supported encryption algorithm.

16. The network node (600) of claim 15, wherein the determining that SIP message encryption is configured enabled is based on the security field comprising the parameter indicating the supported encryption algorithm.

17. The network node (600) of claim 15, wherein the processing circuitry is further configured to:determine (412) that the inbound roaming device (106) is not configured to enable SIP message encryption based on the security field comprising the parameter indicating no supported encryption algorithm, or not comprising the parameter indicating a supported encryption algorithm.

18. The network node (600) of claim 15, in response to determining that the inbound roaming device (106) is not configured to enable SIP message encryption, the processing circuitry is further configured to take no further action.

19. The network node (600) of any of claims 11 to 18, wherein the registration response message is an Authentication Challenge response.

20. The network node (600) of any of claims 11 to 19, wherein determining a roaming operator domain is based on a From header value that comprises an IP Multimedia Private Identity, IMPI, associated with a user of the inbound roaming device (106).

21. A computer program (610) comprising instructions which, when executed on at least one processor (604), cause the processor to carry out the method according to any of claims 1 to 10.

22. A carrier containing the computer program of claim 21, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (606).

Images