Security management for local service access in femtocells

Abstract

Techniques are disclosed for security management techniques in a communication network environment. For example, a method includes generating, at user equipment associated with a communication network, a service request message, the service request message comprising an identifier associated with a femtocell device in the communication network and an indication that local service access is to be provided by the femtocell device. The method also includes sending, from the user equipment to the femtocell device, the service request message. The method may also include receiving a service reject message, the service reject message comprising a cause value indicating that the service request is rejected due to the femtocell device not being authorized for the local service access.

Description

[0001] SECURITY MANAGEMENT FOR LOCAL SERVICE ACCESS IN FEMTOCELLS

[0002] Field

[0003] The field relates generally to communication networks, and more particularly, but not exclusively, to security management in such communication networks.

[0004] Background

[0005] This section introduces aspects that may be helpful in facilitating a better understanding of the inventions. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

[0006] Fourth generation (4G) wireless mobile telecommunications technology, also known as Long Term Evolution (LTE) technology, was designed to provide high-capacity mobile multimedia with high data rates particularly for human interaction. Next generation or fifth generation (5G) technology is intended to be used not only for human interaction, but also for machine type communications in so-called Internet of Things (loT) networks.

[0007] While 5G networks are intended to enable massive loT services (e.g., very large numbers of limited capacity devices) and mission-critical loT services (e.g., requiring high reliability), improvements over legacy mobile communication services are supported in the form of enhanced mobile broadband (eMBB) services providing improved wireless Internet access for mobile devices.

[0008] In an example communication system, user equipment (5G UE in a 5G network or, more broadly, a UE) such as a mobile terminal (subscriber) communicates over an air interface with a base station or access point of an access network referred to as a 5G AN in a 5G network. The access point (e.g., gNB) is illustratively part of an access network of the communication system.

[0009] For example, in a 5G network, the access network referred to as a 5G AN is described in 5G Technical Specification (TS) 23.501, entitled “Technical Specification Group Services and System Aspects; System Architecture for the 5G System,” and TS 23.502, entitled “Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS),” the disclosures of which are incorporated by reference herein in their entireties. In general, the access point (e.g., gNB) provides access for the UE to a core network (CN or 5GC), which then provides access for the UE to other UEs and / or a data network such as a packet data network (e.g., Internet).

[0010] TS 23.501 goes on to define a 5G Service-Based Architecture (SBA) which models services as network functions (NFs) that communicate with each other using representational state transfer application programming interfaces (Restful APIs).

[0011] Furthermore, TS 33.501, entitled “Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System,” the disclosure of which is incorporated by reference herein in its entirety, further describes security management details associated with a 5G network.

[0012] Security management is an important consideration in any communication network environment. However, due to continuing attempts to improve the architectures and protocols associated with a 5G network, and / or other networks, in order to increase network efficiency and / or subscriber convenience, security management issues associated with one or more access control protocol layers of the communication network environment can present a significant technical challenge.

[0013] Summary

[0014] Illustrative embodiments provide security management techniques associated with local service access in femtocells. While illustrative embodiments are described herein in the context of femtocell devices in next generation or fifth generation (5G) communication network environments, it is to be appreciated that one or more security management techniques described herein can be applied in other communication network environments.

[0015] By way of example, in one or more other illustrative embodiments, a method includes generating, at user equipment associated with a communication network, a service request message, the service request message comprising an identifier associated with a femtocell device in the communication network and an indication that local service access is to be provided by the femtocell device, and sending, from the user equipment to the femtocell device, the service request message.

[0016] By way of further example, in one or more other illustrative embodiments, a method includes receiving, at a core network entity in a communication network, a service request message generated by user equipment, the service request message comprising an identifier associated with a femtocell device in a communication network, an indication that local service access is to be provided by the femtocell device, and an indication of secondary authentication to be performed responsive to determining that the femtocell device is authorized for the local service access, determining, at the core network entity, whether the femtocell device is authorized for the local service access, responsive to determining that the femtocell device is authorized for the local service access, performing the secondary authentication to determine whether the user equipment is authorized for the local service access and, responsive to determining that the femtocell device is not authorized for the local service access, sending a service reject message.

[0017] Advantageously, illustrative embodiments provide for enabling enhanced femtocell authorization for local service access scenarios, and for enhancing secondary authentication when user equipment connects with a femtocell device for local service access.

[0018] Further illustrative embodiments are provided in the form of a non-transitory computer readable medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above and / or other steps, operations, and the like. Still further illustrative embodiments comprise an apparatus with a processor and a memory configured to perform the above and / or other steps, operations, and the like. Some illustrative embodiments comprise a system configured to perform the above and / or other steps, operations, and the like. Further, some illustrative embodiments comprise an apparatus or a system comprising means for performing the above and / or other steps, operations, and the like.

[0019] These and other features and advantages of embodiments described herein will become more apparent from the accompanying drawings and the following detailed description.

[0020] Brief Description of the Drawings

[0021] FIG. 1 illustrates a communication network environment with which one or more illustrative embodiments may be implemented.

[0022] FIG. 2 illustrates user equipment and entities with which one or more illustrative embodiments may be implemented.

[0023] FIG. 3 illustrates a process flow for performing security for local services in a femtocell during packet data unit session establishment procedures according to an illustrative embodiment.

[0024] FIG. 4 illustrates a table of femtocell access modes provided in a system information block message according to an illustrative embodiment. FIG. 5 illustrates derivation of a femtocell identifier from a system information block message according to an illustrative embodiment.

[0025] FIG. 6 shows a table of cause attribute application errors including an unauthorized or compromised femtocell device according to an illustrative embodiment.

[0026] FIG. 7 shows a table of application error descriptions including an unauthorized or compromised femtocell device application error according to an illustrative embodiment.

[0027] FIG. 8 shows a table of information elements for packet data unit session establishment reject message content according to an illustrative embodiment.

[0028] FIG. 9 shows a table of session management cause values including a cause value for a femtocell that is not authorized for local services according to an illustrative embodiment.

[0029] FIG. 10 illustrates a process flow for performing security for local services in a femtocell during service request procedures according to an illustrative embodiment.

[0030] FIG. 11 shows a table of information elements for service request reject message content according to an illustrative embodiment.

[0031] FIG. 12 shows a table of mobility management cause values including a cause value for a femtocell that is not authorized for local services according to an illustrative embodiment.

[0032] Detailed Description

[0033] Embodiments will be illustrated herein in conjunction with example communication systems and associated techniques for security management in communication systems. It should be understood, however, that the scope of the claims is not limited to particular types of communication systems and / or processes disclosed. Embodiments can be implemented in a wide variety of other types of communication systems, using alternative processes and operations. For example, although illustrated in the context of wireless cellular systems utilizing the 3rd Generation Partnership Project (3GPP) system elements such as a 3GPP next generation system (5G), the disclosed embodiments can be adapted in a straightforward manner to a variety of other types of communication systems such as 6G communication systems.

