HK1166917B - Setup and configuration of relay nodes - Google Patents

Description

Setting and configuration of relay nodes

Technical Field

The present invention relates generally to communications, and in particular, to a method, apparatus and system for provisioning (provisioning) of wireless relay nodes in a telecommunications system.

Background

Radio communication networks were originally developed primarily to provide voice services over circuit switched networks. The introduction of packet switched bearers in, for example, so-called 2.5 generation (G) and 3G networks enables network operators to provide data services as well as voice services. Eventually, the network architecture will likely evolve towards a full Internet Protocol (IP) network that provides both voice and data services. However, network operators have a large investment in existing infrastructure and will therefore generally prefer to migrate gradually to full IP network architectures in order to allow them to gain sufficient value from their investment in existing infrastructure. Furthermore, in order to provide the capabilities needed to support next generation radio communication applications while using legacy infrastructure, network operators are able to deploy hybrid networks, where the next generation radio communication system is overlaid onto an existing circuit switched or packet switched network as a first step in the transition to a fully IP based network. Alternatively, radio communication systems are able to evolve from one generation to the next, while still providing backward compatibility with legacy devices.

One example of such an evolved network is based on the Universal Mobile Telephone System (UMTS), which is an existing third generation (3G) radio communication system that is evolving to High Speed Packet Access (HSPA) technology. Yet another alternative is to introduce new air interface technologies within the UMTS framework, e.g. the so-called Long Term Evolution (LTE) technology. Target performance objectives for LTE systems include, for example, support of 200 active calls per 5MHz cell and less than 5ms latency for small IP packets. Each new or partial generation of mobile communication systems increases the complexity and capabilities of the mobile communication system and this is expected to continue, leading to enhancements to the proposed system or new systems in the future.

Taking LTE technology as an example, as this new technology is deployed in more locations, more infrastructure, such as network nodes, will need to be deployed in order for mobile users to be able to take advantage of the service options available via this technology. This can be particularly relevant for wireless relay nodes, which may need to be deployed quickly and smoothly, for example to temporarily improve the coverage of the radio access network. In a conventional operations and maintenance (O & M) configuration process, it is expected that a new network node establishes connectivity to an Operations and Support System (OSS) before beginning its configuration, i.e., the node is generally expected to have a secure connection to the OSS before configuring the new network node for operations in the network.

Accordingly, systems and methods for configuring network nodes lacking such secure connections in a telecommunications system are desirable.

Disclosure of Invention

These and other objects, features and advantages of the exemplary embodiments are described herein in which a relay node is described that uses the same wireless interface and network connection as used by a user equipment. Methods, systems, and apparatus are described for configuring such relay nodes using the same wireless interface, some of which use network-based mechanisms that are also used by user equipment for attachment/authentication with the network. Such relay nodes can then operate to relay signals to and from the user equipment and the network after they are connected to the network.

According to an exemplary embodiment, a method for configuring a wireless relay node in a telecommunications network is described. The wireless relay node uses the first configuration data to connect with the telecommunications network via a wireless interface that is the same as the wireless interface used by the user equipment to transmit and receive data. After wirelessly connecting with the network, the wireless relay node authenticates with the telecommunications network using the first configuration data. The wireless relay node then receives second configuration data from the telecommunications network, which it uses to enter an operational mode. At this time, the wireless relay node can relay data received from the user equipment to the telecommunication network through the wireless interface.

According to another exemplary embodiment, a wireless relay node comprises a processor and a communication interface. The processor is for example configured to use the first configuration data to allow the wireless relay node to wirelessly connect to the telecommunications network using the same wireless interface as the user equipment used to transmit and receive data. The wireless relay node authenticates with the telecommunications network using the first configuration data, after which the communication interface receives second configuration data from the telecommunications network. The processor configures the wireless relay node for normal operation using the second configuration data, at which point the wireless relay node relays data received from the user equipment towards the telecommunications network using the same wireless interface.

Drawings

The accompanying drawings illustrate exemplary embodiments, and in which:

fig. 1 shows an overview of a system in which wireless relay nodes can be deployed, according to an exemplary embodiment;

fig. 2 illustrates an operator network communicating with an evolved universal terrestrial radio access network (E-UTRAN) in which enoders (enrs) are deployed, according to an exemplary embodiment;

fig. 3 shows a flow chart of a method for provisioning an eNR according to an exemplary embodiment;

fig. 4 shows a signaling diagram associated with provisioning eNR in accordance with an exemplary embodiment;

fig. 5 illustrates a communication node according to an exemplary embodiment; and

fig. 6 shows a flow chart of a method for configuring a wireless relay node according to an exemplary embodiment.

Detailed Description

The following detailed description of exemplary embodiments refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. Furthermore, the following detailed description does not limit the invention. Rather, the scope of the invention is defined by the appended claims.

In the expansion and upgrade of wireless telecommunication systems, nodes to be equipped are deployed. "provisioning" as used herein refers to the general process of providing a node with initial configuration data that is subsequently used by the node to enter an active service that is part of the network. Before discussing exemplary embodiments below, a purely illustrative overview of a system capable of deploying and provisioning nodes will now be described with reference to FIG. 1 to provide some context for this discussion.

