WO2017220124A1

WO2017220124A1 - Redundant network entities for critical communication

Info

Publication number: WO2017220124A1
Application number: PCT/EP2016/064214
Authority: WO
Inventors: György Miklós; János HARMATOS
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2016-06-20
Filing date: 2016-06-20
Publication date: 2017-12-28

Abstract

The invention relates to a system (10) comprising: a first mobile entity (100) configured to connect to a first network entity (301) which is part of a group of first network entities of a cellular network, a second mobile entity (200) configured to connect to a second network entity (302) which is part of a group of second network entities of a cellular network. At least one memory (130, 230) stores a first list of first network parameters allowing the first network entities of the first group to which the first mobile entity (100) is configured to connect, to be identified, and a second list of second network parameters allowing the second network entities of the second group to which the second mobile entity (200) is configured to connect, to be identified, wherein the group of first network entities and the group of second network entities do not have a single network entity in common. The first mobile entity (100) is operative to connect only to one of the first network entities determined by the first network parameters, and the second mobile entity (200) is operative to connect only to one of the second network entities determined by the second network parameters.

Description

Redundant network entities for critical communication

Technical Field

The present invention relates to a system including a first mobile entity and a second mobile entity. The invention furthermore relates to a method for operating the system, to a computer program and a carrier comprising the computer program. Background

Future mobile networks are expected to serve a wide range of use cases beyond the current mobile broadband use case, and some of the new use cases are expected to have high reliability requirement. One such use case is industry automation, which in itself covers a wide range of deployments. It can include the automation of different industrial processers, from pure plant measurement to high precise motion control in a robotized factory cell. Due to the wide range of related use cases industry automation is a continuously expanding area, where more and more complicated tasks and processes are taken over by high-precision robots and automatized systems deployed in a factory cell or in a complex assembly line. To provide precise control of industry systems by centralized controllers the two most important requirements of industry automation are low latency (which could be extreme low, around 1 ms in several use cases, such as laser cutting) and high reliability (which requires fast and robust fault-handling solutions). Obviously, the extreme low latency is important in case of timing critical use cases, but the high redundancy/fast switchover time in case of failure could be a basic requirement in much wider range of industrial use cases. Outage of any industry process or system due to a failure causes revenue loss, but an unhandled failure situation could mean damages in industry systems or in the products, or in extreme cases the risk of human injury should also be considered.

To sum up, reliability/fault handling is a very important aspect in industry automation, especially in such use cases when time critical processes are performed by the system, since in this case even a short communication problem could have huge impact on the industry system performance. Besides industry automation, there are other use cases such as intelligent transport systems or public safety and emergency services which may require very high reliability and at the same time low delay.

In the core network, reliability is typically addressed by the use of reliable product solutions for the CN (Core Network) entities such as the MME (Mobility Management Entity) or GWs (Gateways), e.g. by using redundancy at the platform level.

The state of the art solution applied in fixed networks is to provide two independent paths between the communicating end-points, e.g. between a mobile entity(also called UE herein after) and a network entity of a cellular network, so that in case of failure on one of the communication paths, the other path can take over.

However, a need exists to improve the reliability in a communication path between two different entities and to provide a redundancy in an efficient way. Summary

This need is met by the features of the independent claims. Further aspects are described in the dependent claims. According to a first aspect a system is provided comprising a first mobile entity configured to connect to a first network entity which is part of a group of first network entities of a cellular network. The system comprises a second mobile entity configured to connect to a second network entity which is part of a group of second network entities of a cellular network. The system comprises at least one memory configured to store a first list of first network parameters allowing the first network entities of the first group to which the first mobile entity is configured to connect, to be identified. The memory is configured to store a second list of second network parameters allowing the second network entities of the second group to which the second mobile entity is configured to connect, to be identified, wherein the group of first network entities and the group of second network entities do not have a single network entity in common. The system furthermore comprises a processor and the memory contains instructions executable by the at least one processor, wherein the first mobile entity is operative to connect only to one of the network entities determined by the first network parameters and the second mobile entity is operative to connect only to one of the network entities determined by the second network parameters. In this approach the mobile entities in the system which can be a single entity within a common enclosure or housing always connect to different network entities, preferably two different core network entities. The first mobile entity always connects to a given network entity or a set of given network entities contained in the first list that are different for each mobile entity in the system so that the mobile entities in the system can never connect to the same network entity. As the second mobile entity only connects to a fixed set of second network entities, such a static relationship is simple to set up. According to a further aspect a system is provided comprising a first mobile entity configured to connect to a first network entity of a cellular network. The system comprises a second mobile entity configured to connect to a second network entity of a cellular network. The system comprises at least one memory configured to store a first list containing different first selection parameters used by the first mobile entity to select the first network entity when connecting to the cellular network, the different selection parameters having different priority levels. The memory is furthermore configured to store a second list containing different second selection parameters used by the second mobile entity to select the second network entity when connecting to the cellular network, wherein the different second selection parameters have different priority levels, wherein the first selection parameter having the highest priority contained in the first list is different from the second selection parameter having the highest priority contained in the second list. The system comprises at least one processor and the memory contains instructions executable by said at least one processor. The first mobile entity is operative to select a first network entity with highest priority using the first selection parameter with highest priority from the first list when connecting to the first network entity. The second mobile entity is operative to select a second network entity with highest priority using the second selection parameter with the highest priority from the second list when connecting to the second network entity, wherein the selected second network entity with the highest priority from the second list is different from the selected first network entity with the highest priority from the first list.

In this dynamic approach the mobile entities in the system preferably connect to different network entities when each mobile entity selects the network entity with the highest priority. However this does not exclude that the two mobile entities select the same network entity, e.g. when the network with the highest priority is not available for one of the mobile entities so that this mobile entity has to select a network entity with a lower priority. According to another aspect a system is provided wherein the first mobile entity is configured to connect to a first network entity of a cellular network. The system comprises a second mobile entity configured to connect to a second network entity of a cellular network. The system comprises at least one memory and at least one processor, the memory containing instructions executable by said at least one processor, wherein the first mobile entity is operative to connect to the first network entity and the second mobile entity is operative to determine to which first network entity the first mobile entity is connected. The second mobile entity is furthermore operative to select the second network entity taking into account to which first network entity the first mobile entity is connected.

In this coordinated dynamic approach the selection processes of the mobile entities in the same system are coordinated so that they can preferably connect to different network entities. This coordinated dynamic approach can be especially useful if the selection of the network entity is randomised. In this case, coordination is necessary to make sure that the mobile entity which is connecting to the network entity after the other mobile entity in the same system if possible, connects to a different network entity.

The invention furthermore relates to the corresponding methods carried out by the above described systems. Furthermore, a computer program comprising program code is provided to be executed by at least one processing unit of the system including the two mobile entities, wherein execution of the program code causes the at least one processing unit to execute a method mentioned above and described in more detail further below. It is to be understood that the features mentioned above or features yet to be explained below can be used not only in the respective combinations indicated, but also in other combinations or isolation without departing from the scope of the present application. The features of the above mentioned aspect embodiments may be combined with each other in other embodiments unless explicitly mentioned otherwise.

Brief Description of the Drawings

The foregoing and additional features and effects of the application will become apparent from the following detailed description when read in conjunction with the accompanying drawings in which like reference numbers refer to like elements. Brief description of the drawings

Figure 1 shows a high level architecture of a system in which two mobile entities select different core network entities for redundant communication.

Figures 2a to 2c show options how the two mobile entities can be provided within the system.

Figure 3 shows a high level architecture of the system in which the two mobile entities of the system select different PLMNs.

Figure 4 shows a message flow between involved entities for a network assisted and coordinated selection of a PLMN.

Figure 5 shows a message flow between involved entities with the network assisted coordinated PLMN selection according to a further embodiment.

Figure 6 shows a message flow between involved entities of a network assisted coordinated PLMN selection according to another embodiment. Figure 7 shows a high level architecture in which the mobile entities in the system connect to multiple redundant slices in the same PLMN.

Figure 8 shows a message flow between the involved entities for a network assistance when the mobile entity selects a slice of the network in a system shown in Fig. 2.

Figure 9 shows a message flow between the involved entities with a network based slice selection and the mobile entity providing sequence numbers.

Figure 10 shows a message flow between the involved entities of a network based slice selection according to a further embodiment.

Figure 1 1 shows a message flow between the involved entities in an embodiment where a coordination between the mobile entities for selecting a mobility management entity, MME, is carried out. Figure 12 shows a high level architecture of a system in which the two mobile entities in the system use different access point names, APNs, for independent user planes.

Figure 13 shows a message flow between involved entities in an embodiment where a network assisted method is carried out by the mobile entities to connect to an APN.

Figure 14 shows high level architecture of a system in which different sequence numbers are used per mobile device form dependant planes. Figure 15 shows a high level architecture of a system comprising the two mobile entities.

Figure 16 shows a high level architecture of the system with a network based selection of network entities for a system comprising two mobile entities. Figure 17 shows a high level architecture for the different options in a system where two mobile entities connect to different network entities.

Figure 18 shows a message flow between involved entities in an embodiment where network based coordination of slices used by the system is carried out.

Figure 19 shows a message flow between the involved entities for an embodiment where the mobile entities connect to different MMEs.

Figure 20 shows a high level architecture of a system in which the user plane selection is based on a sequence number database.

Figure 21 shows a message flow between involved entities of an embodiment where the sequence number is determined by an RCF. Figure 22 shows a schematic view of a network based entity configured to coordinate the connection of a system with two mobile entities to a cellular network.

Detailed description

In the following, embodiments of the invention will be described in detail with reference to the accompanying drawings. It is to be understood that the following description of embodiments is not to be taken in a limiting sense. The scope of the invention is not intended to be limited by the embodiments described hereafter or by the drawings which are to be taken

demonstratively only. The drawings are to be regarded as being representations and elements illustrated in the drawings are not necessarily shown to scale. Rather, the various elements are represented such that their function and a general purpose become apparent to a person skilled in the art. Any connection or coupling between functional blocks, devices, components or physical functional units shown in the drawings or described herein may be implemented by an indirect connection or coupling. A coupling between components may be established over a wired or wireless connection. Furthermore, functional blocks may be implemented in hardware, software, firmware, or a combination thereof.