[0034] In accordance with illustrative embodiments implemented in a 5G communication system environment, one or more 3 GPP technical specifications (TS) and technical reports (TR) may provide further explanation of network elements / functions and / or operations that may interact with parts of the inventive solutions, e.g., the above-referenced 3GPP TS 23.501, TS 23.502, and TS 33.501. Other 3GPP TS / TR documents may provide other details that one of ordinary skill in the art will realize, for example, TS 23.548 entitled “Technical Specification Group Services and System Aspects; 5G System Enhancements for Edge Computing; Stage 2,” TS 24.501 entitled “Technical Specification Group Core Network and Terminals; Non- Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3,” TS 29.502 entitled “Technical Specification Group Core Network and Terminals; 5G System; Session Management Services; Stage 3,” and TR 33.745 entitled “Technical Specification Group Services and System Aspects; Study on security aspects of 5G NR Femto,” the disclosures of which are incorporated by reference herein in their entireties. Note that 3 GPP TS / TR documents are non-limiting examples of communication network standards (e.g., specifications, procedures, reports, requirements, recommendations, and the like). However, while well-suited for 5G-related 3 GPP standards, embodiments are not necessarily intended to be limited to any particular standards.

[0035] It is to be understood that the term 5G network, and the like (e.g., 5G system, 5G communication system, 5G environment, 5G communication environment etc.), in some illustrative embodiments, may be understood to comprise all or part of an access network and all or part of a core network. However, the term 5G network, and the like, may also occasionally be used interchangeably herein with the term 5GC network, and the like, without any loss of generality, since one of ordinary skill in the art understands any distinctions.

[0036] Prior to describing illustrative embodiments, a general description of certain main components of a 5G network will be described below in the context of FIGS. 1 and 2.

[0037] FIG. 1 shows a communication system 100 within which illustrative embodiments are implemented. It is to be understood that the elements shown in communication system 100 are intended to represent some main functions provided within the system, e.g., control plane functions, user plane functions, etc. As such, the blocks shown in FIG. 1 reference specific elements in 5G networks that provide some of these main functions. However, other network elements may be used to implement some or all of the main functions represented. Also, it is to be understood that not all functions of a 5G network are depicted in FIG. 1. Rather, at least some functions that facilitate an explanation of illustrative embodiments are represented. Subsequent figures may depict some additional elements / functions (i.e., network entities).

[0038] Accordingly, as shown, communication system 100 comprises user equipment (UE) 102 that communicates via an air interface 103 with an access point 104 (e.g., a base station such as a Next Generation Node B (gNB) base station). It is to be understood that UE 102 may use one or more other types of access points (e.g., access functions, networks, etc.) to communicate with the 5GC network other than a gNB. By way of example only, the access point 104 may be any 5G access network (gNB) including a home gNB (HgNB) (e.g., an in- home or personal base stations such as a femtocell device, also referred to as a femto device, a femto node, a femto base station), an untrusted non-3GPP access network that uses an Non- 3GPP Interworking Function (N3IWF), a trusted non-3GPP network that uses a Trusted Non- 3 GPP Gateway Function (TNGF) or wireline access that uses a Wireline Access Gateway Function (W-AGF) or may correspond to a legacy access point (e.g., an evolved Node B (eNB) base station). Furthermore, access point 104 may be a wireless local area network (WLAN) access point.

[0039] The UE 102 may be a mobile station, and such a mobile station may comprise, by way of example, a mobile telephone, a computer, an loT device, or any other type of communication device. The term “user equipment” as used herein is therefore intended to be construed broadly, so as to encompass a variety of different types of mobile stations, subscriber stations or, more generally, communication devices, including examples such as a combination of a data card inserted in a laptop or other equipment such as a smart phone. Such communication devices are also intended to encompass devices commonly referred to as access terminals.

[0040] In one illustrative embodiment, UE 102 is comprised of a Universal Integrated Circuit Card (UICC) part and a Mobile Equipment (ME) part. The UICC is the user-dependent part of the UE and contains at least one Universal Subscriber Identity Module (USIM) and appropriate application software. The USIM securely stores a permanent subscription identifier and its related key, which are used to uniquely identify and authenticate subscribers to access networks. The ME is the user-independent part of the UE and contains terminal equipment (TE) functions and various mobile termination (MT) functions. Alternative illustrative embodiments may not use UICC-based authentication, e.g., a Non-Public (Private) Network (NPN).

[0041] Note that, in one example, the permanent subscription identifier is an International Mobile Subscriber Identity (IMSI) unique to the UE. In one embodiment, the IMSI is a fixed 15-digit length and consists of a 3-digit Mobile Country Code (MCC), a 3-digit Mobile Network Code (MNC), and a 9-digit Mobile Station Identification Number (MSIN). In a 5G communication system, an IMSI is referred to as a Subscription Permanent Identifier (SUPI). In the case of an IMSI as a SUPI, the MSIN provides the subscriber identity. Thus, only the MSIN portion of the IMSI typically needs to be encrypted. The MNC and MCC portions of the IMSI provide routing information, used by the serving network to route to the correct home network. When the MSIN of a SUPI is encrypted, it is referred to as Subscription Concealed Identifier (SUCI). Another example of a SUPI uses a Network Access Identifier (NAI). NAI is typically used for loT communication.

[0042] The access point 104 is illustratively part of a radio access network or RAN of the communication system 100. Such a radio access network may comprise, for example, a 5G System having a plurality of base stations. Components of a radio access network may, more generally, be considered “radio access entities.”

[0043] Further, the access point 104 in this illustrative embodiment is operatively coupled to an Access and Mobility Management Function (AMF) 106. In a 5G network, the AMF 106 supports, inter alia, mobility management (MM) and security anchor (SEAF) functions.

[0044] AMF 106 in this illustrative embodiment is operatively coupled to (e.g., uses the services of) other network functions 108. Other network functions 108 may include Unified Data Management (UDM), Unified Data Repository (UDR), Authentication Server Function (AUSF), Authentication Credential Repository and Processing Function (ARPF), Subscription Identifier De-concealing Function (SIDF), and other network functions that can act as service producers (NFp) and / or service consumers (NFc). Note that any network function can be a service producer for one service and a service consumer for another service. Further, when the service being provided includes data, the data-providing NFp is referred to as a data producer, while the data-requesting NFc is referred to as a data consumer. A data producer may also be an NF that generates data by modifying or otherwise processing data produced by another NF. Note that NFs may, more generally, be considered “network entities” whereby a network entity that consumes one or more of data and a service can be considered a “consumer network entity” and a network entity that produces one or more of data and a service can be considered a “producer network entity.”