According to an exemplary embodiment, the communication system in which the wireless relay node can be deployed includes various User Equipments (UEs) 108, such as mobile phones, laptops and Personal Digital Assistants (PDAs), which communicate with an evolved universal terrestrial radio access network (E-UTRAN)106 over a wireless interface. E-UTRAN106 communicates with Evolved Packet Core (EPC)104 over an S1 interface. The EPC 104 then routes the call/request from the UE 108 to various separate networks and services as generally shown by the internet/operator service 102. E-UTRAN106 may use wired or wireless nodes to support communication with UE 108. The phrase "wireless relay node" as used herein includes, for example, repeaters, relays, self-backhauled enodebs (enbs), and the like. More specifically, the repeater is a layer 1 (L1) amplifier device that receives a transmission, e.g., from the UE 108, amplifies the received transmission without decoding it, and retransmits it to, e.g., the network. A repeater is a node that decodes a transmission and forwards the data forward after it has been encoded again. A self-backhauled eNodeB is similar to a conventional eNodeB except that its backhaul link is provided by the LTE radio interface rather than a wired network connection. In the following description, these and other similar devices will be referred to as enoders (enrs). Although the exemplary system of fig. 1 includes an E-UTRAN106, those skilled in the art will appreciate that the present invention is not limited to use with a cooperative E-UTRAN wireless communication system, but can be used with any wireless communication system.

According to exemplary embodiments, a Long Term Evolution (LTE) Radio Access Network (RAN)/System Architecture Evolution (SAE) network can include various control functions and nodes for radio resource management. For example, fig. 2 illustrates an operator network 202 including an Operations Support System (OSS)204 and an Evolved Packet Core (EPC) 206. The OSS 204 is generally capable of performing functions such as command processing, billing, fault management, configuration of network components, and other operation/maintenance support functions. The EPC 206 includes a Mobility Management Entity (MME)208 that is capable of performing (and/or supporting) various functions of the RAN, such as bearer management functions, authentication, and gateway selection. The Home Subscriber Server (HSS)210 is a database that contains subscriber information that supports authentication/authorization issues associated with the UE214 (and other nodes). The EPC 206 also includes a serving SAE Gateway (SGW)/packet data network SAE gateway (PDN GW) 212. The SGW function performs a variety of tasks such as packet routing and forwarding, mobility anchoring for inter-3 GPP mobility, and a gateway as an interface terminating towards E-UTRAN 216. The PDN GW (PGW) function also performs a variety of tasks, such as IP address allocation for the nodes and is a link to other networks 224, such as the internet, and services, such as those provided by a Registered Operator (RO)226, which 226 can act as a broker for the operator and perform hosted discovery services. Its responsibilities are described in more detail below. Additionally, although shown as a single entity, the SGW/PDN GW212 can be implemented as a separate entity within the EPC 206.

The E-UTRAN 216 includes an anchor eNodeB (aNB)218 that communicates with the EPC 206 over a version of the S1 interface, e.g., S1MME and S1U. In addition, the aNB218 is capable of wirelessly communicating with other nodes, e.g., the UE214 and the eNR220, over a radio interface denoted "LTE-Uu". Once the eNR220 is operational, i.e., sufficiently provisioned and accepted by the network, other UEs 214 will be able to connect to the network through the eNR220 in communication with the aNB218 using the same interface (e.g., the "LTE-Uu" interface). Although only one eNodeB218 is shown in fig. 2 to simplify the figure, those skilled in the art will appreciate that an E-UTRAN implementation will typically include more than one eNodeB.

According to an exemplary embodiment, the wireless relay to be configured will become part of the network infrastructure itself once it enters the operational mode, e.g., the eNR220 which will provide connectivity services to regular users, and the wireless relay will also use the same network infrastructure for its own connectivity purposes in reaching the OSS 204 as part of its configuration and/or provisioning before entering the operational mode, i.e., the eNR220 can connect with the network using the same interface for its configuration and provisioning for relaying and communicating with the UE 214. The establishment of basic connectivity with the network infrastructure is part of the process by which the wireless relay node 220 is set up and configured, for example, during provisioning. In addition to establishing this basic (wireless) connectivity with the rest of the network, other factors can also be taken into account for provisioning, e.g., it may be desirable to inform other nodes of the presence of the wireless relay node 220. For example, upon provisioning an eNR220 that is being added to a communication network, the eNR220 is an entity that is part of the infrastructure and therefore may need to be treated differently than the UE214, to which other network nodes that join to provide connectivity services note (or need to become aware). That is, certain network nodes like the aNB218 will know or understand that even though the eNR220 and the UE214 are both connected to the network via the same wireless interface, the eNR220 has different functionality and responsibilities compared to the UE 214.