Solution with mobile entity based selection of the network entities

In the following a solution will be explained in detail in which reliability and redundancy for a communication system is provided. Figure 1 shows a schematic view of the architecture involving a system 10 which contains in a housing 50 two mobile entities 100, 200. Mobile entities 100, 200 are also called UE-A and UE-B hereinafter. Accordingly two mobile entities are provided within a single system 10 for redundant communications. In many scenarios, the reliability of the solution is of very high importance which justifies the cost of more than one mobile entity integrated in the same system 10. The mobile entities 100 and 200 connect to a core network entity 301 , 302 in the core network over the radio access network (RAN). A core network entity selection process is responsible for selecting the appropriate core network entity for a given mobile entity. The selection process for the network entity is such that the two mobile entities 100, 200 within the same system 10 preferably connect to different network entities 301 , 302, e.g. core network entities. In this way, the communication of the mobile entities within the same system are independent, and therefore the impact of a failure of a core network entity may be limited to a single mobile entity. In the solution the network entity selection process is located within the system 10. The UEs within the system may provide information to the network to influence the selection of the core network entities, so that different UEs within the system select different core network entities when possible.

Figure 2 shows the different options for implementing a system as shown in figure 1. Option one as shown in figure 2a corresponds to the system shown in figure 1 where the two mobile entities are provided within the system 10. Figure 2b shows an embodiment where some parts or the complete physical hardware 12 is in common for the two mobile entities. It is possible that the two mobile entities use the same radio transceiver. This is especially suited for the cases where the core network entities are reachable via the same radio access network. Hence the two mobile entities may correspond to logically different mobile entities that use the same physical hardware.

As another example, the two UEs could have a common SIM/USIM for e.g., identity and authentication. This is a hybrid case between option a and b. In that case, the two UEs can use the same credentials to authenticate themselves. In this case, however, the different UEs still need to differentiate themselves to the network, which can be done e.g., by adding an additional identifier such as a sequence number which tells the two UEs apart for the network.

Further, it is also possible that instead of two UEs in the system, there is only a single UE 100 in the system 10 but the system supports multiple connections from a single UE (option c in Fig. 2). This is the case today for PDN (Packet data network) connections in LTE/EPC, or PDP (Packet Data Protocol) contexts in 3G, which may use different user plane nodes.

Below, the solutions will be described in terms of multiple UEs per system, but the generalizations mentioned above could apply.

There are several options regarding what type of CN entities are treated in this way.

• CN entities may correspond to different PLMNs (Public Land

Mobile Networks). In this case, UEs in the same system 10 preferentially select different PLMNs. Those PLMNs may be handled either by the same business entity, or by different business entities who may have a business relationship to handle each other's UEs. In many cases, the use of different PLMNs provides sufficient separation, so that even if there is a failure in one PLMN, the other PLMN may continue to operate. • CN entities may correspond to different slices of the same PLMN. Network slicing is an emerging concept, where a single physical network supports multiple logical networks called slices. Network slices may be isolated from each other, so that a failure of one network slice may not impact another network slice. In the following the slice is used for a special purpose: providing reliability (e.g providing two independent paths from a certain system to another one through the RAN and CN). In this case multiple slices are instantiated with the purpose that failure of one slice should not impact the other slice(s). Slicing is considered from a core network point of view, where different slices correspond to different Dedicated Core Networks (DCNs).

• CN entities may correspond to different MMEs (Mobile

Management Entity). An MME is the control plane entity in EPC whose

responsibility includes NAS (Non-Acces Stratum) signaling with the UE. Note that for 5G networks, a different control plane entity may be defined with a

corresponding role, for which the invention may be similarly applicable.

• CN entities may correspond to different user plane nodes such as the SGW (Serving Gateway) and PGW (Packet Data Network Gateway) in EPC (Evolved Packet Core). This is a complementary approach to the previous case.

• Any combination of the above. The selection process and the corresponding configuration may be such that UEs 100, 200 are distributed in a balanced way between the CN entities, rather than having a majority of the UEs using only a single or limited set of CN entities.

Regarding the role of the UE vs. the network, the following main alternatives can be differentiated regarding the selection of the CN entity. These alternative embodiments will be elaborated later below.

• UE-only selection without network assistance. In this case, the UE decides on its own which CN entity to connect to, and the network does not explicitly guide the UE in its selection. Network assisted UE selection. In this case, the selection process itself takes place in the UE, but the network provides assistance to the UE to make the selection. Such assistance may be given in the form of a bootstrapping procedure: the UE performs an initial attachment to the network; followed by the network providing information on which CN entity to connect to. If necessary, this can be followed by the UE detaching from the network and attaching again, to the indicated CN entity. Network assistance may also come to the UE while it is already attached; in that case, the UE may detach and re-attach again when necessary.

Network based selection extended with UE indication of the redundancy instance. In this case, the selection of the CN entity takes place in the network. However, the UE still assists the network by supplying required

parameters to differentiate the UEs within the same system. The network directs the UE to the proper CN entity. The solution involves multiple UEs 100, 200, denoted as UE-A, UE-B, etc. within a single system 10 for redundant communications. In many scenarios, the reliability of the solution is of very high importance, which justifies the cost of more the one UEs integrated in the same system. The UEs connect to a CN entity in the core network over the RAN. A CN entity selection process is responsible for selecting the appropriate CN entity for a given UE. The CN entity selection process is such that the UEs within the same system are preferred to connect to different CN entities. In this way, the communication of the UEs within the same system are independent, and therefore the impact of a failure at a CN entity can be limited to a single UE.

With regard to the relationship of a given UE 100, 200 within a system 10 to a given CN entity in the network, the following main options can be differentiated.

• Static relationship. A given UE always connects to a given CN entity or set of CN entities that are different for each UE in the system 10, so that UEs in the system can never connect to the same CN entity. If no CN entity is available for a UE, the UE will not select another CN entity that is associated with another UE in the system. Such a static relationship can be simple to set up, but its application may be limited to cases when the networking environment is well known in advance. This approach is less flexible than other approaches: if the

corresponding CN entity (or set of CN entities) is down, then no reliability can be guaranteed even if other CN entities were available. · Dynamic relationship. A given UE preferably connects to a given

CN entity or set of CN entities so that the CN entity is preferably different for all UEs in a system, but if that is not available it can select another one as well which could be the same as the CN entity for another UE in the system. A dynamic approach can also incorporate a priority list as well to guide the selection. Such a dynamic relationship can also be flexible to handle a networking environment which may change, e.g. due to mobility or failures.

• Coordinated dynamic relationship. The selection process of the UEs in the same system 10 are coordinated, so that they preferably connect to different CN entities. Such coordination can take place e.g., within the system 10 using system-internal signaling between the UEs or between the UEs and another system-internal function. The coordinated dynamic approach can be especially useful if the selection of the CN entity is randomized. In that case, coordination is necessary to make sure that the UE which is connecting to the network after another UE in the same system gets to a different CN entity. Another benefit of coordination is that it is possible to know whether the UEs actually connect to different CN entities or not, and in that way determine the current level of redundancy in the system.

As mentioned above, there are several options for which CN entity the invention is applied; these will be treated separately in more detail below.

UEs connect to different PLMNs

A UE, such as UE 100 or 200 of Fig. 1 or 2 may be able to attach to different PLMNs, each having its own respective RANs which the UEs can connect to. Alternatively, the same RAN may provide access to different PLMNs using network sharing. In either case, by having the UEs 100, 200 within the same system 10 connect to multiple PLMNs, the reliability of the communication can be significantly improved by using independent core networks in the different PLMNs. In many instances of major network failures in the past, other PLMNs could often continue to function, since they are operated independently. Such an arrangement may be accompanied by respective roaming agreements between network operators to cover the cost of serving the additional roaming UEs, as a way to improve reliability. Such business agreements are especially needed in case the different PLMNs are run by different business entities.

PLMN selection is today performed in the UEs, as specified in detail in 3GPP TS 23.122 section 4.4. The user has the possibility for manual selection or for user controlled automatic selection to explicitly influence which PLMN to attach to; otherwise the selection is performed automatically using operator configuration, which will be described below.

The paragraph below indicates a priority list of an automatic PLMN selection process in a mobile entity.

1. HPLMN/EPLMNs

2. User controlled PLMN selection

3. Operator controlled PLMN selection

4. Other PLMNs with sufficiently good signal strength in random order

5. PLMNs in decreasing order of signal strength The idea of the automatic PLMN selection process using, as shown above that the UE 100, 200 selects from the available PLMNs based on the priority list of PLMNs that has been configured in the USIM. First, the PLMNs configured by the user are applied, followed by the PLMNs configured by the operator. (The priority may also be specific for each radio access type in a given PLMN.) The UE's HPLMN (Home PLMN) has the highest priority. There may be other "equivalent" PLMNs which are handled in the same way and priority as the HPLMN. It is possible for the home operator to steer the UE's roaming decision (i.e., PLMN selection) by refreshing the UE's priority list using USIM configuration (e.g., via configuration SMS's). If there is no explicitly configured PLMN that is accessible, the UE attempts to attach to a random PLMN which has sufficiently good signal strength; or if there is no such PLMN with sufficiently good signal strength, the UE 100, 200 tries the PLMNs in decreasing order of signal strength. It is also possible for the home operator to configure a list of forbidden PLMNs (not shown in the figure) which the UE shall not attempt to attach to. The case where the UEs within the same system 10 attach to different PLMNs is illustrated in Figure 3. The mobile entity 100 connects to a first PLMN 31 and the mobile entity 200 connects to a second PLMN 32.

Below the different alternative embodiments with respect to the role of the UE and the network are discussed. Since the PLMN selection takes place in the UE, we can differentiate two cases: UE-only PLMN selection, and network assisted PLMN selection in the UE.

UE-only PLMN selection