[0045] Note that a UE, such as UE 102, is typically subscribed to what is referred to as a Home Public Land Mobile Network (HPLMN) in which some or all of the functions 106 and 108 reside. Alternatively the UE, such as UE 102, may receive services from an NPN where these functions may reside. The HPLMN is also referred to as the Home Environment (HE). If the UE is roaming (not in the HPLMN), it is typically connected with a Visited Public Land Mobile Network (VPLMN) also referred to as a visited network, while the network that is currently serving the UE is also referred to as a serving network. In the roaming case, some of the functions 106 and 108 can reside in the VPLMN, in which case, functions in the VPLMN communicate with functions in the HPLMN as needed. However, in a non-roaming scenario, access and mobility management functions 106 and the other network functions 108 reside in the same communication network, i.e., HPLMN. Embodiments described herein, unless otherwise specified, are not necessarily limited by which functions reside in which PLMN (i.e., HPLMN or VPLMN).

[0046] The access point 104 is also operatively coupled (via one or more of functions 106 and / or 108) to a Session Management Function (SMF) 110, which is operatively coupled to a User Plane Function (UPF) 112. UPF 112 is operatively coupled to a Packet Data Network, e.g., Internet 114. Note that the thicker solid lines in this figure denote a user plane (UP) of the communication network, as compared to the thinner solid lines that denote a control plane (CP) of the communication network. It is to be appreciated that Internet 114 in FIG. 1 may additionally or alternatively represent other network infrastructures including, but not limited to, cloud computing infrastructure and / or edge computing infrastructure. Further typical operations and functions of such network elements are not described here since they are not the focus of the illustrative embodiments and may be found in appropriate 3GPP 5G documentation. Note that functions shown in 106, 108, 110 and 112 are examples of network functions (NFs).

[0047] It is to be appreciated that this particular arrangement of system elements is an example only, and other types and arrangements of additional or alternative elements can be used to implement a communication system in other embodiments. For example, in other embodiments, the communication system 100 may comprise other elements / functions not expressly shown herein.

[0048] Accordingly, the FIG. 1 arrangement is just one example configuration of a wireless cellular system, and numerous alternative configurations of system elements may be used. For example, although only single elements / functions are shown in the FIG. 1 embodiment, this is for simplicity and clarity of description only. A given alternative embodiment may of course include larger numbers of such system elements, as well as additional or alternative elements of a type commonly associated with conventional system implementations.

[0049] It is also to be noted that while FIG. 1 illustrates system elements as singular functional blocks, the various subnetworks that make up the 5G network are partitioned into so-called network slices. Network slices (network partitions) are logical networks that provide specific network capabilities and network characteristics that can support a corresponding service type, optionally using network function virtualization (NFV) on a common physical infrastructure. With NFV, network slices are instantiated as needed for a given service, e.g., eMBB service, massive loT service, and mission-critical loT service. A network slice or function is thus instantiated when an instance of that network slice or function is created. In some embodiments, this involves installing or otherwise running the network slice or function on one or more host devices of the underlying physical infrastructure. UE 102 is configured to access one or more of these services via access point 104.

[0050] FIG. 2 is a block diagram illustrating computing architectures for various participants in methodologies according to illustrative embodiments. More particularly, system 200 is shown comprising user equipment (UE) 202 and a plurality of entities 204-1, . . . . , 204-N. For example, in illustrative embodiments and with reference back to FIG. 1, UE 202 can represent UE 102, while entities 204-1, . . . , 204-N can represent functions 106 and 108 (i.e., network entities such as, but not limited to, AMF, UDM / UDR, AUSF, SMF, UPF, ARPF, SIDF, etc ), as well as access point 104 (i.e., radio access entity such as, but not limited to, a RAN node or gNB, a HgNB or Femto device, etc.). It is to be appreciated that the UE 202 and entities 204- 1, . . . . , 204-N are configured to interact to provide security management and other techniques described herein.

[0051] The user equipment 202 comprises a processor 212 coupled to a memory 216 and interface circuitry 210. The processor 212 of the user equipment 202 includes a security management processing module 214 that may be implemented at least in part in the form of software executed by the processor. The security management processing module 214 performs security management described in conjunction with subsequent figures and otherwise herein. The memory 216 of the user equipment 202 includes a security management storage module 218 that stores data generated or otherwise used during security management operations.

[0052] Each of the entities (individually or collectively referred to herein as 204) comprises a processor 222 (222-1, . . . , 222 -N) coupled to a memory 226 (226-1, . . . , 226-N) and interface circuitry 220 (220-1, . . . , 220-N). Each processor 222 of each entity 204 includes a security management processing module 224 (224-1, . . . , 224-N) that may be implemented at least in part in the form of software executed by the processor 222. The security management processing module 224 performs security management operations described in conjunction with subsequent figures and otherwise herein. Each memory 226 of each entity 204 includes a security management storage module 228 (228-1, . . . , 228-N) that stores data generated or otherwise used during security management operations.

[0053] The processors 212 and 222 may comprise, for example, microprocessors such as central processing units (CPUs), application-specific integrated circuits (ASICs), digital signal processors (DSPs) or other types of processing devices, as well as portions or combinations of such elements.

[0054] The memories 216 and 226 may be used to store one or more software programs that are executed by the respective processors 212 and 222 to implement at least a portion of the functionality described herein. For example, security management operations and other functionality as described in conjunction with subsequent figures and otherwise herein may be implemented in a straightforward manner using software code executed by processors 212 and 222.

[0055] A given one of the memories 216 and 226 may therefore be viewed as an example of what is more generally referred to herein as a computer program product or still more generally as a computer or processor readable (non-transitory or storage) medium that has executable program code embodied therein. Other examples of computer or processor readable media may include disks or other types of magnetic or optical media, in any combination. Illustrative embodiments can include articles of manufacture comprising such computer program products or other computer or processor readable media.

[0056] Further, the memories 216 and 226 may more particularly comprise, for example, electronic random-access memory (RAM) such as static RAM (SRAM), dynamic RAM (DRAM) or other types of volatile or non-volatile electronic memory. The latter may include, for example, non-volatile memories such as flash memory, magnetic RAM (MRAM), phasechange RAM (PC-RAM) or ferroelectric RAM (FRAM). The term “memory” as used herein is intended to be broadly construed, and may additionally or alternatively encompass, for example, a read-only memory (ROM), a disk-based memory, or other type of storage device, as well as portions or combinations of such devices.