According to exemplary embodiments, one method for securely configuring a wireless relay node is capable of connecting to a network infrastructure using the same wireless communication interface as the communication protocol used to provide access services for the UE 214. An exemplary configuration method can, for example, provision the eNR220 with operational Universal Service Identity Module (USIM) credentials and other operator-specific configuration data from the home operator. Additionally, the exemplary embodiments are able to establish the desired security for the eNR220 as it transitions from its initial state from the factory where it was manufactured (e.g., without any binding to the operator, and separate from all networks) to being a trusted and integrated component of the particular operator's network.

Before provisioning a new eNR220, the eNR220 can perform steps associated with pre-provisioning and field deployment. For (optional) pre-provisioning, applications and data may be stored in the eNR220, which can then be used to obtain basic network connectivity, obtain management system capabilities, or support subsequent provisioning of applications or data. Examples of data that can be pre-provisioned in the eNR220 include an identifier of the eNR220, secure data such as cryptographic keys and public key certificates, and address information such as Fully Qualified Domain Names (FQDNs). An example of an application that can be provisioned in the eNR220 is a USIM application, which performs third generation partnership project (3GPP) Authentication and Key Agreement (AKA) operations. The pre-provisioning can be done in the factory (by the manufacturer) or in a warehouse (by the operator). In addition, the manufacturer of the eNR220 may support subsequent provisioning by implementing or installing applications or data, or by integrating external interfaces that facilitate deployment.

According to exemplary embodiments, the purpose of pre-provisioning and provisioning during deployment is to enable the eNR220 to become provisioned with USIM credentials sufficient to establish initial connectivity using, for example, a procedure similar to the UE attach procedure. In addition, the pre-provisioning and/or provisioning procedures can provide the eNR220 with information on how to use its initial connectivity (i.e., what signal to send to complete the configuration procedure). In addition, some of the data provided at this time may be used for bootstrap (bootstrap) O & M security procedures.

After this (optional) pre-provisioning has occurred, the eNR220 is deployed in the field, e.g., the eNR220 is assembled with cables, power supplies and the like connected to the antenna at the location of installation. Before or after power on of the eNR220, during the deployment phase, there may be some additional configuration performed by, for example, a Universal Integrated Circuit Card (UICC) that may be placed in a card reader (not shown in fig. 2, see, e.g., fig. 5) connected to the eNR 220. A computing device or processor (not shown in fig. 2, see e.g. fig. 5) is connectable to the eNR220 for uploading provisioning data (keys, one-time passwords, identifiers, addresses, root certificates, fingerprints) or applications (e.g. USIM applications) from a UICC card reader, which can include and read the USIM card containing this information on the eNR 220. Alternatively, provisioning data can be loaded into the eNR220 at the deployment site using other input means than a UICC card reader. After deployment, provisioning can be performed according to an exemplary embodiment, as shown in the flow diagram of FIG. 3 and described below.

As mentioned above, certain provisioning of data and/or applications for the wireless relay node may be done at the factory or deployment site before connecting the eNR220 to the network. However, some or all of the provisioning may also be done once the wireless relay node is connected to the network over the air interface. According to an exemplary embodiment, the provisioning of the eNR220 can thus comprise the following steps: (1) establishing basic wireless connectivity with a network in step 302; (2) download eNR220 configuration information in step 304; and (3) begin normal operation in step 306. At startup, the eNR220 may perform procedures similar to legacy UE attach procedures to the LTE network by using USIM credentials (if available) and specifying a special Access Point Name (APN) for providing network internal connectivity for the eNR220 over the radio interface. This makes it possible to provide IP connectivity to a wireless relay node, e.g. eNR220, over an intra-operator IP network separate from the IP network used by the ordinary end user, e.g. UE 214.

The HSS 210 subscription data, which may be preconfigured in the HSS 210 from the OSS 204, may include an IP address, a PDN gateway to assign, and a QoS profile of a default bearer for providing basic connectivity for the eNR 220. The MME 208 serving the eNR220 can then obtain subscription data from the HSS 210. Note that in one possible embodiment, the MME serving the eNR may be integrated into the anchor eNB, rather than a separate node. MME 208 can then authenticate eNR220 and establish bearer services in aNB218 and in SGW/PGW 212 accordingly. According to an exemplary embodiment, the eNR220 performs the 3GPP AKA option using provisioned USIM credentials and derives keys for ciphering and integrity protection over the air interface in a format similar to that performed by the UE214 for establishing connectivity with the network. This method can also be used to reconnect an eNR220 at a later time if connectivity has been established based on credentials issued by the home operator that owns the network into which the eNR220 is being configured.

However, according to other exemplary embodiments, in the case where downloadable USIMs as described in 3GPP TR33.812 are used, the initial connectivity may be based on "one-time USIMs" issued by the Registration Operator (RO) 226. The purpose of the initial connectivity in such embodiments is to connect the eNR220 to the RO 226 and discover the home operator of the network through the discovery service it hosts, then download the home operator USIM credentials from it to the eNR 220. Using these final USIM credentials, basic connectivity can be established as described above.