In this case the UEs 100, 200 within the system 10 have mechanisms and configurations so that the different UEs preferably connect to different PLMNs. The following options are possible.

Static approach: The UEs 100, 200 within the system 10 are configured with a given PLMN or a given set of PLMNs that they can connect to. The configuration is such that the different UEs in the system can only connect to different PLMNs. The UEs do not connect to any other PLMN besides what they are configured to. This can be realized e.g., by the use of the manual selection mode, by setting the appropriate PLMNs by configuration for the given UEs. This option requires appropriate system configuration, but does not require any additional features from the mobile system.

Dynamic approach: The UEs 100, 200 within the system 10 are configured to preferentially connect to different PLMNs, but can fall back to other PLMNs if the most preferred PLMN is not available. This might in certain failure cases result in a situation where UEs in the system 10 connect to the same PLMNs, instead of one of the UEs being disconnected. The configuration is set as user or operator controlled PLMN selector with a priority list in the USIM. Such USIM configuration can be provided in advance. The a priori lists for the UEs 100, 200 should be such as to minimize the chances that the two UEs in the system select the same PLMN, i.e., for PLMNs that are available at the same area, different UEs in the same system 10 should set different PLMNs with higher priorities. In this case, the priority lists of the different UEs are coordinated, but the selection process itself is not coordinated between the UEs - that is an advantage, since such co-ordination may be more complex to implement in a system, and would make the system 3GPP specific. A feature of this approach is that it is possible for the operator to assign a higher priority for a given PLMN than the HPLMN. This can be possible if the HPLMN (and its equivalent PLMNs) are assumed a certain given priority as part of the user controlled PLMN selector or operator controlled PLMN selector, where the HPLMN priority may be exceeded by other PLMNs. This is necessary to allow cases when only one UE in the system connects to the HPLMN whereas another UE in the same system 10 connects to a different PLMN. It might even be possible for a UE to have the HPLMN as a forbidden PLMN. The approach in the paragraph below which indicates a priority list.

1 . User controlled PLMN selection

2. Operator controlled PLMN selection

3. Other PLMNs with sufficiently good signal strength in random order

4. PLMNs in decreasing order of signal strength

It should be noted that the HPLMN/EPLMNs may be included in 1 to 4 as well. Furthermore the UEs in the same system set different PLMNs for the highest priority using 1. or 2..

Additionally priorities may be specific per (PLMN, access type) combination.

Co-ordinated dynamic approach: The dynamic approach can be extended with coordination of the PLMN selection. When one UE in the system, e.g. UE 100 has connected to a PLMN, that PLMN is down-prioritized in the PLMN selection process for other UEs, e.g. UE 200 in the same system 10. The UE needs to be able to set a list of PLMNs which are selected with a lower priority, even if the given PLMN is otherwise assigned a higher priority by the operator or user. Note however that PLMNs which do not have a sufficiently good signal strength should be treated with even lower priority. Between the down-prioritized PLMNs, it is possible to keep a priority ordering such as., consider user controlled PLMN selector first, operator controlled PLMN selector second, and other PLMNs with sufficiently good signal strength third. The solution is illustrated in the paragraph below.

Normal Priority PLMNs

1 . User controlled PLMN selector

2. Operator controlled PLMN selector

3. Other PLMNs with sufficient good signal strength in random order 2. Low priority PLMNs

1 . User controlled PLMN selector

2. Operator controlled PLMN selector

3. Other PLMNs with sufficiently good signal strength in random order

3. PLMNs in decreasing order of signal strength

Note 1 : PLMNs that other UEs in the device attach to are regarded as low priority PLMNs Note 2: A low priority PLMN may cause other PLMNs to be regarded low priority.

Note 3: HPLMN/EPLMNs may be included in 1 and 2 as well.

Note 4: UEs in the same device set different PLMNs for the highest priority using 1.1 -1 .2. Note 4: Priorities may be specific per <PLMN, access type> combination. This approach requires co-ordination between the UEs 100, 200 within the system 10.

Hence, in this case the system 10 needs to have 3GPP specific functionality for this coordination. Also, the system 10 needs to make sure that the UEs in the system attempt to set up their network connections in sequence, one after the other, so that the down-prioritization can take place in the UEs during PLMN selection, considering the other UEs that are already connected based on UE-UE communication within the system 10. Note that a UE that is already connected may re-connect later to a different network, and therefore the down- prioritization process should be applied for such re-connection attempts as well.

The co-ordinated dynamic case is especially useful for systems which might be roaming in different countries, where it can be very difficult to list all the potential PLMNs in a PLMN list which the UEs may connect to. In this case, we have a roaming situation where UEs may randomly select a PLMN with sufficiently good radio coverage. In case of such randomized selection, it is necessary to have co-ordination between UEs to avoid that other UEs select the same PLMN.

The down-prioritization process should be extensible such that for a given PLMN which another UE in the same system has already connected to, there could be a list of PLMNs which are down-prioritized. Such a PLMN list is needed to handle cases when multiple equivalent PLMNs connect to the same network. Also, for network sharing situations it is possible that two PLMNs share (parts of) the core network, and those other PLMNs should also be down-prioritized. As a further generalization, it could be possible to introduce levels in the down-prioritization, so that one PLMN is down-prioritized more than another PLMN. E.g., if when one UE in the system 10 uses a PLMN, that PLMN is down-prioritized more, whereas another PLMN which shares only part of the core network with that PLMN is down- prioritized less.

The down-prioritization could also be specific on a per access type basis. I.e., it could be possible to down-prioritize only a given pair of (PLMN, access type). It could also be possible to use different levels of down-prioritization for the different access types, i.e., down-prioritize a given access type of a PLMN more, while also down-prioritize other access types of the same PLMN less. This can also take into account that not all access types may need the same level of reliability.

Network-assisted PLMN selection in the UE

It is possible for the network and the mobile operator to further support the mechanisms described above for the UE-only PLMN selection using network assistance. Such assistance could be provided in several forms.

Over the air configuration of the USIM. Such configuration methods might include messages, e.g. using configuration SMS's, but are also possible over IP connectivity. Such configuration can be used to set the priority lists of PLMNs, and also the configuration for which PLMNs to down-prioritize together. Such configuration can be provided as part of a bootstrapping procedure: the UE first sets up connectivity using normal PLMN selection. Then the HPLMN can use over the air configuration of the UE. After that, the UE can connect again, using the new configuration, to the appropriate PLMN. The difference compared to cases above is that in this case the network sends configuration information to the UE, instead of UE pre- configuration.

Network-based UE co-ordination. This approach is to support the coordinated dynamic approach for the UEs in the same system 10. Such co-ordination is possible within the system itself, however in many cases it may be difficult to realize such co-ordination in the system, since it affects low-level system procedures in the UE which are often not easy to control from outside the UE. This approach involves at least one of the following aspects: A network entity is used, here referred to as RCF (Redundancy Co-ordination Function), which collects information about the connectivity status of the UEs within the same system. The RCF is responsible for the network-based coordination of the UEs within the system. When one of the UEs in the system 10 connects or disconnects, the RCF is notified. For this, the control plane entities (MME (Mobility Management Entity )/SGSN (Serving GPRS Support Node) nodes) in the network may communicate with the RCF.

UEs in the same system 10 are identified with a system name, which is also communicated to the network. UEs with the same system name are considered to be in the same system 10. The system name configuration should be secured, in order to avoid abuse. One way to accomplish this is to have the system name as part of the USIM configuration. Another way is to use e.g., an industrial system for name configuration which has an underlying security mechanism as well, and could provide support for the configuration of the system name. The two approaches can also work in combination, e.g. an industrial system configures the system name into the system, and that in turn is configured into the USIMs of the UEs.

The system 10 should make sure that the UEs 100, 200 attach to the network one after the other, rather than all at the same time. This allows the network to co-ordinate the UE attachments one by one.

Note that the RCF functionality may be implemented in the HSS (Home Subscriber Server). One advantage is that the HSS may already be involved during attachment, and the HSS is already accessible from the VPLMNs. However, the signaling optimizations which disable HSS signaling during the Attach procedure need to be disabled, or the HSS explicitly notified during the Attach procedure. Also, the HSS needs to be notified about the detachment of a UE. It could be possible to have an RCF functionality which is not co-located with the HSS, however such an entity would need to be reachable over the roaming interfaces from the VPLMNs.

The RCF may send information to the UEs 100, 200. This may be based on explicit control signaling, however that would then need to be

implemented in the VPLMNs as well. Or alternatively such information could use system configuration means as mentioned above, e.g. over SMS's or over IP. • The information sent to the UEs may contain the following: which

PLMNs (or optionally also which access) the other UEs in the same system are connected to; or which PLMNs a given UE should down-prioritize; the latter may be a bigger list, since multiple PLMNs may be down-prioritized as a result of a UE connecting to a PLMN, as discussed in the previous section above. Again, the

PLMNs may be specified in combination with the access types.

Using the above components, the PLMN selection of the different UEs 100, 200 in the same system can be coordinated. When the UEs receive updated information from the RCF, they can attempt to re-connect to a different PLMN (or access type) when needed.

One example of how the network assistance may help is shown in figure 4. In this case the following steps are carried out. Steps S1 -S3: UE-A attaches to PLMN 1 , and the RCF is also informed about the attachment in step S2. The PLMN also gives information about the identity of PLMN 1. The PLMN1 may also give information about the access type (radio access technology) as well.

Steps S4-S6: Similarly, UE-B attaches also to PLMN 1 , and the RCF is also informed. Step S7: The RCF detects that two UEs from the same system have connected to the same PLMN. The RCF decides to direct UE-B to another PLMN. It might be better to direct UE-B to another PLMN rather than UE-A, since UE-B has just connected and therefore it has not had any significant traffic yet. The RCF updates the forbidden PLMN list of UE-B using some remote configuration method (e.g., SMS based on IP based over the air configuration.) The remote configuration may be done with the help of another network entity responsible for system configuration.

Steps S8-S13: As a result of the new configuration from the RCF, the UE-B detaches from PLMN 1 and attaches to PLMN 2.