[0057] The interface circuitries 210 and 220 illustratively comprise transceivers or other communication hardware or firmware that allows the associated system elements to communicate with one another in the manner described herein. It is apparent from FIG. 2 that user equipment 202 and plurality of entities 204 are configured for communication with each other as security management participants via their respective interface circuitries 210 and 220. This communication involves each participant sending data to and / or receiving data from one or more of the other participants. The term “data” as used herein is intended to be construed broadly, so as to encompass any type of information that may be sent between participants including, but not limited to, identity data, key pairs, key indicators, tokens, secrets, security management messages, registration request / response messages and data, request / response messages, authorization and / or authentication request / response messages and data, metadata, control data, audio, video, multimedia, consent data, other messages, etc.

[0058] It is to be appreciated that the particular arrangement of components shown in FIG. 2 is an example only, and numerous alternative configurations may be used in other embodiments. For example, any given network element / function and / or access point can be configured to incorporate additional or alternative components and to support other communication protocols.

[0059] Other system elements such as access point 104, SMF 110, and UPF 112 may each be configured to include components such as a processor, memory and network interface. Also, entities such as third-party applications and network operators can participate in methodologies described herein via computing devices configured to include components such as a processor, memory and network interface. These elements and devices need not be implemented on separate stand-alone processing platforms, but could instead, for example, represent different functional portions of a single common processing platform.

[0060] More generally, FIG. 2 can be considered to represent processing devices configured to provide respective security management functionalities and operatively coupled to one another in a communication system. By way of example only, all or parts of each of UE 202 and the plurality of entities 204 (e.g., processor and memory) can be considered examples of means for performing one or more operations, one or more steps, one or more functions, one or more processes, etc. as described herein.

[0061] Given the above-described illustrative communication network environments, some realizations regarding communication network architectures that may be implemented therein, such as a 5G New Radio (NR) architecture, are now described. In 5G, a Closed Access Group (CAG) identifies a group of subscribers who are permitted or allowed to access one or more CAG cells associated to the CAG identifier (ID) of the CAG. A CAG cell is a cell that broadcasts one or several CAG IDs. Security concerns for CAGs include determining whether, and how, to enable the provisioning of subscribers that are allowed to access a CAG cell, as well as managing access control by a CAG owner or an authorized administrator.

[0062] Non-Public Networks (NPN), also referred to as private networks, are networks which are intended for non-public or private use. In some communication systems, a public mobile network may provide services and functionality for operating an NPN, in what is referred to as a Public Network Integrated NPN (PNI-NPN). In PNI-NPN, CAG identifies a group of subscribers that are permitted or allowed to access one or more CAG cells of the PLMN identified by CAG IDs. Such PNI-NPN functionality may also be used for 5G Femto access control. As noted above, a CAG cell broadcasts one or several CAG IDs. A small base station broadcasting CAG IDs is called a Femto base station (also referred to as a home base station, a HgNB, a personal base station, a femtocell device, a femto device, etc.). CAG membership of a UE is configured in the user subscription data and on the UE. If a UE is roaming, the access control should be performed in the visited network based on CAG IDs configured in the VPLMN, and the UE needs to be provisioned with access information for allowed visited CAG cells in the visited network.

[0063] Various 3GPP TS / TR documents, including TS 23.501, TS 23.502 and TS 24.501, describe aspects of PNI-NPN and CAG cells, CAG information changes in the HPLMN and CAG specifications. 3GPP TS 23.501 and 3GPP TS 23.502 further describe aspects of secondary authentication and authorization by a Data Network Authentication, Authorization and Accounting (DN-AAA) server during the establishment of a Packet Data Unit (PDU) session, including indication of PDU session establishment rejection which is transferred by an SMF to the UE via the NAS Session Management (SM) protocol. 3GPP TS 23.502 also describes aspects of non-roaming and roaming with local breakout, and 3GPP TS 23.548 describes aspects of 5GC connectivity models for edge computing. 3GPP TS 33.501 describes aspects of security for accessing a localized service, as well as primary authentication and key agreement.

[0064] 5G systems should ensure that the connectivity models used for local access are secure and do not leak privacy details to any intruder. Femto devices are deployed at user locations, and it is thus important to ensure that there are no malicious or compromised femto devices to which an operator is providing services, and to ensure that UEs do not get services from malicious or compromised femto devices.

[0065] Illustrative embodiments overcome the above and other technical challenges associated with local service access, including femto authorization for local service access, by providing improved security management techniques for the authorization of femto devices in local breakout (LBO) roaming access scenarios.

[0066] For example, some illustrative embodiments provide solutions for femto device authorization for local service access before secondary authentication of UE requesting local services. In some embodiments, the solutions are based on service request procedures, where service requests originating from UEs that are meant for local service access (e.g., LBO cases) are detected and secured, and where the service requests are sent to the core network via untrusted femto devices. In other embodiments, the solutions are based on PDU session establishment procedures, where PDU sessions that are meant for local service access (e.g., LBO cases) and which are initiated using untrusted femto devices are detected and secured. Secondary authentication is enhanced for such service requests related to local service access and / or PDU session establishment for local service access. If the secondary authentication fails, the UEs are safeguarded against malicious or compromised femto devices.

[0067] For the solutions based on PDU session establishment procedures, when a UE initiates a secondary authentication procedure (e.g., for local service access), the femto ID of the femto device used for requesting establishment of the PDU session and a femto indication are included in the initial message. The AMF sends the femto ID and the femto indication parameters to the SMF. The SMF gets the femto details using the femto ID from the UDR. The UDR searches for the femto details, and sends the details to the SMF. The SMF checks whether the details exist and, if the details exist, whether the details show that the femto is allowed to be used in the PDU session establishment procedure for local service access.

[0068] If the SMF does not get details from the UDR (e.g., the UDR does not have any details for the femto ID included in the PDU sessions establishment request), the SMF sends an error code to the AMF to indicate that the femto is unauthorized. The AMF will send a NAS message (e.g., a downlink (DL) NAS Transport or PDU Session Establishment Reject message) with an error information element (IE) indicating that the femto is unauthorized. Alternatively, the femto can send the message to the UE with the femto unauthorized indication in a SIB, Media Access Control (MAC) Control Element (MAC-CE), or Downlink Control Information (DCI) message. The UEs may remove the femto ID after receiving the femto unauthorized indication, so that the UEs do not attempt to connect to the femto device associated with that femto ID when requesting access to local services.