As part of establishing basic wireless connectivity with the network in step 302, eNR220 operation and maintenance (O & M) security bootstrapping can proceed as will now be described (alternatively, this security bootstrapping can be performed as a separate step). After establishing basic connectivity (i.e., default bearer) for the eNR220, the eNR220 contacts the OSS 204 to become registered with the management system of the operator network 202. This can include, for example, performing a PKCS #10 registration procedure, which is a certification request syntax standard for public keys, whereby the eNR220 requests public key certificates issued by the OSS 204 Public Key Infrastructure (PKI) system. Simple Certificate Enrollment Protocol (SCEP) is an exemplary protocol that can be used for this process.

The request may contain a logical identifier of the eNR220, a public key of the eNR220, a one-time password (OTP), and signed with a private key of the eNR 220. The OTP may be encrypted to avoid man-in-the-middle attacks and other unwanted external interference. This can be performed by using Transport Layer Security (TLS) and server certificates, in which case the server certificate needs to be verified and considered trustworthy. One method for performing this verification is by equipping the root certificate or its fingerprint that enables the eNR220 to verify the server certificate. Thus, according to an exemplary embodiment, a successful registration can use a public key certificate containing the eNR220 logical identifier, the eNR220 public key and other data, all of which can be signed by the certifying authority of the OSS 204 PKI. Alternatively, such credentials may be provisioned to the eNR220 in the repository or during deployment, in which case this step may be omitted. Additionally, according to exemplary embodiments, this certificate can be used to set up subsequent TLS protected communications between the eNR220 and the OSS 204.

After having registered with the management system of the network, the eNR220 contacts the OSS 204 to establish TLS and downloads node-specific configuration data, e.g., radio configuration information and the like. The configuration downloaded from the OSS 204 may include other instructions regarding the connectivity of the eNR220, e.g., information regarding additional established dedicated bearers in case the eNR220 is a self-backhauled eNB. This instruction from the OSS 204 may trigger the eNR220 to perform a UE214 initiated bearer establishment procedure to the network. In an alternative embodiment, the eNR may not communicate directly with the OSS, but the anchor eNB may perform signaling to the OSS, download the eNR configuration and configure corresponding data in the eNR via a new signaling procedure introduced between the anchor eNB and the eNR for this purpose. In this way, the eNR can remain "hidden" with respect to the OSS.

In order for the network nodes (aNB 218 and MME 208) to notice that a certain specific connection is not related to a regular UE214 but to an eNR220, e.g., a wireless relay node, the eNR220 may use a specific flag in the UE214 capability information that can be uploaded from the eNR220 using legacy UE214 capability upload procedures. This enables the network nodes of interest (aNB 218 and MME 208) to treat eNR220 correctly. For this case, the Access Stratum (AS) capabilities (sent to the aNB218 including radio protocol specific capabilities) and NAS capabilities (sent to the MME 208 including core network protocol specific capabilities) can be extended by the required eNR220 specific fields. The required eNR220 specific field can include at least one indicator of a class type for the node, where a new class type can be defined for the relay node, and possibly for other types of nodes represented by eNR 220. In yet another possible embodiment, the indicator that the apparatus performing the initial access to the network is not a regular UE but a relay node may have been sent as part of the RRC connection establishment procedure (in the RRC connection request or in the RRC connection complete message). More detailed capability information may then be sent from the eNR220 later via the legacy UE214 capability upload procedure. Alternatively, another method for the network to notice the eNR220 is subscribed information, which may include a specific QoS profile for the eNR 220. These QoS profiles can be provided by the HSS 210 or policy control system to the desired network node when using the APN associated with the eNR 220. This allows the affected network nodes to understand that the "new" wireless relay node is eNR220 and interact appropriately with eNR220, i.e., treating eNR220 as a wireless relay node rather than UE 214.

The OSS 204 also configures QoS policies in the PDN GW212 (which provides the APN to which the eNR is connected), which may include any additional dedicated bearers that may need to be established for the eNR 220. This may be useful in the case of a self-backhauling solution where the eNR220 may be established with multiple bearers with different QoS. Additionally, in the case of a self-backhauled eNB, the OSS 204 may need to configure backhaul bearer mapping rules in the SGW used to serve the regular UE 214. This configuration typically also includes mapping rules, i.e. which UE bearer classes (QCI: QoS class identifier) correspond to which backhaul bearer classes on the transport network and their identities, e.g. by means of appropriate Diffserv code points.

The aNB218 providing connectivity for the eNR220 may also need to be configured with eNR220 specific settings, e.g., setting the frequency band that the aNB218 will use to schedule user data for UEs 214 connected via the eNR 220. To obtain these settings, the aNB218 can contact the OSS 204 that provides the OSS 204 specific ID of the eNR220 (possibly received from the eNR220 as part of the "UE" capability), or the OSS 204 can contact the aNB218 with the cell specific "UE" identity (received from the eNR) to identify the eNR220 towards the aNB 218.