Note that in some UEs, the home PLMN might not be considered forbidden. In this case, it is beneficial if the UE is considered always roaming, i.e. it is assigned a PLMN which it never connects to directly. This can be achieved e.g., by using a virtual home operator. Note also that the use of the forbidden PLMN list can cause the solution to become a static solution, in the sense that if one UE of a system connects to a given PLMN, another UE from the same system will never connect to the same PLMN.

Possible variants as optional enhancements:

The RCF may give an immediate response to about the requested UE reconfiguration, and that may be delivered to the UE already as part of the Attach procedure. In case the reconfiguration indicates that the given PLMN is forbidden, then the network may return an Attach Reject instead of an Attach Accept. This is shown in Figure 5. In this case, the RCF acknowledges the messages received (step S23), so that it is possible to decide whether the attach procedure should proceed or the attachment should be rejected. An advantage of this approach is that it can avoid some of the signaling such as steps S 8 to S 10 of Fig. 4, especially that it avoids UE-B unnecessarily attaching to PLMN1 and then detaching from it soon after. Otherwise step S S21 and S 22 correspond to steps S1 and S2, steps S3 to S 5 correspond to steps S24 to S26, and steps S29. S 30 and S32 correspond to steps S1 1 to S13.

Instead of using the forbidden PLMN list, it is also possible to just down-prioritize the given PLMNs. As an advantage, this makes it possible for multiple UEs of the same system to connect to the same PLMN if separate PLMNs are not available. The down-prioritization feature can be realized as described above for the UE based case. A disadvantage of this approach though is that such down-prioritization feature is required in the UE, and that is not currently part of the specifications. This is shown in Fig. 6. Down-prioritization is possible both as part of the Attach procedure as shown by step S47, or afterwards as in the previous figure. Note that in this case, the UE's attachment to PLMN1 was accepted, since the UE might still use PLMN 1 if that is the only one available. In this example, there were other PLMNs, hence the UE detaches from PLMN 1 and attaches to PLMN 2. Steps S41 to S36 correspond to steps S 21 to S26, steps S49 to S55 correspond to steps S8 to S13 with an additional acknowledgement message in step S54 sent from the RCF to PLMN2.

Instead of configuring the system name into the UEs of the system, it is also possible to have network configuration to determine the system name. The system name could be derived from an identifier of the UE such as the IMSI or IMEI. The mapping could be performed in the HSS or MME or some other entity.

UEs connect to different network slices (Dedicated Core Networks) in a PLMN

Network slicing is a concept under discussion, which allows a single physical network to realize a set of logical networks. See e.g., NGMN 5G White Paper,

https://www.ngmn.org/uploads/media/NGMN_5G_White_Paper_V1_0.pdf, section 5.4 for a discussion on network slicing. One possibility to define network slicing is as follows. "Network slice is a set of all the required network resources together configured as a logical network used to serve a defined business purpose or customer. It is created, changed and removed by management functions."

It is clear that network slicing is a concept which allows the operator to partition the network so that the different partitions can be isolated from each other from a resource usage point of view. Such partitioning could apply to the full core network, or only parts of the network, where other parts remain common and shared by the network slices.

Network slicing can help to make the network more reliable. When multiple UEs are used within a single system 10, the UEs 100, 200 can be directed to different slices of the same network. Should a failure occur in one of the slices, there is a higher likelihood that other slices may be unaffected by the failure and the system may continue to be connected. The reliability of the overall system can be further improved if the slices are managed separately, e.g., software upgrades are done in only one slice at a time; the software and/or hardware vendor may be different in the slices, or the personnel operating the slice may be

independent, or the slices may be placed at different locations.

The network slicing concept, to a certain degree, is already made possible by the use of the Dedicated Core Networks feature of EPC, as described in 3GPP TS 23.401 section 4.3.25. This is based on a network mechanism whereby a subscription parameter Usage Type is defined for the UEs. The Usage Type parameter can influence the selection of the MME node; when it is determined that a given UE should be served by another MME node, it is possible to perform a re-direction procedure to a target MME node. In this way, network slicing can be realized: the UE is re-directed to a MME in the appropriate network slice, which can also select the user plane nodes in the given network slice accordingly. Extensions to the Dedicated Core Network (DCN) feature may be defined to make it a more general slicing concept. Currently, the UE cannot influence the Dedicated Core Network. A Requested DCN id (or a similarly named parameter) may be given by the UE, which could influence the MME selection (or corresponding 5G functionality which terminates the signaling from the UE). It is possible to take the Requested DCN id into account in the RAN during the selection of the MME, and select an MME entity from a different set for each Requested DCN id. Alternatively, it is possible to use a re-direction mechanism initiated from the core network to re-direct a user from one DCN to another, based on the requested DCN id and a combination of other parameters, such as the Usage Type subscription record or local configuration.

Below, solutions are provided how the different UEs 100, 200 in the system 10 may connect to different slices (i.e., DCNs) within a given PLMN. For this, the possibility of both the existing core network redirection mechanism, or a possible UE information based DCN selection mechanism is considered.

UE-only slice (DCN) selection

This approach relies on the possibility of the UE providing the Requested DCN id parameter to the network. UEs can be configured with a Requested DCN id, which is different for each UE in a given system. This approach is especially useful for cases when the systems operate in a known PLMN where multiple DCNs are in operation with similar or compatible characteristics, deployed for redundancy reasons.

To help systems operate also in roaming scenarios, it may be useful to structure the requested DCN id parameter, so that the redundant slices - when available - can be represented as a sub-structure below a given DCN id. I.e., DCN X.1 , DCN X.2 etc. denote the redundant instantiations of slice X. In this way, even if the UE connects to a VPLMN and determines to connect to a given DCN by some type of bootstrapping procedure, it may try to use this structured DCN identification to attempt to connect to redundant instances when they are available. However, even if the requested DCN id parameter is not structured in this way, the UE may be configured with the relevant values of the redundant DCNs.

The DCN id to be used by the UEs could also be provided in the UEs by a priori

configuration. Alternatively, if the Requested DCN id parameter is structured, the UEs within the system may connect with a separate .1 , .2 etc. identifier following a well-defined or random order, so that the UEs connect to different slices.

Figure 7 shows an illustration of the UE-based slice (DCN) selection applied for connecting to different DCN from the UEs 100, 200 in the same system 10. In this case, the slice selection is based on parameters configured into the system. UE 100 selects slice 71 whereas UE 200 selects slice 72. In this example shown in Fig. 7, slice (DCN) X has two redundant instances71 , 72, while slice (DCN) Y 75 does not have any redundancy protection on a slicing level.

As another option, it is also possible that the UEs 100, 200 in the system 10 are not pre- configured with a specific DCN id. Instead, in-system co-ordination can be used to make sure that each UE in the system connects to a different DCN; once a UE has connected to a DCN, the id of the DCN is made known to other UEs in the same system so that they do not use the same DCN. Each UE in this case can pick from a set of DCNs which could be pre- configured.

In case the system uses only one of the slices for active data traffic and the other slice as a backup for redundancy, then it can be useful that the load is distributed evenly between the network slices. In case of UE based solutions this can be achieved by a randomized configuration where some systems connect to one slice (DCN) and other systems connect to another slice (DCN) for active communication.

Network assisted slice (DCN) selection in the UE

A bootstrapping procedure may be used to assist the UEs in determining the Requested DCN id. The UE in that case first connects to a default DCN, where it gets assistance from the network in determining the Requested DCN id. The bootstrapping procedure can provide the corresponding redundant DCN instances that the system 10 should use. Then the UE connects again using the Requested DCN id information. Such a flexible procedure may be used e.g., in a roaming scenario where the UE does not have sufficient configuration to determine which DCN to connect to.

The bootstrapping process may use information provided by the UE. E.g., the UE may give information whether it is the first, second etc. UE connecting from the given system, and the bootstrapping procedure may return different Requested DCN id values to the UE. This can be realized in the network based on configuration. Such configuration could be provided e.g., from a separate node, or from the MME node, or in other nodes. This approach requires appropriate configuration in the system 10 to set the order of UEs connecting to the network. The solution is illustrated in Figure 8. The UEs first attach to a default DCN (steps S61 and S66) where they can execute a bootstrapping procedure. This is done with the help of a DCN Configuration entity. The UE contacts this entity and provides its sequence number within the UE (stepS62). The UE may also give some characteristics of the type of network slice/DCN that it wants to connect to (e.g., slice for mobile broadband, machine type communications, delay or reliability requirements etc.) Based on this information, the DCN configuration provides the DCN identifier to the UE (step S63). The UE then attaches to the given DCN (step S65). Note that the DCN configurator entity could be combined with the MME entity, it can also be possible to perform the message exchange already within the Attach procedure. E.g., the UE can provide the needed parameters in the Attach Request message, and the MME can provide the DCN configuration response in the Attach Accept or Attach Reject messages. Similar steps are carried out for UE-B in steps S66-S70.

As a way to distribute the network load evenly between the slices/DCNs in case the system only uses one UE for active communication, it is possible that the system randomly selects whether it uses the first, second, etc. UE in the system for active communication.

UE indication of the redundancy instance in case of network slice (DCN) selection

In this case, shown in Fig. 9, the slice for the UE is determined in the network (step S72) after an attach request in step S71. However, the UE provides assistance data for the network to help it determine the target slice/DCN redundancy instance, so that the UEs in the same system can be directed to different slice/DCNs. One way to provide such assistance data is that the UE provides a numbering for the UEs within the system as done in step S71 : UEs within the system are numbered as 1 , 2, ... using system configuration. This information can then be taken into account in the network together with other information (such as Usage Type subscription record), so that the UEs in the system are redirected to different slice/DCNs whenever possible.