[0069] If the SMF gets details from the UDR, the SMF further checks the LBO Roaming Information in the UE subscription data. If allowed and the PDU session establishment is from femto, the SMF will trigger the secondary authentication. The SMF creates an N4 session with the UPF by including the femto indicator and an LBO indicator (Ibolndicator) in an N4 Session Establishment Request message. After (successful) secondary authentication, the UPF has learnt that the PDU session is from the femto and is meant for the local services (e.g., LBO), and thus enforces security mechanisms like Transport Layer Security (TLS), Internet Protocol Security (IPsec), etc.

[0070] Advantageously, the solutions described herein enhance femto authorization for local service access (e.g., LBO) scenarios and further enable secondary authentication for when a UE connects with a femto device for local service access requests.

[0071] In the description below, the terms femtocell device, femto device, femto node, femto, HgNB and 5G NR Femto are used interchangeably.

[0072] FIG. 3 shows a process flow 300 for providing security for local services in a communication system including a UE 301, a femtocell device 303 (also referred to as Femto 303), a visited AMF (V-AMF) 305 supporting SEAF functionality, a visited UDM / UDR (VUDM / UDR) 307 supporting ARPF / SIDF functionality, a visited AUSF (V-AUSF) 309, a visited SMF (V-SMF) 311 supporting authenticator functionality, a visited UPF (V-UPF) 313, and a DN-AAA 315. The process flow 300 includes steps 0a, 0b and 1-23. Step 0a includes a pre-condition that an operator has provisioned or preconfigured HgNB or femto details for each HgNB or femto device in the VUDM / UDR 307. Such HgNB or femto details may include, but are not limited to, a HgNB ID (HgNB ID), a supported CAG ID list (supportedCagldList), location information (Locationinfo), access mode (accessMode), femto indication (FemtoIndication) and secondary authentication indication ( Secondary Authlndi cation) parameters. Step 0b includes the UE 301 performing a primary authentication with the V- AUSF 309 during registration of the UE 301 with the network. This primary authentication may, in some embodiments, be in accordance with 3GPP TS 33.501 clause 6.1. Steps 0a and 0B are prerequisites that are assumed to be performed prior to steps 1-23 described below. Step 1 : The UE 301 sends a PDU Session Establishment Request to the Femto 303. The UE 301 adds HgNBID, FemtoIndication and Secondary Authlndication parameters to the PDU Session Establishment Request. The UE 301 learns about the Femto 303 from a SIB message, and learns about the femto access mode based on the table 400 shown in FIG. 4 which may be included in the SIB message. The table 400 includes columns for CAG IDs, an indication of whether the CAG cell is reserved for other use (cellReservedForOtherUse) and the Femto Access Mode. The UE 301 may derive the HgNBID / Femto ID from an SIB1 message using the cell Identity parameter (e.g., SIBl->CellAccessRelatedInfo- PLMN- IdentityInfoList->PLMN-IdentityInfo->cell Identity) as illustrated in FIG. 5. FIG. 5 shows an example cell Identity parameter 500 for 5GNR SIB1 and the gNodeB ID length. The NR-Cell Identity (NCI) identifies an NR cell within a PLMN, and has a length of 36 bits. The NCI may be based on a gNB Identity (gNB ID) and a Cell Local ID (cellLocalld). The gNB ID identifies a gNB within a PLMN, and has a length with a minimum of 22 bits and a maximum of 32 bits. The cellLocalld identifies a NR cell of a gNB, and has a length with a minimum of 4 bits and a maximum of 14 bits. The Physical Cell Identity (PCI) is visible only at the 5gNB level. The NCI is unique at the PLMN, and is visible at the AMF / SMF level. The Cell Global Identity (CGI) is globally unique and is visible across networks and PLMNs. If the UE 301 is attaching to the Femto 303 (where the UE 301 learns of the Femto node based on the above information), then the Secondary Authlndication parameter may be mandatorily added by the UE 301 to the PDU Session Establishment Request (or Service Request) message that is sent to the network (e.g., to the Femto 303).

[0073] Step 2: The Femto 303 sends an Initial UE Message to the V-AMF 305. The Initial UE Message includes the NAS-PDU (e.g., the PDU Session Establishment Request Message) received from the UE 301 in Step 1.

[0074] Step 3: The V-AMF 305 initiates a Nsmf_PDUSession_CreateSMContext Request with the HgNBID, FemtoIndication and Secondary Authlndi cation parameters, and sends the Nsmf_PDUSession_CreateSMContext Request to the V-SMF 311, which acts as an authenticator.

[0075] Step 4: The V-SMF 311 retrieves the femto details from the VUDM / UDR 307 using a new application programming interface, an Nudr FemtoDetails Get Request message. The HgNBID is used as the data key. Step 5: The VUDM / UDR 307 searches for the femto details using the HgNBID as the data key.

[0076] Step 6: The VUDM / UDR 307 sends a Nudr FemtoDetails Get Response message to the V-SMF 311. The Nudr FemtoDetails Get Response message includes the HgNBID and FemtoDetails. The FemtoDetails may include parameters or information such as the supported CAG ID list, access mode, femto indicator, HgNBID, etc.

[0077] Step 7: The V-SMF 311 checks whether the HgNBID and its details exist from the Nudr FemtoDetails Get Response message content received from the VUDM / UDR 307. If femto details are present for the HgNBID included in the PDU Session Establishment Request message of Step 1, then the process flow 300 continues with secondary authentication. Otherwise, the PDU Session Establishment procedure is aborted by indicating a proper error code. This step also includes the V-SMF 311 checking whether the Femto 303 is authorized to get the requested local services from the 5G Core Network or not. If Step 7 fails, the process flow 300 proceeds with Steps 8-15. If Step 7 passes, the process flow proceeds with Steps 16- 23.

[0078] Step 8: The V-SMF 311 sends an Nsmf PDUSession CreateSMContext Response message to the V-AMF 305, where the Nsmf_PDUSession_CreateSMContext Response message includes a novel error code in the SmContextCreateError data structure of the POST Response Body. The novel error code indicates the cause (e.g., of failure of the PDU Session Establishment) as being a result of an unauthorized or compromised femto. FIG. 6 shows a table 600 of data structures supported by the POST Response Body (i.e., 3GPP TS 29.502 Table 6.1.3.2.3.1-3) where the novel error code for an unauthorized or compromised femto “UNAUTHORIZED OR COMPROMISED FEMTO DEVICE” is added to a list of application errors which may be used for the “cause” attribute of the SmContextCreateError data structure. FIG. 7 shows a table 700 of application errors (i.e., 3GPP TS 29.502 Table 6.1.7.3-1) with an added application error entry for the unauthorized or compromised femto application error “UNAUTHORIZED OR COMPROMISED FEMTO DEVICE” along with its HTTP status code (403 Forbidden) and its description indicating that this application error is used when the Femto / HgNBID details are not found in the UDR, and that this check is done to decide whether a UE shall proceed for secondary authentication or not.