The final step of configuring the eNR220 according to this exemplary embodiment occurs when the eNR220 enters normal operation in step 306. At this point, the eNR220 can run a self test and, with permission from the management system, begin normal operation. Higher layers, such as layer 2 and layer 3, may be terminated if the eNR220 is a repeater, rather than, for example, a relay or a self-backhauled eNB. Additionally, after a potential termination of the relay node to higher layer connectivity of the network, the OSS 204 may later become necessary to again contact the relay node, e.g., to download new configurations, new software, etc. To support this use case, the eNR220 may remain connected to the network, but enter idle mode (in a similar manner as done for inactive UEs 214) and wake up only occasionally to monitor the paging channel. When the OSS 204 wants to reach the eNR220, the network can page the eNR220 first and in response, the eNR220 can perform a service request legacy procedure to enter the active mode. After new configuration data is downloaded from the OSS 204, the eNR220 may again move into idle mode.

The above exemplary embodiments generally describe systems and methods for obtaining a first set of information that can be used to obtain basic connectivity to a communication network and a second set of information that describes details for configuring an eNR220 for use in the communication network. Operation and maintenance (O & M) information for the eNR220 can be obtained as part of the second set of information. According to an alternative exemplary embodiment, there can be a third set of obtained information comprising O & M information, i.e. configuration data is obtained and then used by the eNR220 to bootstrap the next connection (this can be the third connection obtaining O & M information). For example, the eNR220 can connect over a network to a software management library distributed service (SMRS) in the OSS 204 to download basic radio parameters and O & M registration information, then connect to a Registration Authority (RA) in the OSS 204 to register node specific O & M certificate information, and then connect to an O & M also in the OSS 204 to register traffic certificate information.

According to an exemplary embodiment, a signaling diagram for connecting (including configuration messages) the eNR220 to the operator network 202 is shown in fig. 4. Initially, the eNR220 transmits a Radio Resource Control (RRC) connection request message 402 to the aNB 218. The aNB218 then responds to the eNR220 with an RRC connection setup message 104. The eNR220 then transmits an RRC connection complete message 406 to the aNB218 and includes NAS: RRC of attach request information directly transmits message 408. The aNB218 then sends an initial message 410 to the MME 208 via S1 application protocol (S1-AP), where S1 represents the interface. If the MME is integrated into the a-NB, the aNB-MME/PGW/SGW signaling steps are ignored. This initial message 410 includes the NAS: attach request, and is similar to the initial UE message. At this point, the collection and authentication of subscription information for the eNR220 proceeds as shown in block 412. In addition, the subscription information may include one or both of the associated PGW address and the local IP address to be assigned to this eNR 220.

MME 208 then transmits create default bearer request message 414 to SGW/PGW 212 via the S11 interface. Here, the IP address of the eNR220 is assigned (if not predetermined and stored with other subscription messages) and the SGW/PGW 212 may initiate the setup of dedicated bearers, which are typically pre-configured in the PGW from the OSS 204. In addition, it may be the case that no interaction is made with the Policy Charging Rules Function (PCRF) during this step.

SGW/PGW 212 then transmits a create default bearer response message 416 to MME 208 over the S11 interface, including a create dedicated bearer request. MME 208 then transmits a message including NAS: attach the accepted context setup request to the aNB 218. The aNB218 then transmits the NAS-bearing: RRC connection reconfiguration of attach accept message 420. In response, the eNR220 transmits an RRC connection reconfiguration complete message 422 to the aNB218 and includes NAS: RRC of attach complete information directly transmits message 424. The aNB218 will then include NAS: a context setup response message 426 of the attach complete information is transmitted to MME 208. MME 208 then transmits an update bearer request message 432 including create dedicated bearer response information to SGW/PGW 212. In response, SGW/PGW 212 transmits an update bearer response message 434 back to MME 208. Further, upon receiving the RRC direct transfer message 424, the aNB218 transmits a capability query message 428 to the eNR220, the eNR220 responding with a capability information message 430 that can include additional eNR specific capabilities.

As shown in fig. 4, initial signaling takes place between the eNR220 and the aNB 218. In this context, when the aNB218 first receives a transmission from the eNR220, the eNR220 can appear to the aNB218 as the UE 214. According to exemplary embodiments, the aNB218 can "discover" that the eNR220 is actually an eNR220, rather than the typical UE214, in various ways. According to an exemplary embodiment, the MME 208 obtains subscription information about the "new" wireless relay node (which information is pre-stored). The subscription information can include a credential indicating that this new wireless relay node is eNR 220. This information is then transmitted back to the aNB 218. According to another exemplary embodiment, when the aNB218 queries the wireless relay node, the wireless relay node can transmit its capabilities indicating that it is an eNR220 rather than a typical UE214 requesting a connection.

The above-described exemplary embodiment associated with the flowchart of fig. 3 describes a provisioning process for a wireless relay node. However, those skilled in the art will appreciate that such a provisioning process can be implemented with a number of variations, some examples of which are described below.