This approach is illustrated in Figure 9. The UE's Attachment request (step S71 ) is initially forwarded to a default MME which then performs the DCN selection (S72). The UE also provides the sequence number parameter to indicate which UE it is within the system. This is taken into account in the DCN selection, so that the UEs in the system are directed to different DCNs if possible (S73 to S74 and S77, S78). The re-direction from the default DCN to the selected DCN may take place via the RAN as well (not shown in the figure). The network may inform the UE about the identity of the DCN which was eventually selected. As another option, as shown in Fig. 10, it is also possible that instead of the sequence number, the UE provides the identity of the other slices/DCNs used by the other UEs in the system as shown by step S85. This requires that this information is coordinated between the UEs within the system. The network down-prioritizes the DCNs that are already used by the other UEs in the same system. In the example shown UE-B informs the MME in step S85 that UE-A has selected the DCN with identity X.1. This DCN is down prioritized in the selection step S86 and another DCN is selected and informed in step S87.

UEs connect to different MMEs in a given slice

It is also possible that the UEs connect to the same slice/DCN in the same PLMN, but the operator would like to achieve redundancy by having the UEs connect to different MMEs. (Alternatively, the corresponding 5G entity instead of MME may also be applicable.) The MME selection is always performed in the network (in the eNB, or in the old MME/SGSN in case of relocation procedures). Therefore, only network based mechanisms are applicable for this case, however the UE may also assist the mechanisms.

As a solution option, the UEs supply a list of GUMMEIs which identify the MMEs of the other UEs in the same system. This list could be constructed within the system in case the UEs coordinate this information. The list can be supplied on both RRC (Radio Resource Control) and NAS level, so that it is available for the MME selection in RAN, and also for the MME selection in the CN.