[0079] Following Step 8, the process flow 300 may proceed with Option 1 (Steps 9-13) and / or Option 2 (Steps 14-15). Step 9: The V-AMF 305 sends a DL NAS Transport message to the Femto 303, where the DL NAS Transport message includes a new IE “5gNrFemto {un-authorized 5G NR Femto}”.

[0080] Step 10: The Femto 303 forwards a PDU Session Establishment Reject message to the UE 301, where the PDU Session Establishment Reject message includes a new cause “LBO: un-authorized 5G NR Femto”. The DL NAS Transport message sent from the V-AMF 305 to the Femto 303 in Step 9 includes the NAS PDU (e.g., it has the PDU Session Establishment Reject message in it). The UE 301, which originated the PDU Session Establishment Request message in Step 1, will remove the HgNBID from the cell search / sel ection criteria in response to receiving the PDU Session Establishment Reject message with the new cause “LBO: unauthorized 5G NR Femto”.

[0081] Step 11 : The Femto 303 prepares an SIB / MAC-CE / DCI message to send to UEs, including UE 301.

[0082] Step 12: The Femto 303 sends the SIB / MAC-CE / DCI message to the UE 301.

[0083] Step 13: The UE 301 reads the SIB / MAC-CE / DCI message. If it contains one or more bit values indicating the Femto 303 status is “un-authorized 5G NR Femto”, then the UE 301 may remove the 5G-NR Femto / HgNBID from the cell search criteria, so that the UE 301 does not attempt to connect to the same Femto node (e.g., Femto 303) again. By doing so, the UE 301 under the HgNBID proximity will not attempt to use the HgNBID for any local services in the future (e.g., since the Femto 303 may be malicious or compromised). It may also happen that even though the authorization status of “off’ is received from the V-AMF 305, the Femto 303 may still send an authorization status of “on” to the UEs under it, including UE 301. The UE 301 may prioritize information received from the core network in one or more NAS messages over information received from the Femto 303 over AS. In this case, even though the Femto 303 may send an authorization status of “on,” if the UE also receives an authorization of “false” from a PDU Session Establishment Reject NAS message (e.g., in Step 14 discussed below), then the UE 301 should consider the authorization information / status from the V-AMF 305 rather than the Femto 303.

[0084] Step 14: The V-AMF 305 sends a PDU Session Establishment Reject NAS message to the UE 301, where the PDU Session Establishment Reject NAS message includes a new error code derived from the SmContextCreateError data structure of the Nsmf PDUSession CreateSMContext Response message received in Step 8. FIG. 8 shows a table 800 of information element identifiers (lEIs) along with their information element, type / reference, presence, format and length (i.e., 3GPP TS 24.501 Table 8.3.3.1.1) with a new information element for “Forbidden HgNBID” with a type / reference indicating that the HgNBID is compromised or unauthorized to access the services and that the UE may not use the HgNBID for future services. FIG. 9 shows a table 900 of cause values (e.g., 5GSM cause values) including bits and their description (i.e., 3GPP TS 24.501 Table 9.11.4.2) with a new cause value with bit value 0111 0000 for “Femto not authorized for LBO / Local Services.” It should be appreciated that any similar meaningful error code may be used.

[0085] Step 15: The UE 301 reads the PDU Session Establishment Reject NAS message and, if the reject cause value indicates an unauthorized 5G NR, then the UE 301 may remove the 5G-NR Femto / HgNBID from the cell search criteria, so that the UE 301 does not attempt to connect to the same Femto node (e.g., Femto 303) again.

[0086] Step 16: The V-SMF 311 sends a Nudm SubscriberDataManagement Get Request message with SUPI as the data key to the VUDM / UDR 307 to retrieve the UE subscription data.

[0087] Step 17: The VUDM / UDR 307 sends a Nudm_SubscriberDataManagement Get Response message to the V-SMF 311, where the Nudm SubscriberDataManagement Get Response message includes the UE subscription data.

[0088] Step 18: The V-SMF 311 checks for “LBO Roaming Information” in the UE subscription data (e.g., checking whether LBO Roaming Information = true in the Nudm SubscriberDataManagement (SDM) Service). If allowed (LBO Roaming Information = true) and the PDU Session Establishment Request is from femto (a femto indication is received in Step 3), then the V-SMF 311 shall trigger the secondary authentication and also uses the DN-AAA server addressing information if present. As noted above, Step 18 assumes that Step 7 has passed (e.g., there exists Femto details in the VUDM / UDR 307 for the HgNBID included in the PDU Session Establishment Request message).

[0089] Step 19: The V-SMF 311 creates an N4 session with the V-UPF 313 by including the FemtoIndicator and Ibolndicator parameters in an N4 Session Establishment Request message.

[0090] Step 20: The V-UPF 313 responds to the V-SMF 311 with an N4 Session Establishment Response message. Step 21 : Secondary authentication is performed between the V-SMF 311 and the DN- AAA 315. The secondary authentication may be performed in accordance with 3 GPP TS 23.502 Clause 4.3.2.3 and 3GPP TS. 33.501 Clause 11.1.

[0091] Step 22: The V-UPF 313 has learned that the PDU session is from the Femto 303 and is meant for local services (LBO), and thus enforces specified security mechanisms for protecting data over N6. This may include the V-UPF 313 enforcing encryption of data over N6 using protocols like TLS, IPsec, etc. The specified security mechanisms may be set by the operators of the communication network. Operators in different geographic regions may have different specifications for imposing security protocols, which may depend on the local legislation of particular countries. For example, security protocols for LBO are often required by operators in Europe and North America, while operators in other regions (e.g., India, China, developing countries) may not require security protocols for LBO.

[0092] Step 23 : The V-UPF 313 and DN-AAA 315 perform the specified security mechanisms, such as TLS or IPsec (e.g., Internet Key Exchange version 2 (IKEv2)) encryption.

[0093] FIG. 10 shows a process flow 1000 for providing security for local services in a communication system including a UE 1001, a femtocell device 1003 (also referred to as Femto 1003), V-AMF 1005 supporting SEAF functionality, VUDM / UDR 1007 supporting ARPF / SIDF functionality, V-AUSF 1009, V-SMF 1011 supporting authenticator functionality, V-UPF 1013, and DN-AAA 1015. Similar to the process flow 300, the process flow 1000 may assume a pre-condition that an operator has provisioned or preconfigured HgNB details for each HgNB in the VUDM / UDR 1007. Such HgNB details may include, but are not limited to, parameters such as HgNBID, supportedCagldList, Locationinfo, accessMode, FemtoIndication and Secondary Authlndicati on. Step 0 includes the UE 1001 performing a primary authentication with the V-AUSF 1009 during registration of the UE 1001 with the network. This primary authentication may, in some embodiments, be in accordance with 3 GPP TS 33.501 clause 6.1.