According to exemplary embodiments, different methods can be used to provision the eNR220, such as provisioning in a factory or warehouse, using a UICC, using a Mobile Provisioning Device (MPD), or downloading USIM credentials after establishing initial connectivity with the eNR 220. For security reasons, the eNR220 USIM application and credentials are typically located in a trusted execution environment (TrE), in a secure element that can be implemented on the smart card UICC or in an embedded module within the eNR 220. According to exemplary embodiments, one approach is to provision the home operator USIM credentials at the factory where the eNR220 is manufactured, i.e., the eNR220 is manufactured as required by a particular operator. Other alternative exemplary embodiments are subdivided into various categories and described below.

General purpose integrated circuit card (UICC)

In the case of deploying an eNR220 with a UICC containing USIM applications and credentials, the eNR220 typically has a smart card reader or a factory installed interface for connecting the reader. The operator can prepare the customized UICC, e.g. in a warehouse. Each eNR220 typically has its own UICC which can be placed in its reader for provisioning and during normal operation. The content stored in the UICC can be similar to that of a USIM card for a femto base station, i.e., the content on the UICC can include traditional USIM credentials, IMSI and secret keys, additional configuration data, operator root certificates, FQDN to the registration authority in the operator's OSS 204 and a one-time password (OTP) to authenticate the registration request to the OSS 204.

Furthermore, the eNR220 typically has a (physical) identifier that provides it while still at the factory. Further, the eNR220 can use its own public and private keys, which can be provisioned in the factory, but are typically self-generated on the eNR 220. In addition, there may be preferred Public Land Mobile Networks (PLMNs) designated as mandatory enrs 220 to connect to certain networks. Alternatively, the connectivity from the eNR220 goes through the networks of other operators. It is preferred to insert the UICC into the eNR220 or its associated card reader during deployment, as in this way the logistics of the manufacturer and operator can be separated.

Embedded USIM

According to other exemplary embodiments, provisioning can be performed by using an embedded USIM. When the eNR220 has been manufactured with an embedded TrE and all necessary USIM application logic (e.g., stored in an internal memory device (see, e.g., fig. 5)), the eNR220 is said to be enabled by the embedded USIM. USIM credentials and other operator specific parameters remain to be provisioned, but additional configuration data can be provisioned in a manner similar to that described above for the UICC embodiments. Various use cases for configuring a wireless relay node using an embedded USIM are described below according to exemplary embodiments.

According to exemplary embodiments, the embedded USIM may be provisioned to the eNR220 in an operator warehouse or by a trusted third party before shipment to the field and deployment. Alternatively, and less time consuming for the operator, the eNR220 can be enabled by an embedded USIM in place from the factory, which allows the operator to provision only USIM credentials and other configuration data.

According to exemplary embodiments, for the case when the eNR220 is enabled by an embedded USIM from the factory, the embedded USIM in the eNR220 can be provisioned during field deployment either using MPD or via an MPD modem. The MPD is an active device that securely connects to the eNR220 using local connectivity, e.g., Near Field Communication (NFC), bluetooth, IR, serial interface, USB, ethernet/LAN, and the like, to upload relevant data. This exemplary embodiment generally requires that the eNR220 includes an appropriate communication interface.

According to exemplary embodiments, there are two sub-cases where MPD is used to provision embedded USIMs: MPD offline and MPD online. For MPD offline, USIM credentials and other data are already stored on the MPD. No overlay is needed at this point to obtain USIM credentials. For MPD online, the MPD securely connects to the operator network 202 and downloads relevant USIM credentials and other data. This connection relies on wireless communication coverage at the eNR220 deployment site, as that is the only connectivity that can be employed at the eNR220 site. The MPD can be, for example, an LTE mobile phone or an LTE-equipped laptop of the person doing the installation, which can use Java applications to select the configuration.

In contrast, according to other exemplary embodiments, when the MPD is used as a modem, the eNR220 connects to the operator network 202 via the MPD in order to download relevant soft USIM credentials and other operator data. This connection also relies on the wireless coverage available in the field. The modem may be, for example, an LTE mobile phone or an LTE-equipped laptop of the person performing the installation. In this case, the eNR220 is the active party and the modem primarily provides temporary connectivity. Since the modem/mobile terminal belongs to the operator person (e.g. has a known MSISDN/IMSI), this provides the nodes in the operator network 202 with the option of verifying the legitimacy of the request. In addition, the eNR220 can present its own identity (device identifier) in order to identify the USIM credentials to be downloaded. For the case where the eNR220 has its own private and public cryptographic keys and the mapping between the device identifier and the public key is known out-of-band to the home operator, the USIM credentials can be encrypted by the home operator by the eNR 220's public key.

According to other exemplary embodiments, to avoid live operation using MPD, the eNR220 can alternatively use a disposable USIM for automatic provisioning over a mobile network. A one-time USIM is typically embedded in the eNR220 at the time of manufacture using credentials of the RO 226. This approach employs concepts similar to those formed in the context of machine-to-machine (M2M) communications as described in 3GPP TR33.812, which describes the deployment and remote management of devices without human interaction. In one example, a device such as the eNR220 is provisioned with the initial credentials from the RO 226. We can treat the pre-provisioned data as similar to a one-time USIM issued with an address to the RO 226 service. For example, there are identifiers and secret keys called temporary connectivity ids (pcids) similar to the traditional IMSIs and corresponding secret keys that can be used. In addition, RO 226FQDN can also be provisioned to eNR 220. Other exemplary embodiments based on the use of a disposable USIM are described below.