The solution is illustrated in Figure 1 1 . UE-A attaches to MME1 normally (step S91 ). Once attached, UE-A co-ordinates the identity of MME1 within the system (step S93) with UE-B. Hence, UE-B can supply the identifier of MME1 (i.e., it's GUMMEI) to the eNB (S94) so that the eNB, when possible, excludes that from MME selection. As a result, the eNB selects MME2 for UE-B (step S 94). Note that the solution is also possible based on re-direction between MMEs as well. UEs connect to different user plane entities

The UEs within the same system 10 are configured with different APNs. The solution is illustrated in Figure 12. APNs are used to guide the network selection of user plane nodes and external PDNs. UEs can be configured with different suffixes to the same base APN. For example, the APN string "factorynet" could be suffixed as "factorynet-1 ", "factorynet-2", etc. in the message sent from the system to MME 81 and to MME 82, for the UEs in the same system to indicate the different user plane entities for redundancy. The user plane node selection in the MME is configured such that different SGW and PGW nodes (or other user plane nodes when applicable) such as gateways 91 or 92 are used for these APNs. The MME's selection of user plane nodes is typically based on DNS configuration, therefore this would require to make the appropriate DNS (Domain Name System) configuration as well in the DNS 95. Also, PGW nodes 91 and 92 also need their appropriate configuration for the APNs they serve. Hence, for this solution to work, the UE configuration and the network configuration should be harmonized.

Network assisted UE based solution

Instead of a priory system configuration of the APN strings, it is also possible to have the operator configure the APNs of the different UEs in the system 10. This could be based on an automatic system configuration. One possible signaling flow is illustrated in Fig. 13 where the different APNs are provided to the two UEs in steps S103 and 108. There could be many variations of the signaling.

The UE first connects to the network with a default APN (step S101 ). The UE then contacts (stepS102) the "APN configuration". This may be a separate entity, or co-located with other entities such as the GW or the MME. The UE may supply a system name (common for all UEs in the system), or a sequence number of the UE in the system (1 , 2, ...). Alternatively, an identifier such as the IMSI or IMEI could be mapped to a system name or sequence number. Also, the network could map the IMSI or IMEI to a sequence number. The UE may also provide other information (such as the characteristics of the user plane it intends to use) to the APN configuration. Based on the input information, the APN configurator sets up (step S103) the UE's APN so that it will be different for the UEs within a given system. The configuration could be done e.g. via configuration SMS's or by an IP based configuration protocol. Afterwards, if needed, the UE disconnects from its default user plane (step S104), so that it can connect to the user plane using the newly configured APN (step S105). A similar procedure is applied for UE-B. UE indication of the redundancy instance in case of network based user plane selection

In this option, shown in Figure 14 the UE does not set the APN string differently for the different UEs in the same system; all UEs 100, 200 in the system 10 send the same APN string. The network has the responsibility to assign different user plane nodes for the UEs in the same system such as modes 91 , 92. However, the UE provides an indication about which of the redundancy instances to use.

The UEs are configured with a sequence number in the system (1 , 2, ...), which is also sent to the network during the establishment of a new data connection. The user plane path depends on this sequence number.

Once a sequence number of the UE within the system is available, the MME's selection of the user plane nodes takes this into account and selects different user plane nodes for each sequence number. This could be accomplished by the MME 81 , 82 automatically adding a suffix including the sequence number to the APN string before making the DNS query for the user plane node selection. The sequence number could also be sent to the DNS system 95 as a parameter of the DNS query. Alternatively, the sequence number could be taken into account after the DNS query is already made: when the DNS response includes several possible user plane nodes 91 , 92, the MME 81 , 82 can choose between them based on the sequence number. E.g., the DNS response could include separate user plane nodes for the different sequence numbers.

The solution of Figure 14 is a more flexible solution compared to the UE-based approach, as the APN in the UE does not need to be explicitly changed, and the redundancy can be provided based on a separate parameter.

Figure 15 shows a schematic architectural view of a system 10 with a mobile entity 100 and a mobile entity 200. The mobile entity 100 corresponds to one of UE-A and UE-B UE mentioned above in connection with the different flow charts and comprises an interface 1 10. The interface is provided for transmitting user data or control messages to other entities via a transmitter 1 1 1 and to receive user data and control messages from other entities using receiver 1 12. The interface is especially qualified to communicate with the different entities as shown in the different flow charts discussed above. The interface 1 10 is furthermore configured for a wireless data exchange and for a wired data exchange. Furthermore, a processing unit 120 is provided which is responsible for the operation of the mobile entity 100. The processing unit 120 comprising one or more processors can carry out instructions stored on a memory 130 wherein the memory may include a read-only memory, a random access memory, a mass storage or the like. The memory can furthermore include suitable program code to be executed by the processing unit 120 so as to implement the above described functionalities of the mobile entity 100. The memory can further include the lists of selection parameters used by the mobile entity to select a core network entity.

The mobile entity 200 shown in Fig. 15 can correspond to the other of UE-A and UE-B and comprises an interface 210 configured for the communication with other nodes or entities such as the mobile entity 100 or any other nodes of the cellular system mentioned above. An interface 210 is configured to exchange control messages and user data including a transmitted 21 1 and a receiver 212. A processing unit 220 is provided comprising one or more processors wherein the processing unit 220 is responsible for the operation of the radio access node 200. A memory 230 is provided which can include a read-only memory, a random access memory, a mass storage or the like. Memory 230 can include suitably configured program codes to be executed by the processing unit 220 so as to implement the above described functionalities in which the radio access node 200 is involved. The memory 230 can further include the lists of selection parameters used by the mobile entity to select a core network entity.

In the solution shown in Fig. 15, each functional unit discussed above is provided for each mobile entity. As discussed above in connection with Fig. 2 the system may also use one of the functional entities shown in Fig. 15 for both mobile entities.

It should be noted that the structures illustrated in Figs 15 are only schematic and that they may comprise further functional entities, which, for the sake of clarity, have not been illustrated.

From the above discussion, some general conclusions can be drawn.

As far as the system with two mobile entities is concerned, when the selection of the network entities by the method parameters is carried out in the system itself, the system may be configured such that based on predefined parameters the first mobile entity always selects a first network entity and the second mobile entity always selects a second network entity which is necessarily different from the first network entity as the two lists will not have network parameters in common which would allow the selection of a common network entity in the core network.

The first mobile entity and the second mobile entity can be located in the same housing or enclosure. The first network entity identified with the first network parameter can belong to a first public land mobile network, PLMN, and the second entities that identified by the second network parameters belong to a second Public Land Mobile Network, PLMN that is different from the first PLMN. Furthermore, it is possible that the first network entities identified by the first network parameters and the second network entities identified by the second network parameters belong to different slices of one PLMN. In this context it is possible that each mobile entity provides a unique identification to the PLMN, by which the corresponding mobile entity within the system is uniquely identified. Furthermore, each mobile entity can receive at least one network slice identifier uniquely identifying the slice within the PLMN. The corresponding mobile entity then selects the network sliced based on the received at least one network slice identifier.

The first network entities identified by the first parameters and the second network entities identified by the second parameters may also be different network entities of one PLMN, wherein the first and the second network entities are each responsible for a control plane signalling towards one of the mobile entities in the system. In the embodiment the two mobile entities in the system each select different core network entities which are responsible for the control plane signalling towards the corresponding mobile entity.

The first network entities determined with the first network parameters and the second network entities determined by the second parameters may be different network entities responsible for an exchange of user plane data with the corresponding mobile entities. In a further embodiment the relationship between the network entity and the mobile entity of the system, is not static, but a dynamic relationship is provided where the mobile entities preferably connect to different core network entities, but if one of the network entities is not available, the affected mobile entity could also connect to the same core network entity as the other mobile entity in the same system.

In this embodiment the selected first network entity with the highest priority from the first list and the second selected network entity with the highest priority from the second list can belong to different PLMNs. However this two network entities with the corresponding highest priority may also belong to different slices of one PLMN.

Furthermore, the network entities with the highest priorities can also be different network entities which are responsible for an exchange of user plane data with the corresponding mobile entity.

In the two embodiments described above the selection of a network entity by one of the mobile entities 100, 200 did not influence the selection of the network entity in the other mobile entity. There is additionally a coordinated selection or coordinated dynamic relationship for the selection process in the two mobile entities. Here the second mobile entity in the system 10 is informed about the network entity to which the other mobile entity, the first mobile entity, in the system is connected to. The mobile entity that is connecting to the network later than the other mobile entity in the same system preferably connects to a different network entity. In this embodiment the system with the 2 mobile entities can also use the different selection parameters with the corresponding priority levels. When one of the mobile entities connecting to the network later than the other mobile entity is informed about the network entity to which the mobile entity that connected earlier, is connected, the priority levels of the network entities selected by the earlier mobile entity can be decreased for the second mobile entity such that the second mobile entity preferably connects to a different network entity. In more detail this means that the at least one memory of the system stores a first list containing different first selection parameters used by the first mobile entity to select the first network entity when connecting to the cellular network, wherein the different selection parameters have different priority levels. Furthermore, a second list containing different second selection parameters used by the second mobile entity are provided to select the second network entity when connecting to the cellular network, wherein the different second selection parameters have different priority levels. The first mobile entity (or the mobile entity connecting earlier than the other mobile entity) then selects the first network entity based on the first selection parameter having the highest priority from the first list. The first mobile entity furthermore initiates a reduction of at least one priority level of the second selection parameters in the second list such that when the second mobile entity selects the second network entity based on the second selection parameter having the highest priority level, the second network entity is different to the first network entity. It is possible that the second mobile entity and the first mobile entity each select network entities which belong to different PLMN ends.

The second mobile entity, the mobile entity that is connecting later, may receive an indication which can be used by the second entity to determine to which first network entity the first mobile entity ( the mobile entity that connected earlier), is attached. In other words, the mobile entity that is connecting later in the system receives an indication to which network entity the mobile entity that connected earlier is connected. The mobile entity that connects to the system later can then determine a network entity that is different to the network entity to which the first mobile entity is connected to.

Furthermore, the second mobile entity that is connecting later can determine an entity identifier identifying the first network entity which the first mobile entity is connected to. When the second mobile entity then attaches to the network and transmits an attach request to the radio access network, it includes the network entity identifier the network nodes which network entity the first mobile entity in the system is connected to. The network can then make sure that the second mobile entity attaches to different network entity.

For the solution discussed above a cooperation of the mobile entity was necessary in order to carry out the necessary steps. In the following a solution will be explained in more detail in which the cellular network is mainly responsible for selection the redundant network entity used by a system with two mobile entities for communication.

Solution with network based selection of the network entities

The solution discussed below and shown inter alia in Fig. 16, involves multiple mobile entities/UEs, 410, 420 denoted as UE-A, UE-B, etc. within a single system 400 for redundant communications. In many scenarios, the reliability of the solution is of very high importance, which justifies the cost of more the one UE integrated in the same system. The UEs connect to a CN entity 610, 620, 630 in the core network over the RAN. A CN entity selection process is responsible for selecting the appropriate CN entity for a given UE to provide redundancy handling for the certain (industry) system. The CN entity selection process is such that the UEs within the same system are preferred to connect to different CN entities. In this way, the communication of the UEs within the same system are independent, and therefore the impact of a failure at a CN entity can be limited to a single UE. The basic solution is shown in Fig. 16. The invention considers a CN entity selection unit 500 in the network. Note that the CN entity selection unit 500 may be co-located with RAN or one of the CN entities, such as entities 610, 620 or 630 shown in Fig. 16, or may take place in a standalone entity. While the solution is described based on the presence of two UEs 410, 420 in the system

400 (option a in Fig. 17), it must be noted that some parts or all of the physical hardware 430, may be common for the two UEs (option b). It is possible that the two UEs use the same radio transceiver; that is especially suited for the cases when the CN entities are reachable via the same RAN. Hence, the UEs may correspond to logically different UEs that use the same physical UE.

As another example, the two UEs could have a common SIM/USIM for e.g., identity and authentication. This is a hybrid case between option a and b. In that case, the two UEs 410, 420 can use the same credentials to authenticate themselves. In this case, however, the different UEs still need to differentiate themselves to the network, which can be done e.g., by adding an additional identifier such a sequence number which tells the two UEs apart for the network.

Further, it is also possible that instead of two UEs in the system, there is only a single UE 440 in the system 400 but the system supports multiple connections from a single UE (option c in Fig. 17).

There are several options regarding what type of CN entities are treated in this way. • CN entities may correspond to different slices of the same PLMN. Network slicing is an emerging concept, where a single physical network supports multiple logical networks called slices. Network slices may be isolated from each other, so that a failure of one network slice may not impact another network slice. Here the slice is used for a special purpose: providing reliability (e.g providing two independent paths from a certain system to another one through the RAN and CN). In this case multiple slices are instantiated with the purpose that failure of one slice should not impact the other slice(s). Slicing is considered from a core network point of view, where different slices correspond to different Dedicated Core Networks (DCNs).

• CN entities may correspond to different MMEs. An MME is the control plane entity in EPC whose responsibility includes NAS signaling with the UE. Note that for 5G networks, a different control plane entity may be defined with a corresponding role, for which the invention may be similarly applicable. · CN entities may correspond to different user plane nodes such as the SGW and PGW in EPC. This is a complementary approach to the previous case.

• Any combination of the above.

Note that the CN entities such as entities 610 to 630 are assumed to belong to the same PLMN, since PLMN selection is UE based rather than network based.

The selection process and the corresponding configuration may be such that UEs 410, 420 are distributed in a balanced way between the CN entities, rather than having a majority of the UEs using only a single or limited set of CN entities.

With regards to the relationship of a given UE within a system to a given CN entity in the network, the following main options can be differentiated. • Static relationship. A given UE is always connected to a given CN entity or set of CN entities that are different for each UE in the system 400, so that the different UEs in the system 400 is never connected to the same CN entity. If no CN entity is available for a UE, the UE will not be selected to connect to another CN entity that is associated with another UE in the system. Such a static relationship can be simple to set up, but its application may be limited to cases when the networking environment is well known in advance. This approach is less flexible: if the corresponding CN entity (or set of CN entities) is down, then no reliability can be guaranteed even if other CN entities were available.

• Dynamic relationship. A given UE is preferably connected to a given CN entity or set of CN entities so that the CN entity is preferably different for all UEs in a system 400, but if that is not available the UE can be selected to connect to a CN entity which could be the same as the CN entity for another UE in the system. A dynamic approach can also incorporate a priority list as well to guide the selection. Such a dynamic relationship can also be flexible to handle a networking environment which may change, e.g. due to mobility or failures.

• Coordinated dynamic relationship. The selection process of the UEs in the same system 400 are coordinated, so that they preferably connect to different CN entities. Such coordination can take place in the network in a network entity. The coordinated dynamic approach can be especially useful if the selection of the CN entity is randomized. In that case, coordination is necessary to make sure that the UE which is connecting to the network after another UE in the same system gets to a different CN entity. Another benefit of coordination is that it is possible to know whether the UEs actually connect to different CN entities or not, and in that way determine the current level of redundancy in the system.

Network slicing is a concept under discussion, which allows a single physical network to realize a set of logical networks, see e.g. NGMN 5G White Paper,

https://www.ngmn.org/uploads/media/NGMN_5G_White_Paper_V1_0.pdf section 5.4 for a discussion on network slicing. One possible definition of network slicing is as follows:

"Network slice is a set of all the required network resources together configured as a logical network used to serve a defined business purpose or customer. It is created, changed and removed by management functions." However, it is clear that network slicing is a concept which allows the operator to partition the network so that the different partitions can be isolated from each other from a resource usage point of view. Such partitioning could apply to the full core network, or only parts of the network, where other parts remain common and shared by the network slices.

Network slicing can help to make the network more reliable. When multiple UEs within a single system are present, the UEs can be directed to different slices of the same network. Should a failure occur in one of the slices, there is a higher likelihood that other slices may be unaffected by the failure and the system may continue to be connected. The reliability of the overall system can be further improved if the slices are managed separately, e.g., software upgrades are done in only one slice at a time; the software and/or hardware vendor may be different in the slices, or the personnel operating the slice may be independent, or the slices may be placed at different locations. The network slicing concept, to a certain degree, is already made possible by the use of the Dedicated Core Networks feature of EPC, as described in 3GPP TS 23.401 section 4.3.25. This is based on a network mechanism whereby a subscription parameter Usage Type is defined for the UEs. The Usage Type parameter can influence the selection of the MME node; when it is determined that a given UE should be served by another MME node, it is possible to perform a re-direction procedure to a target MME node. In this way, network slicing can be realized: the UE is re-directed to a MME in the appropriate network slice, which can also select the user plane nodes in the given network slice accordingly.

Extensions to the Dedicated Core Network (DCN) feature may be defined to make it a more general slicing concept. Currently, the UE cannot influence the Dedicated Core Network. A Requested DCN id (or a similarly named parameter) may be given by the UE, which could influence the MME selection (or corresponding 5G functionality which terminates the signaling from the UE). It is possible to take the Requested DCN id into account in the RAN during the selection of the MME, and select an MME entity from a different set for each Requested DCN id. Alternatively, it is possible to use a re-direction mechanism initiated from the core network to re-direct a user from one DCN to another, based on the requested DCN id and a combination of other parameters, such as the Usage Type subscription record or local configuration. Below, we give solutions how the different UEs in the system may connect to different slices (i.e., DCNs) within a given PLMN. For this, we consider the possibility of both the existing core network re-direction mechanism, or a possible UE information based DCN selection mechanism.

Network based slice (DCN) selection

In this case, the slice for the UE is determined in the network.

A central entity, such as entity 500 of Fig. 16, coordinates the slice/DCN of the different UEs within the same system 400. Such central entity is called RCF (Redundancy Coordination Function), which may be realized in the HSS. The RCF is notified when a UE in a system connects to or disconnects from a given DCN. The DCN selection entity queries the RCF to supply a list of DCN ids which the other UEs have already connected to from the same system; these DCNs will be down-prioritized in the selection process. The DCN is then selected, and the result of the selection is stored in the RCF. The system name of system 400 can obtained in several ways.

• The UE supplies a system name. This requires assistance from the terminal. Note however that the UEs in the system supply the same system name, i.e., the UEs are not differentiated regarding their indication to the network.

• The system name can be configured into the network. This can be configured into the HSS subscription records, or as configuration data in the

RCF, or into MME configuration, or another database. This approach is applicable in case it is known to the operator which UEs are used in which system.

• The system name may also be derived from another identifier such as the IMSI or IMEI . In this case, those identifiers have to be structured appropriated so that the UEs within the same system have a coordinated identifier.

Such network based co-ordination can reduce the burden of system and UE configuration, and is more reliable against configuration errors.

The solution is shown in Figure 18. Note that the system id is either supplied by the UE, or configured into the network into some database. In this example, UE-A first attaches to a default DCN (step S121 ), where the MME queries the RCF whether another UE in the same system has already connected to a DCN (steps S122 and S123). Since there is no such UE yet, any DCN can be selected (step S 124). The attach procedure for UE-A is finalized by steps S 125 and S126. When UE-B connects in step S127, a query is sent to the RCF in step S128 and the latter notifies the MME that DCN X.1 is already used by the system (step S 129). Hence, that DCN is down-prioritized in the selection in step S130, and UE-B gets assigned to DCN X.2 with the attach steps S131 and S132. This is how the RCF could help in the co-ordination of the DCN selection. Note that the RCF needs to be notified not only when a UE connects to DCN, but also when it disconnects (detaches) from a DCN.

UEs connect to different MMEs in a given slice

It is also possible that the UEs 410, 420 connect to the same slice/DCN in the same PLMN, but the operator would like to achieve redundancy by having the UEs connect to different MMEs. (Alternatively, the corresponding 5G entity instead of MME may also be applicable.) The MME selection is always performed in the network (in the eNB, or in the old MME/SGSN in case of relocation procedures). Therefore, only network based mechanisms are applicable for this case.

As one solution option, when MME recognizes that there is a second UE from the same system, it applies a re-direction to another MME. The solution is shown in the signaling diagram in Fig. 19. For this solution, a system name needs to be supplied to the MME. This can be based on UE assistance by signaling the system name in a signaling message such as Attach Request from the UE to the MME based on UE pre-configuration (step S141 ). This can also be done based on network configuration of the system name, e.g. in the subscription record, or in the MME configuration, or in another database, or derived from another identifier such as the IMSI or IMEI. For a new UE, the MME checks whether there is another UE from the same system based on the system identifier (step S142). If not (as is the case for UE-A), the MME can accept the UE and the attach procedure is continued in step S143 and S144. If the check identifies the UE as the second from a given system (as is the case in step S145 for UE-B), then the UE is re-directed to another MME (steps S 146, S147). The re-direction may take place via the RAN (not shown in the figure). As a parameter, the message includes the identity of the original MME which should be excluded from the selection in MME2. This is a way to avoid re-direction loops that may arise, if MME2 were to re-direct the message back to MME1. Each MME adds its identity to the list of MMEs to exclude during the re-direction process. Note however that if there is no other MME, it is possible to use even those that would otherwise be excluded. UEs connect to different user plane entities

Network based solution

In this option, the UE does not set the APN string differently for the different UEs in the same system; all UEs in the system send the same APN string. The network has the responsibility to assign different user plane nodes for the UEs in the same system.

The network maintains a database of mapping the user ids such as the IMSI or IMEI to a sequence number. This is illustrated in Fig. 20, showing a Seq. Num. database 650 (which can be part of the HSS). This could be done when the network operator has a knowledge about which UEs are inserted into the same system 400. Such a database could be part of the HSS, i.e. the HSS includes the serial number for each user, or be part of UE

configuration, or stored in another database. As for the other cases, the user plane path depends on this sequence number. The MME appends the sequence number to the APN before making the DNS lookup in a DNS database 660 for GW 710, 720 selection.

As another variant, the sequence number may also be derived from other identifiers, such as the IMSI or IMEI. This does not require a database in the operator, but instead to make sure that the UEs in the same system have their identifiers configured appropriated such that the sequence numbers derived from the identifiers are different.

As yet another variant of this option, a central network entity RCF maintains the currently connected UEs from a system, and hence it can determine the sequence number of a newly connecting UE. For this, a system name is sent to the RCF, which is used to correlate the different UEs in a system. The RCF may e.g., be collocated with the HSS. The user plane path depends on the sequence number determined by the RCF.

The solution is illustrated Figure 21 . The RCF returns sequence number 1 for the firstly attaching UE in step S153, after the attach request of the UE-A in step S151 and after the information about the UE id is sent from the MME1 to the RCF in step S152. Based on the sequence number received in step S153, the MME performs user plane selection based on the APN suffixed by the sequence number (step S154). For the secondly attaching UE in step S 156, the RCF returns a different sequence number in response to the information sent in step S158, hence the MME (which can be different for the secondly attaching UE) suffixes a different sequence number, which guarantees that the user plane selection will be different, based on the appropriate configuration of the user plane selection process (S159). Note that the disconnection/detachment events should also be notified to the RCF (not shown in the figure) so that the RCF has an accurate picture of which UEs are connected to the system. As yet another variant, the MME may append its own identity to the APN string. This can work in cases when the MMEs are also selected such that they are different for each UE in the system. However, if there are not sufficient number of MMEs to have a separate one for each UE in the system, this approach is not applicable.

In conclusion the different embodiments have different advantages. When the mobile entities in the system are mainly responsible for selecting different network entities for the communication the device can communicate with the network with very high reliability. Even if one of the UEs in the system experiences a communication failure which could be e.g., due to a failure in a CN entity, the system can use another UE for communication. In this way, the system remains connected in a highly reliable way, and can recover from CN network failures with very low latency.

Fig. 22 shows a schematic architectural view of a network entity such as the CN entity selection unit 500. The entity 500 comprises an interface 510. The interface is provided for transmitting user data or control messages to other entities via a transmitter 51 1 and to receive user data and control messages from other entities using receiver 512. The interface is especially qualified to communicate with the different entities as shown in the different flow charts of Fig. 18, 19 and 21 discussed above.

The interface 510 is furthermore configured for a wireless data exchange and for a wired data exchange. Furthermore, a processing unit 520 is provided which is responsible for the operation of the entity 500. The processing unit 520 comprises one or more processors and can carry out instructions stored on a memory 530 wherein the memory may include a readonly memory, a random access memory, a mass storage or the like. The memory can furthermore include suitable program code to be executed by the processing unit 520 so as to implement the above described functionalities of the entity 500.

From the above discussion of the network based solution for a redundant communication some general conclusions can be drawn. According to a first option a network entity (500) of a cellular network may be provided which comprises at least one processor (520), and a memory (530), the memory containing instructions executable by the at least one processor. The network entity can be operative to receive a signaling message from one mobile entity (100) of a system (10) which comprises two mobile entities (100, 200). Furthermore, a query is transmitted to a coordination entity of the cellular network which is configured to coordinate a selection of control plane signaling entities for the mobile entities of the system (10), the control plane signal entities controlling a control plane signaling of the mobile entities. A query response is received from the coordination entity, the query response including an indication to which control plane signaling entity the other mobile entity of the same system is connected.

A control plane signaling entity is selected for said one mobile entity taking into account the received indication, and the signaling message is transmitted to the selected control plane signaling entity. In this first option mentioned above, the signaling message may be a query request.

According to a further aspect of option 1 , the network entity may further transmit information about the selected control plane signaling entity for said one mobile entity to the coordination entity in a second option.

According to a further aspect of option 1 or 2, in a third option, the control plane signaling entity selected for said other mobile entity may be identified based on the received indication, wherein the control plane signaling entity for said one mobile entity is selected based on priority parameters assigned to control plane signaling entities available for selection. The priority parameter of the identified control plane signaling entity can be reduced such that when the control plane signaling entity with the highest priority parameter is selected for said one mobile entity, the identified control plane signaling entity is not selected. Additionally, in a fourth option, the network entity according to any of the options 1 to 3 is further operative to determine a system identifier allowing the system in the cellular network to be determined, wherein the system identifier is included into the query transmitted to the coordination entity. According to an fifth option a control plane signaling entity (500) is provided configured to control a control plane signaling of a system (10) which comprises two mobile entities ( 100, 200) in a cellular network. The control plane signaling entity comprises at least one processor (520), and a memory (530), wherein the memory contains instructions executable by the at least one processor. The control plane signaling entity (500) is operative to receive a signaling message from one mobile entity (100) of the system (10), and to determine whether another mobile entity from the same system is already connected to the control plane signaling entity.

If another mobile entity is connected to the control plane signaling entity, the signaling message from said one mobile entity is forwarded to another control plane signaling entity of the same cellular network.

According to a sixth option the control plane signaling entity of option 5 is operative to forward the signaling message, which may be an attach request, to another control plane signaling entity in the same slice of the cellular network.

The terminal based approach reduces the extra complexity needed to handle reliability in the network. Also, by minimizing the impact on the network, the resistance to network failures are maximized since supporting network functions are also subject to failure. In certain cases, such as for PLMN selection, the selection can also be done in the terminal, and the terminal based selection for redundancy can support these cases as well.

The network based approach reduces the impacts on the terminal, hence it is easier to deploy without requiring bigger changes in the very large installed base of the terminals. It may be easier to influence or upgrade for the network operator compared to terminal based selection approach.

Claims

1 . A system (10) comprising:

- a first mobile entity (100) configured to connect to a first network entity (301 ) which is part of a group of first network entities of a cellular network,

- a second mobile entity (200) configured to connect to a second network entity (302) which is part of a group of second network entities of a cellular network,

- at least one memory (130, 230) configured to store

- a first list of first network parameters allowing the first network entities of the first group to which the first mobile entity (100) is configured to connect, to be identified,

- a second list of second network parameters allowing the second network entities of the second group to which the second mobile entity (200) is configured to connect, to be identified, wherein the group of first network entities and the group of second network entities do not have a single network entity in common,

- at least one processor (120, 220), the memory containing instructions executable by said at least one processor, wherein the first mobile entity (100) is operative to connect only to one of the first network entities determined by the first network parameters, and the second mobile entity (200) is operative to connect only to one of the second network entities determined by the second network parameters.

2. The system (10) according to claim 1 , wherein the first network entities identified by the first network parameters belong to a first Public Land Mobile Network, PLMN, and the second network entities identified by the second network parameters belong to a second Public Land Mobile Network, PLMN that is different from the first PLMN.

3. The system (10) according to claim 1 , wherein the first network entities identified by the first network parameters and the second network entities identified by the second network parameters belong to different slices of one Public Land Mobile Network, PLMN.

4. The system according to claim 3, wherein each mobile entity is configured to

- provide a unique identification to the PLMN, by which the corresponding mobile entity within the system is uniquely identified,

- receive at least one network slice identifier uniquely identifying the slice within the PLMN,

- select the network slice based on the received at least one network slice identifier.

5. The system (10) according to claim 1 , wherein the first network entities identified by the first network parameters and the second network entities identified by the second network parameters are different network entities in one Public Land Mobile Network, PLMN, which are each responsible for a control plane signaling towards one of the mobile entities in the system.

6. The system (10) according to any of the preceding claims, wherein the first network entities (301 ) determined bv the first network parameters and the second network entities (302) determined by the second network parameters are different network entities which are each responsible for an exchange of user plane data with one of the mobile entities.

7. A system (10) comprising:

- a first mobile entity (100) configured to connect to a first network entity (301 ) of a cellular network,

- a second mobile entity (200) configured to connect to a second network entity (302) of a cellular network,

- at least one memory (130, 230) configured to store

- a first list containing different first selection parameters used by the first mobile entity (100) to select the first network entity (301 ) when connecting to the cellular network, the different first selection parameters having different priority levels,

- a second list containing different second selection parameters used by the second mobile entity (200) to select the second network entity (302) when connecting to the cellular network, the different second selection parameters having different priority levels, wherein the first selection parameter having the highest priority contained in the first list is different from the second selection parameter having the highest priority contained in the second list, at least one processor (120, 220), the memory containing instructions executable by said at least one processor (120), wherein the first mobile entity (100) is operative to

select a first network entity with highest priority using the first selection parameter with the highest priority from the first list, when connecting to the first network entity (301 ) of the cellular network

wherein the second mobile entity (200) is operative to

select a second network entity with highest priority using the second selection parameter with the highest priority from the second list, when connecting to the second network entity (302) of the cellular network, wherein the selected second network entity with the highest priority from the second list is different from the selected first network entity with the highest priority from the first list.

8. The system (10) according to claim 7, wherein the selected first network entity with the highest priority from the first list and the selected second network entity with the highest priority from the second list belong to different Public Land Mobile Networks, PLMNs.

9. The system (10) according to claim 7, wherein the selected first network entity with the highest priority from the first list and the selected second network entity with the highest priority from the second list belong to different slices of one Public Land Mobile Network, PLMN.

10. The system (10) according to any of claims 7 to 9, wherein the selected first network entity with the highest priority from the first list and the selected second network entity with the highest priority from the second list are different network entities which are each responsible for an exchange of user plane data with one of the mobile entities.

1 1. A system (10) comprising:

at least one memory (130, 230) and at least one processor (120, 220), the memory (130, 230) containing instructions executable by said at least one processor (120, 220), wherein the first mobile entity (100) is operative to

-connect to the first network entity (301 ),

the second mobile entity (200) being operative to

- determine to which first network entity (301 ) the first mobile entity (100) is connected,

- select the second network entity (302) taking into account to which first network entity the first mobile entity (100) is connected.

12. The system (10) according to claim 1 1 , wherein the second mobile entity (200) is operative to select the second network entity (302) such that the second mobile entity is connected to a another network entity than the first mobile entity.

13. The system according to claim 1 1 or 12, wherein the at least one memory is configured to store

- a first list containing different first selection parameters used by the first mobile entity (100) to select the first network entity (301 ) when connecting to the cellular network, the different selection parameters having different priority levels,

- a second list containing different second selection parameters used by the second mobile entity (200) to select the second network entity (302) when connecting to the cellular network, the different selection parameters having different priority levels,

wherein the first mobile entity (200) is configured to

- select the second network entity (302) based on second selection parameter having the highest from the second list,

- to indicate a reduction of at least one priority level of the second selection parameters in the second list and used by the second mobile entity such that, when the second mobile entity selects the second network entity with the second selection parameter having the highest priority level, the second network entity (302) is different to the first network entity.

14. The system (10) according to any of claims 1 1 to 13, wherein the second mobile entity (200) is operative to select the second network entity (302) that belongs to a Public Land Mobile Network, PLMN that is different to the PLMN to which the first network entity belongs.

15. The system (10) according to any of claims 1 1 to 14, wherein the second mobile entity (200) is operative to receive an indication with which the second mobile entity (200) is configured to determine to which first network entity (301 ) the first mobile entity (100) is attached.

16. The system (10) according to any of claims 1 1 to 15, wherein the second mobile entity (200) is operative to select a second network entity (302) that belong to a slice of a Public Land Mobile Network, PLMN, wherein the first mobile entity is operative to select the first network entity (301 ) which belongs to a different slice of the same PLMN.

17. The system (10) according to any of claims 1 1 to 15, wherein the first network entity (301 ) and the second network entity (302) are different network entities in one Public Land Mobile Network, PLMN, which are each responsible for a control plane signaling towards one of the mobile entities in the system.

18. The system (10) according to any of claims 1 1 to 17, wherein the second mobile entity (200) is operative to

- determine a network entity identifier identifying the first network entity (301 ) to which the first mobile entity is connected,

- transmit an attach request to a radio access network including the network entity identifier.

19. A method for operating a system including a first mobile entity and a second mobile entity, wherein the first mobile entity (100) connects to a first network entity (301 ) which is part of a group of first network entities of a cellular network, and second mobile entity (200) connects to a second network entity (302) which is part of a group of second network entities of a cellular network, wherein the system comprises at least one memory storing

a first list of first network parameters allowing the first network entities of the first group to which the first mobile entity (100) is configured to connect, to be identified, and a second list of second network parameters allowing the second network entities of the second group to which the second mobile entity (200) is configured to connect, to be identified, wherein the group of first network entities and the group of second network entities do not have a single network entity in common, the method comprising the steps of:

- the first mobile entity connecting only to one of the first network entities determined by the first network parameters,

- the second mobile entity connecting only to one of the second network entities determined by the second network parameters, so that the first mobile entity and the second mobile entity never connect to the same network entity.

20. The method according to claim 19, wherein the first network entities identified by the first network parameters and the second network entities identified by the second network parameters belong to different slices of one Public Land Mobile Network, PLMN, wherein each of the mobile entities provides a unique identification to the PLMN, by which the corresponding mobile entity within the system is uniquely identified, receives at least one network slice identifier uniquely identifying the slice within the PLMN, and selects the network slice based on the received at least one network slice identifier.

21. A method for operating a system including a first mobile entity and a second mobile entity, wherein the first mobile entity (100) connects to a first network entity (301 ) of a cellular network, and second mobile entity (200) connects to a second network entity (302) of a cellular network, wherein the system comprises at least one memory storing a first list containing different first selection parameters used by the first mobile entity (100) to select the first network entity (301 ) when connecting to the cellular network, the different first selection parameters having different priority levels, and storing a second list containing different second selection parameters used by the second mobile entity (200) to select the second network entity (302) when connecting to the cellular network, the different second selection parameters having different priority levels, wherein the first selection parameter having the highest priority contained in the first list is different from the second selection parameter having the highest priority contained in the second list, the method comprising the steps of:

- the first mobile entity selecting a first network entity with highest priority using the first selection parameter with the highest priority from the first list, when connecting to the first network entity (301 ) of the cellular network,

- the second mobile entity selecting a second network entity with highest priority using the second selection parameter with the highest priority from the second list, when connecting to the second network entity (302) of the cellular network, wherein the selected second network entity with the highest priority from the second list is different from the selected first network entity with the highest priority from the first list.

22. A method for operating a system including a first mobile entity and a second mobile entity, wherein the first mobile entity (100) connects to a first network entity (301 ) of a cellular network, and second mobile entity (200) connects to a second network entity (302) of a cellular network, the method comprising the steps of:

- the first mobile entity connecting to the first network entity (301 ),

- the second mobile entity determining to which first network entity (301 ) the first mobile entity (100) is connected, and selecting the second network entity (302) taking into account to which first network entity the first mobile entity (100) is connected.

23. The method according to claim 22, wherein the second mobile entity (200) selects the second network entity (302) such that the second mobile entity is connected to a another network entity than the first mobile entity.

24. The method according to claim 22 or 23, wherein the system comprises at last one memory storing a first list containing different first selection parameters used by the first mobile entity (100) to select the first network entity (301 ) when connecting to the cellular network, the different selection parameters having different priority levels, and storing a second list containing different second selection parameters used by the second mobile entity (200) to select the second network entity (302) when connecting to the cellular network, the different selection parameters having different priority levels, the method comprising the steps of:

- the first mobile entity (200)

- selecting the first network entity (302) based on first selection parameter having the highest from the first list,

- initiate a reduction of at least one priority level of the second selection parameters in the second list and used by the second mobile entity such that, when the second mobile entity (200) selects the second network entity with the second selection parameter having the highest priority level, the second network entity (302) is different to the first network entity.

25. The method according to any of claims 22 to 24, wherein the second mobile entity (200) selects the second network entity (302) that belongs to a Public Land Mobile Network, PLMN that is different to the PLMN to which the first network entity belongs.

26. The method according to any of claims 22 to 25, wherein the second mobile entity (200) receives an indication with which the second mobile entity (200) determines to which first network entity (301 ) the first mobile entity (100) is attached.

27. The method according to any of claims 22 to 26, wherein the second mobile entity (200) selects a second network entity (302) that belong to a slice of a Public Land Mobile Network, PLMN, wherein the first mobile entity selects the first network entity (301 ) which belongs to a different slice of the same PLMN.

28. The method according to any of claims 22 to 27, wherein the second mobile entity (200) determines a network entity identifier identifying the first network entity (301 ) to which the first mobile entity is connected, and transmits an attach request to a radio access network of the cellular network including the network entity identifier.

29. A computer program comprising program code to be executed by at least one processing unit (120, 220) of a system, wherein execution of the program code causes the at least one processing unit to execute a method according to any of claims 19 to 28.

30. A carrier comprising the computer program of claim 29, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.