[0094] Step 1 : The UE 1001 sends a service request to the network (e.g., Femto 1003). The service request includes parameters such as an HgNBID, FemtoIndication and S econdary Authlndi cati on .

[0095] Step 2: The Femto 1003 sends an UL NAS Transport message to the V-AMF 1005, where the UL NAS Transport message has the HgNBID, FemtoIndication and SecondaryAuthlndication parameters added to it. Step 3: The V-AMF 1005 initiates an Nsmf PDUSession UpdateSMContext Request to the V-SMF 1011 which acts as an authenticator. The Nsmf PDUSession UpdatedSMContext Request includes the HgNBID, FemtoIndication and S econdary Authlndi cati on parameters .

[0096] Steps 4-7 in the process flow 1000 are the same as Steps 4-7 in the process flow 300 described above. If Step 7 fails, the process flow 1000 proceeds with Steps 8-15. If Step 7 passes, the process flow 1000 proceeds with steps 16-23.

[0097] Step 8: The V-SMF 1011 sends an Nsmf PDUSession UpdateSMContext Response message to the V-AMF 1005. The Nsmf_PDUSession_UpdateSMContext Response message includes the novel error code (e.g., cause = unauthorized or compromised femto) in the SmContextCreateError data structure of the POST Response Body. The novel error code may be the same as that used in Step 8 of the process flow 300 described above.

[0098] Step 9 in the process flow 1000 is the same as Step 9 in the process flow 300 described above.

[0099] Step 10: The Femto 1003 forwards a Service Reject message to the UE 1001 in a DL NAS Transport message, where the Service Reject message includes the new cause “LBO: unauthorized 5G NR Femto.” The DL NAS Transport message includes a NAS PDU (e.g., it has the Service Reject message in it). Upon receiving the Service Reject message from the Femto 1003, the UE 1001 (which originated the Service Request in Step 1) will remove the HgNBID from the cell search / selection criteria.

[0100] Steps 11-13 in the process flow 1000 are the same as Steps 11-13 in the process flow 300 described above.

[0101] Step 14: The V-AMF 1005 sends a Service Reject message to the UE 1001, where the Service Reject message includes a new error code derived from the SmContextCreateError data structure of the Nsmf PDUSession CreateSMContext Response message received in Step 8. FIG. 11 shows a table 1100 of lEIs along with their information element, type / reference, presence, format and length (i.e., 3GPP TS 24.501 Clause 8.2.18) with a new information element for “Forbidden HgNBID” with a type / reference indicating that the HgNBID is compromised or unauthorized to access the services and that the UE may not use the HgNBID for future services. FIG. 12 shows a table 1200 of cause values (e.g., 5GMM cause values) including bits and their description (i.e., 3GPP TS 24.501 Table 9.11.3.2.1) with a new cause value with bit value 0111 0000 for “Femto not authorized for LBO / Local Services.” It should be appreciated that any similar meaningful error code may be used.

[0102] Steps 15-23 in the process flow 1000 are the same as Steps 15-23 in the process flow 300 described above.

[0103] Accordingly, one or more illustrative embodiments may include an apparatus including at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: generate a service request message, the service request message comprising an identifier associated with a femtocell device in a communication network and an indication that local service access is to be provided by the femtocell device; and send, to the femtocell device, the service request message. The femtocell device may comprise a 5G New Radio (NR) Femto cell. The service request message may further comprise an indication of secondary authentication to be performed responsive to determining that the femtocell device is authorized for the local service access. The at least one processor and the at least one memory may be a part of user equipment accessing the communication network via the femtocell device.

[0104] In some illustrative embodiments, the apparatus may further be caused to receive a service reject message, the service reject message comprising a cause value indicating that the service request is rejected due to the femtocell device not being authorized for the local service access. The service reject message may be received from the femtocell device, or may be received from a core network entity in the communication network in a non-access stratum message.

[0105] In some illustrative embodiments, the apparatus may further be caused to receive a first message from the femtocell device indicating a first authorization status for the femtocell device and receive a second message from a core network entity in the communication network indicating a second authorization status for the femtocell device. The apparatus may further be caused to determine whether the first authorization status matches the second authorization status and, responsive to the second authorization status being different than the first authorization status, utilize the second authorization status to determine whether the femtocell device is authorized for the local service access.

[0106] In some illustrative embodiments, the apparatus may further be caused to, responsive to determining that the femtocell device is not authorized for the local service access, remove the identifier associated with the femtocell device from cell search and selection criteria. In one or more other illustrative embodiments, a method may include: generating, at user equipment associated with a communication network, a service request message, the service request message comprising an identifier associated with a femtocell device in the communication network and an indication that local service access is to be provided by the femtocell device; and sending, from the user equipment to the femtocell device, the service request message.

[0107] In some illustrative embodiments, the method may further comprise receiving a service reject message, the service reject message comprising a cause value indicating that the service request is rejected due to the femtocell device not being authorized for the local service access. The service reject message may be received from the femtocell device, or may be received from a core network entity in the communication network in a non-access stratum message.

[0108] In some illustrative embodiments, the method may further comprise, responsive to determining that the femtocell device is not authorized for the local service access, removing the identifier associated with the femtocell device from cell search and selection criteria of the user equipment.

[0109] In one or more further illustrative embodiments, an apparatus includes at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, at a core network entity in a communication network, a service request message generated by user equipment, the service request message comprising an identifier associated with a femtocell device in a communication network, an indication that local service access is to be provided by the femtocell device, and an indication of secondary authentication to be performed responsive to determining that the femtocell device is authorized for the local service access; determine, at the core network entity, whether the femtocell device is authorized for the local service access; responsive to determining that the femtocell device is authorized for the local service access, perform the secondary authentication to determine whether the user equipment is authorized for the local service access; and responsive to determining that the femtocell device is not authorized for the local service access, send a service reject message. The core network entity may be an SMF.

[0110] In some illustrative embodiments, determining whether the femtocell device is authorized for the local service access comprises verifying whether the core network is provisioned with information for the identifier associated with the femtocell device indicating that the femtocell device is authorized for the local service access. In some illustrative embodiments, the service reject message comprises a cause value indicating that the service request is rejected due to the femtocell device not being authorized for the local service access. The service reject message may be sent to the user equipment in a non-access stratum message, or to the femtocell device.