According to an exemplary embodiment USIM information can be downloaded by using a scheme similar to the application described in M2M TR33.812, i.e. at deployment the eNR220 can obtain connectivity using any "visited operator", contact the RO 226 discovery service and be redirected to a Selected Home Operator (SHO), which can set up a secure connection to the SHO. In M2M, the general purpose of this operation is to download USIM credentials to the device.

According to another exemplary embodiment, the exemplary embodiment for downloading USIM information described above can be enhanced by assuming that the eNR220 is aware of the optimized path. There are some exemplary alternatives. One exemplary alternative is that the external RO 226 is used to authenticate the initial connection, but does not use the RO 226 to discover services and goes directly to SHO. The idea here is to use "standard" M2M devices (in eNR 220), but let the operator network pretend various redirections. Another way is for MME 208 to detect that the attached eNR220 is in its home network and inform the device to acquire the USIM from the FQDN provided inline or derived using a well-defined generation procedure.

According to other exemplary embodiments, the eNR220 can be informed via signaling that it has attached to its home network and can contact its provisioning server directly, whose FQDN is provided inline or derived internally. This may require provisioning restrictions for the PLMN of the disposable USIM. Alternatively, by designing a special procedure, it is possible to avoid contacting the RO 226, whereby the attached eNR220 is handed over directly to the node from which the USIM can be downloaded, which may also require restrictions of the PLMN.

According to still another exemplary embodiment, a pushed version of downloadable USIM information can be used for the discovery service at the RO 226. This scheme can be implemented using Automatic Device Detection (ADD), as described in TS 22.101, which detects when an eNR220 is attached to the network using a disposable USIM. Thus, once the eNR220 attaches to the network and is authenticated, the ADD procedure makes the Home Location Register (HLR) aware of the eNR220 IMEI/IMSI. The HLR then informs the OSS 204 about the new eNR 220. The OSS 204 then pushes, for example, the FQDN of the server, credentials, etc. to the eNR220 using any available bearers so that it can download its USIM credentials and other operator data.

The above-described exemplary embodiments provide methods and systems for provisioning a wireless relay node, e.g., an eNR220, as part of the network infrastructure. As shown in fig. 5, the communication node 500 can include a processor 502 (or multiple processor cores), a memory 504, one or more secondary storage devices 506, and a communication interface 508. The communication node 500 can process the instructions to support the responsibility of performing the functions associated with the eNR 220. For example, configuration information as described in the various exemplary embodiments described above can be stored in the memory 504 or the secondary storage device 506, i.e., the secondary storage device 506 can include an embedded USIM. Further, the pre-provisioned information can be stored in the memory 502 or the secondary storage 506. Additionally, the communication interface 508 is capable of communicating over the same interface used for provisioning and configuration of the node 500 and for communicating with the UE 214. Thus, the communication node 500 can be an eNR 220. In addition, card reader 510 is capable of communicating locally with communication node 500, e.g., through communication interface 508, to read information from a UICC and the like. In some demonstrative embodiments, card reader 510 may be capable of also performing the functions of the MPD as described above. Alternatively, card reader 510 can be integrated as part of communication node 500. The eNR220 differs from the UE214, for example, in many ways. For example, eNR220 can be active for long periods of time, e.g., days, while UEs are often actively connected to the network for shorter periods of time (e.g., for the duration of a telephone conversation), and, in addition, they perform different functions.

A method for configuring a wireless relay node is shown in the flowchart of fig. 6 by utilizing the above-described exemplary system according to exemplary embodiments. Initially, a method for configuring a wireless relay node in a telecommunications network comprises: in step 602, connecting the wireless relay node with the telecommunications network via the wireless interface based on the first configuration data; authenticating the wireless relay node to the telecommunications network based on the first configuration data in step 604; receiving, at the wireless relay node, second configuration data from the telecommunications network in step 606; and in step 608 entering a mode of operation using the second configuration data, wherein in the mode of operation the wireless relay node relays data received over the wireless interface towards the telecommunications network over the wireless interface.

The above-described exemplary embodiments are intended in all respects to be illustrative rather than restrictive. Thus, the present invention is capable of many variations in detailed implementation that can be derived from the description contained herein by a person skilled in the art. All such variations and modifications are to be considered within the scope and spirit of the present invention as defined by the appended claims. For example, in a further evolution of LTE (so-called LTE advanced), a multi-hop structure such as a "chain" of enrs 220 that provide access for UEs can use the various exemplary embodiments described above. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Further, as used herein, the article "a" is intended to include one or more items.

Claims (23)

1. A method performed in a wireless relay node (220) for connecting the wireless relay node (220) to a telecommunication network (216), comprising the steps of:

obtaining first configuration data by inserting a universal integrated circuit card, UICC, comprising the first configuration data into the wireless relay node or by activating an embedded universal service identity module, USIM, located within the wireless relay node, the activation comprising provisioning USIM credentials with the first configuration data;