[0111] In one or more further illustrative embodiments, a method may include: receiving, at a core network entity in a communication network, a service request message generated by user equipment, the service request message comprising an identifier associated with a femtocell device in a communication network, an indication that local service access is to be provided by the femtocell device, and an indication of secondary authentication to be performed responsive to determining that the femtocell device is authorized for the local service access; determining, at the core network entity, whether the femtocell device is authorized for the local service access; responsive to determining that the femtocell device is authorized for the local service access, performing the secondary authentication to determine whether the user equipment is authorized for the local service access; and responsive to determining that the femtocell device is not authorized for the local service access, sending a service reject message. The core network entity may be an SMF.

[0112] In some illustrative embodiments, determining whether the femtocell device is authorized for the local service access comprises verifying whether the core network is provisioned with information for the identifier associated with the femtocell device indicating that the femtocell device is authorized for the local service access.

[0113] In some illustrative embodiments, the service reject message comprises a cause value indicating that the service request is rejected due to the femtocell device not being authorized for the local service access.

[0114] It is to be appreciated that the particular processing operations and other system functionality described in conjunction with the diagrams described herein are presented by way of illustrative example only and should not be construed as limiting the scope of the disclosure in any way. Alternative embodiments can use other types of processing operations and messaging protocols. For example, the ordering of the steps may be varied in other embodiments, or certain steps may be performed at least in part concurrently with one another rather than serially. Also, one or more of the steps may be repeated periodically, or multiple instances of the methods can be performed in parallel with one another. It should again be emphasized that the various embodiments described herein are presented by way of illustrative example only and should not be construed as limiting the scope of the claims. For example, alternative embodiments can utilize different communication system configurations, user equipment configurations, base station configurations, authorization processes, messaging protocols and message formats than those described above in the context of the illustrative embodiments. These and numerous other alternative embodiments within the scope of the appended claims will be readily apparent to those skilled in the art.

Claims

25CLAIMS1. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: generate a service request message, the service request message comprising an identifier associated with a femtocell device in a communication network and an indication that local service access is to be provided by the femtocell device; and send, to the femtocell device, the service request message.

2. The apparatus of claim 1, wherein the femtocell device comprises a 5G New Radio (NR) Femto cell.

3. The apparatus of claim 1, wherein the at least one memory storing instructions, when executed by the at least one processor, further cause the apparatus at least to: receive a service reject message, the service reject message comprising a cause value indicating that the service request message is rejected due to the femtocell device not being authorized for the local service access.

4. The apparatus of claim 3, wherein the service reject message is received from the femtocell device.

5. The apparatus of claim 3, wherein the service reject message is received from a core network entity in the communication network in a non-access stratum message.

6. The apparatus of claim 1, wherein the at least one memory storing instructions, when executed by the at least one processor, further cause the apparatus at least to: receive a first message from the femtocell device indicating a first authorization status for the femtocell device; and receive a second message from a core network entity in the communication network indicating a second authorization status for the femtocell device.

7. The apparatus of claim 6, wherein the at least one memory storing instructions, when executed by the at least one processor, further cause the apparatus at least to: determine whether the first authorization status matches the second authorization status; and responsive to the second authorization status being different than the first authorization status, utilize the second authorization status to determine whether the femtocell device is authorized for the local service access.

8. The apparatus of claim 7, wherein the at least one memory storing instructions, when executed by the at least one processor, further cause the apparatus at least to: responsive to determining that the femtocell device is not authorized for the local service access, remove the identifier associated with the femtocell device from cell search and selection criteria.

9. The apparatus of claim 1, wherein the service request message further comprises an indication of secondary authentication to be performed responsive to determining that the femtocell device is authorized for the local service access.

10. The apparatus of claim 1, wherein the at least one processor and the at least one memory are a part of user equipment accessing the communication network via the femtocell device.

11. A method comprising: generating, at user equipment associated with a communication network, a service request message, the service request message comprising an identifier associated with a femtocell device in the communication network and an indication that local service access is to be provided by the femtocell device; and sending, from the user equipment to the femtocell device, the service request message.

12. The method of claim 11, further comprising receiving a service reject message, the service reject message comprising a cause value indicating that the service request message is rejected due to the femtocell device not being authorized for the local service access.

13. The method of claim 12, wherein the service reject message is received from the femtocell device.

14. The method of claim 12, wherein the service reject message is received from a core network entity in the communication network in a non-access stratum message.

15. The method of claim 12, further comprising, responsive to determining that the femtocell device is not authorized for the local service access, removing the identifier associated with the femtocell device from cell search and selection criteria of the user equipment.

16. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, at a core network entity in a communication network, a service request message generated by user equipment, the service request message comprising an identifier associated with a femtocell device in a communication network, an indication that local service access is to be provided by the femtocell device, and an indication of secondary authentication to be performed responsive to determining that the femtocell device is authorized for the local service access; determine, at the core network entity, whether the femtocell device is authorized for the local service access; responsive to determining that the femtocell device is authorized for the local service access, perform the secondary authentication to determine whether the user equipment is authorized for the local service access; and responsive to determining that the femtocell device is not authorized for the local service access, send a service reject message.2817. The apparatus of claim 16, wherein determining whether the femtocell device is authorized for the local service access comprises verifying whether the core network entity is provisioned with information for the identifier associated with the femtocell device indicating that the femtocell device is authorized for the local service access.

18. The apparatus of claim 16, wherein the service reject message comprises a cause value indicating that the service request message is rejected due to the femtocell device not being authorized for the local service access.

19. The apparatus of claim 16, wherein the service reject message is sent to the user equipment in a non-access stratum message.

20. The apparatus of claim 16, wherein the service reject message is sent to the femtocell device.

21. The apparatus of claim 16, wherein the core network entity is a Session Management Function (SMF).

22. A method comprising: receiving, at a core network entity in a communication network, a service request message generated by user equipment, the service request message comprising an identifier associated with a femtocell device in a communication network, an indication that local service access is to be provided by the femtocell device, and an indication of secondary authentication to be performed responsive to determining that the femtocell device is authorized for the local service access; determining, at the core network entity, whether the femtocell device is authorized for the local service access; responsive to determining that the femtocell device is authorized for the local service access, performing the secondary authentication to determine whether the user equipment is authorized for the local service access; andresponsive to determining that the femtocell device is not authorized for the local service access, sending a service reject message.

23. The method of claim 22, wherein determining whether the femtocell device is authorized for the local service access comprises verifying whether the core network entity is provisioned with information for the identifier associated with the femtocell device indicating that the femtocell device is authorized for the local service access.

24. The method of claim 22, wherein the service reject message comprises a cause value indicating that the service request message is rejected due to the femtocell device not being authorized for the local service access.

25. The method of claim 22, wherein the core network entity is a Session Management Function (SMF).

Images