connecting with the telecommunication network (216) via a wireless interface based on first configuration data, wherein the wireless interface is also used by a user equipment (214) for transmitting and receiving data;

authenticating with the telecommunications network (216) by the wireless relay node (220) based on the first configuration data;

receiving, at the wireless relay node (220), second configuration data from the telecommunications network (216);

entering, by the wireless relay node (220), an operational mode using the second configuration data;

relaying, by the wireless relay node (220), data received from the user equipment (214) via the wireless interface to the telecommunications network (216) via the wireless interface.

2. The method according to claim 1, wherein said steps of connecting and authenticating use a connection mechanism and an authentication mechanism, respectively, present in said telecommunications network and which mechanisms are also used for connecting and authenticating said user equipment.

3. The method of claim 2, wherein the connection mechanism is a UE attach procedure and the authentication mechanism is a universal service identity module, USIM, procedure.

4. The method of claim 1, wherein the first configuration data comprises a physical identifier of the wireless relay node, address information associated with a configuration server, and a public key certificate, and wherein the second configuration data comprises radio configuration data and a local internet protocol, IP, address.

5. The method of claim 1, further comprising:

selectively configuring other network nodes with information about the wireless relay node.

6. The method of claim 5, wherein the other network node is at least one of an eNodeB and a Mobility Management Entity (MME) that is transmitting information received by the wireless relay node.

7. The method of claim 1, wherein the wireless relay node is at least one of a relay, repeater, and self-backhauled eNodeB.

8. The method of claim 1, wherein the embedded USIM is provisioned in an operator repository.

9. The method of claim 1, wherein the embedded USIM is provisioned by using a Mobile Provisioning Device (MPD) during deployment of the wireless relay node.

10. The method of claim 9, wherein the MPD is used as at least one of an MPD offline mode, an MPD online mode, or an MPD modem.

11. The method of claim 10, wherein said MPD offline mode includes using USIM credentials and other data that have been pre-stored on said MPD.

12. The method of claim 10, wherein said MPD online mode includes having said MPD connect to an operator network and download USIM credentials and other data.

13. The method of claim 10, wherein the wireless relay node uses the MPD modem as a modem to connect to an operator network and download USIM credentials and other data.

14. The method of claim 1, wherein the first configuration data is obtained by:

providing a one time universal service identity module, USIM, located within said wireless relay node with credentials to register an operator, RO, wherein said credentials comprise a fully qualified domain name, FQDN, of said RO.

15. The method of claim 1, wherein operation and maintenance information is obtained as part of the second configuration data.

16. The method of claim 1, further comprising:

receiving at said wireless relay node third configuration data from said telecommunications network, wherein said third configuration data includes operation and maintenance information, and further wherein said step of entering a mode of operation uses said second configuration data and said third configuration data.

17. The method of claim 14, wherein the RO performs a discovery service and redirects the wireless relay node to a selected home operator SHO based on the discovery service, the SHO sets a secure connection with the wireless relay node for transmitting the first configuration data to the wireless relay node.

18. The method of claim 14, wherein the RO authenticates an initial connection from the wireless relay node and redirects the wireless relay node to a selected home operator SHO.

19. The method of claim 1, wherein the first configuration data is obtained by:

receiving signaling indicating that the wireless relay node attaches to its home network; and

providing a one time universal service identity module, USIM, located within said wireless relay node with a fully qualified domain name, FQDN, provided with a server.

20. A wireless relay node (220), comprising:

an embedded universal service identity module, USIM, located within said wireless relay node (220), for obtaining first configuration data by activating said USIM, and wherein said activating comprises provisioning USIM credentials with said first configuration data;

a processor (502) configured to use first configuration data to allow the wireless relay node (220) to wirelessly connect to a telecommunications network (216) via a wireless interface that is also used by a user equipment (214) for transmitting and receiving data, wherein the wireless relay node (220) authenticates with the telecommunications network (216) using the first configuration data; and

a communication interface configured to receive second configuration data from the telecommunications network (216),

wherein the processor configures the wireless relay node (220) for normal operation using the second configuration data, and further wherein the wireless relay node (220) subsequently enters an operational mode in which the wireless relay node (220) relays data received from a user equipment (214) over the wireless interface to the telecommunications network (216) via the wireless interface.

21. The wireless relay node of claim 20, wherein the wireless relay node is at least one of a relay, repeater, and self-backhauled eNodeB.

22. The wireless relay node of claim 20, further comprising:

a one time universal services identity module, USIM, located within the wireless relay node with credentials to register an operator, RO, wherein the credentials comprise a fully qualified domain name, FQDN, of the RO, and wherein the credentials are used as the first configuration data.

23. The wireless relay node of claim 20, further comprising:

a disposable universal services identity module, USIM, located within said wireless relay node, wherein said first configuration data is obtained by receiving signalling indicating that said wireless relay node is attached to its home network and provisioning said USIM with a fully qualified domain name, FQDN, of a provisioning server.