Technical Field
[0001] This disclosure relates to a dedicated core networks (DCN) selection.
Background Art
[0002] 3GPP networks are beginning to support devices and customers with very different
[0003]
characteristics, such as device for Machine Type Communication (MTC), Internet of
Things (loT), data usage, etc. These classes of devices and customers may have
different requirements from the core network in terms of optional feature support,
traffic characteristic support, availability, congestion management, ratio of signalling
to user plane traffic, etc. As we move forward, the classes of devices/customers will
continue to increase.
2
wo 2017/061111 PCT/JP2016/0044 77
[0004]
[Table 1]
Abbreviations
DCN Dedicated Core Network
EM Element Manager
eNB evolved Node B
E-UTRAN Evolved Universal Terrestrial Radio Access Network
GPRS General Packet Radio Service
HSS Home Subscriber Server
loT Internet of Things
MME Mobility Management Entity
MMEGI MME Global Identity
MTC Machine Type Communication
NAS Non Access Stratum
NM Network Manager
NNSF NAS Node Selection Function
NRI Network Resource Identifier
OAM Operations, Administration and Management
PCRF Policy and Charging Rules Function
PGW Packet Data Network Gateway
RAU Routing Area Update
RNC Radio Network Controller
SDT Small Data Transmission
SGSN Serving GPRS Support Node
SGW Serving Gateway
TAU Tracking Area Update
UE User Equipment
UTRAN UMTS Terrestrial Radio Access Network
One cost effective mechanism for operators to support these different classes of
devices and customers is to create separate dedicated core networks consisting of specialized
core network elements that are designed and deployed to meet the requirements
of these different devices and customers. It is cost-effective as the network
availability or redundancy requirements may be easier met with different hardware
and/or software than the existing core network. Also, creating separate core networks
enables independent scaling or specific feature provisioning for specific user or traffic
types and isolating specific users and traffic from each other.
[0005] 3GPP started work on standardisation of Dedicated Core Networks in Rel-13
3
wo 2017/061111 PCT/JP2016/0044 77
[0006]
(TR23.707) and agreed a network solution with no UE impact, see TS23.401, s4.3.2.5.
This Rel-13 feature enables an operator to deploy multiple DCNs (Dedicated Core
Networks) within a PLMN with each DCN consisting of one or multiple core network
nodes. Each DCN may be dedicated to serve specific type(s) of subscriber or devices.
This is an optional feature and enables DCN s to be deployed for one or multiple RATs
(GERAN, UTRAN andE-UTRAN).
When DCNs are supported (deployed), at initial access to the network, if sufficient
information is not available for RAN to select a specific DCN, the RAN may selects a
core network node from the default CN. A redirection to a DCN may then be required.
[0007] To redirect a mobile terminal from a default CN to a dedicated CN, the redirection
[0008]
procedure via RAN, described in clause 5.19.1 ofTS23.401, is used to forward the
NAS message from the UE to the target DCN. All selection functions are aware of
DCN(s), including the network node selection function (NNSF) of RAN nodes, for
selecting and maintaining the appropriate DCN for the UEs
Summary of Invention
Technical Problem
The Rel-13 DCN selection solution was not allowed to impact the UE so that it
supports Rel-13 and earlier release mobile terminals. For this reason it has a main disadvantage
- at initial access to the network a sufficient information is not available for
RAN so that it can select the right dedicated DCN at the very beginning instead of
selecting first a default EPC Node (e.g. MME or SGSN) and then rerouting the mobile
terminal to the right DCN. This creates extra signalling and delay.
[0009] In Rel-14 the 3GPP has started a Work Item (S2-152661) on enhanced DCN with the
[0010]
[0011]
following objectives:
- Improve DCN selection mechanism by providing assistance information from the
UE.
This assistance information complements the Rel-13 DECOR mechanism. This can
reduce the signalling required to register to and maintain a DCN. It can also improve
isolation between dedicated core networks since there is no need for redirecting
between different DCN s. The updated selection mechanism impacts the UE and RAN
but the provisioning of the assistance information may impact the core network. It is
advantageous if the solution works when the UE changes PLMNs.
It is however unclear how the RAN takes a decision for routing of the UE's message
towards the core network.
[0012] With this new ongoing work the problem which this invention is trying to solve is
how to enable the RAN Node (e.g. eNB or RNC or CloT RAN) to take a decision
about the routing of the UE' s message (e.g. NAS message) towards the correct
4
wo 2017/061111 PCT/JP2016/0044 77
[0013]
(dedicated) core network.
Solution to Problem
In one aspect, the invention provides a radio access network node comprising: a
receiver configured to receive from a core network node connected to the radio access
network node a message for configuring with a dedicated core network supported by
the core network node.
[0014] In one aspect, the invention provides a communication method for a radio access
[0015]
[0016]
network node, comprising: receiving from a core network node connected to the radio
access network node a message for configuring with a dedicated core network
supported by the core network node.
In one aspect, the invention provides a mobile terminal comprising: a transmitter
configured to transmit to a radio access network node information for indicating a
dedicated core network at registration to a new location in a network included in the
radio access network node.
In one aspect, the invention provides a communication method for a mobile terminal
comprising: transmitting to a radio access network node information for indicating a
dedicated core network at registration to a new location in a network included in the
radio access network node.
[0017] In one aspect, the invention provides a communication method for a communication
system, comprising: receiving, by a radio access network, from a core network node
connected to the radio access network node a message for configuring with a dedicated
core network supported by the core network node; transmitting from a mobile terminal
to the radio access network node information for indicating a dedicated core network at
registration to a new location in a network included in the radio access network node;
and selecting, by the radio access network node, the core network node based on the
information for indicating the dedicated core network received from the mobile
terminal.
Brief Description of Drawings
[0018] [fig.1]Figure 1 illustrates a RAN Node configuration with the dedication type of the
CNnode.
[fig.2]Figure 2 illustrates a list of supported DCN Types of the RAN Node within the
MME Configuration Update message.
[fig.3]Figure 3 illustrates the DCN Type list configuration in the RAN Node.
[fig.4]Figure 4 illustrates one of the System Information messages/blocks a list of all
supported DCN Types in that RAN Node.
[fig.5]Figure 5 illustrates the DCN Type which can also be passed further, from RAN
Node to the EPC Node within Initial UE Message or any other NAS message.
5
wo 2017/061111 PCT/JP2016/0044 77
[0019]
[fig.6]Figure 6 illustrates that the RAN may forward the UE's UE Usage Type indication
to the EPC Node within the Sl-AP's Initial UE message.
[fig.7]Figure 7 illustrates one practical exemplary of how to select the right DCN.
[fig.8]Figure 8 illustrates a scenario where the network does not support a DCN from
the same type that the UE has indicated to RAN Node during the RRC connection establishment.
[fig.9]Figure 9 illustrates an exemplary architecture for the configuration of network
nodes.
Description of Embodiments
Solution Alternative 1.
The following solution in Figure 1 is proposed to assist a Dedicated Core Network
(DCN) selection by the mobile terminals based on the Dedicated Core Network type
provided by the mobile terminals (DCN type, CloT type, UE Usage Type or any other
type of identity for a dedicated type of core network).
[0020] Step 1) RAN Node configuration with the dedication type of the CN Node - Provide
RAN Nodes (eNB or RNC or CloT RAN Node) with the DCN (Dedicated Core
Network) Type(s) of the EPC Nodes (MME or SGSN or CloT EPC Node) that RAN
Node is connected to. The DCN Type of the EPC Node (MME/SGSN/CioT EPC), i.e.
the type of users, services or devices the EPC Node is specialised or dedicated for,
could be identified with the same types that already were agreed by the 3GPP for identification
of the UE subscription type in the HSS, i.e. 'UE Usage Type' (see TS23.401)
or alternatively with MMEGI or NUL-NRIISGSN Group Id that in 3GPP Rel-13 were
agreed to identify a dedicated MME Pools or SGSN Pools. The MME' s DCN Type
could also be identified with so called 'MME Usage Type' (which would be the UE
Usage Type per MME) that would allow compatibility with the already existing 'UE
Usage Type' .. The DCN Types of the EPC Nodes (e.g. MMEs) may be configured via
OAM or locally based on operator's configuration and policy.
[0021] The EPC Node indicates to the connected RAN Nodes the types of the users or
[0022]
mobile terminals (UEs) it is specialised to serve (DCN Type list) so that the RAN
Node can select the right dedicated network when a UE connects to the RAN Node.
As mentioned above, one alternative would be when the UEs and EPC Nodes use the
"UE Usage Type" as indication for DCN Type, but other indications can be used, as
well. Another alternative is the MME's indication to the RAN node for DCN Type is
different from the UE' s indication to the RAN node. In this case, the RAN node needs
to have internal mapping mechanism to map the DCN Type from the UE to the correct
dedicated EPC Node. One example of the latter alternative is where the UE indicates in
the DCN Type "delay tolerant", for example whereas the EPC Node (e.g. MME)
6
wo 2017/061111 PCT/JP2016/0044 77
indicates "M2M" DCN Type. The mapping between the UE's indication and the EPC
Node's indication in the RAN node can be done via configuration over the OAM
system, for example or via an internal logic in the RAN node.
[0023] In addition, DCN may have an associated DCN Profile and the DCN Profile can be
also sent to RAN Node together with DCN Type. The DCN Profile may contain parameters
that defines DCN characteristic that are specialized to serve predefined
service(s). The DCN Type can be considered as a network slicing mechanism, thus an
associated DCN Profile may define the network slice characteristics
[0024] The DCN Type list (e.g. 'UE Usage Type' list or MMEGI/SGSN Group ID list) can
be provided by the EPC Node to the RAN Node with the following messages:
[0025] Step lA) MME Configuration Update message. During the MME configuration the
MMEs provide a list of supported DCN Types to the RAN Node within the MME
Configuration Update message (TS36.413, s8.7.5), see Figure 2. This allows the RAN
Nodes to be configured with information about the UE's DCN Type (e.g. 'UE Usage
Type' or designated MMEGI) served by the MMEs that the RAN Node is connected to
so that the RAN Node uses this information to select the right MME when the UE
connects for service. If parameters other than 'UE Usage Type' are used for DCN
Type, a mapping between the DCN Type indication and the UE subscription type may
be required. This mapping needs to be configured in the RAN node.
[0026] Step lB) Sl Setup Response message (TS36.413, s9.1.8.5). During the Sl Setup
procedure the EPC Node (e.g. MME) may provide or update the DCN Type list (e.g.
'UE Usage Type' list or MMEGI list) configuration in the RAN Node, see Figure 3.
This would allow not just for the DCN Type configuration in the RAN Node but for a
dynamic configuration update of the DCN Type list in the RAN Node based on
operator's policy or operator's configuration.
[0027] Step lC)- any other signalling exchange between the EPC Node (MME or SGSN or
[0028]
CloT EPC Node or any other name for the dedicated network node) could be used to
configure the RAN Node with the specialisation type of the dedicated EPC Nodes.
In yet another aspect applicable to any of the options lA), lB) or lC) from above, it
is possible that the RAN node may indicate to the EPC node whether the RAN node
supports the feature of EPC node (e.g. MME) selection function based the DCN Type
list from the EPC node. This kind of capability indication from the RAN node may be
used by the EPC Node to make a decision whether DCN Type list needs to be set in the
signalling from the EPC node to the RAN node. Especially in cases where the DCN
type list announced from the EPC node may change frequently and the EPC nodes
needs to update the RAN nodes in a frequent manner, so that updating only the
supporting RAN nodes instead of all RAN nodes may be beneficial.
[0029] Once the RAN Node obtains the DCN Types from the associated EPC Nodes (e.g.
7
wo 2017/061111 PCT/JP2016/0044 77
[0030]
MMEs) as shown in Figure 2 and Figure 3, the RAN Node may utilize DCN Type and
associated DCN Profile to perform RAN slicing per service(s). If RAN Node receives
the same DCN Type from multiple EPC Nodes, then RAN Node shall consider all
DCN Profiles associated to the same DCN Type from different EPC Nodes as one aggregated
network slice spanned to multiple EPC Nodes.
In one aspect, when the RAN Node obtains the DCN Types from the associated EPC
Nodes (e.g. MMEs) as shown in Figure 2 and Figure 3, the RAN Node may broadcast
in one of the System Information messages/blocks (over BCCH channeL for example)
a list of all supported DCN Types (e.g. DCN Type list) in that RAN Node, see Figure
4. This would allow the UEs to obtain an information about the supported DCN Types
by the RAN Node and the UEs would attempt to connect only, if the DCN Type they
are subscribed to, is supported. This would allow for an efficient DCN Access control
by restricting the access to a specific DCN(s) when it is not supported in that RAN
Node or temporary not available (overloaded or failure) or any other reason based on
operators' policy and configuration. Thus, the extra signalling from access failures
could be avoided and UE battery power saved.
[0031] If the RAN Node (based on operator's policy or configuration) is configured to select
a default MME when an MME(s) of specific dedication are not available, then the
RAN Node does not broadcast DCN Types list (i.e. no DCN access restriction).
[0032] In another aspect this can be also done on a per UE basis instead of a general configuration
for all UEs at the RAN node, i.e. the EPC Node (e.g. MME) will provide the
DCN Type list when the UE sends the initial UE message. The EPC node then can
map for inbound roaming users the local (VPLMN) DCN Types to the ones supported
in the HPLMN of said UE. For example, if the meaning of the UE Type is different in
the different networks and the UE Usage Type sent by the UE is considered fixed for
the time being, then at time of the initial attach to the VPLMN. the VPLMN EPC Node
would receive the subscriber profile from the HPLMN EPC node including the DCN
~· The VPLMN EPC node would then chose the appropriate DCN Type for this
UE and send it in the reply message e.g. in SlAP, to the RAN node. This means the
same MME could send different support values to the same RAN node for different
inbound roamers. The meaning of the DCN Type is then on a per UE granularity.
[0033] After receiving the 'DCN Type list' indication from the EPC node, the RAN node
stores the 'DCN Type list' together with the EPC node ID (e.g. MME ID). The RAN
node is able to generate a mapping table of all received DCN Types and the corresponding
MME IDs. This mapping table can be used by the RAN node to select a
direct match or the most appropriate serving node, to which to route the UE' s NAS
message, as there may be multiple serving nodes serving the same DCN type indicated
from the UE.
8
wo 2017/061111 PCT/JP2016/0044 77
[0034] Step 2). DCN Type indication by mobile terminals (e.g. UE. MS. MTC device. CloT
device or any other type of 3GPP compatible terminal). The UE can indicate its DCN
~ ('UE Usage Type' subscription or MMEGI identity for the required dedicated
resource or any other type of subscription indication or user characteristics or targeted
service provider or targeted application which could have been preconfigured in the
UE, SIM or UICC) during the RRC connection establishment procedure. The RAN
node can select the right type of DCN (EPC Node like MME or SGSN or CloT EPC
Node) from the very beginning, i.e. avoiding any possibility for re-routing from a
default EPC Node to a dedicated EPC Node. The DCN Type can be indicated within
the RRC Connection Setup Complete message, see Figure 5 or any other message
within the connection establishment procedure or via NAS message.
[0035] The RAN Node has been configured with a list of DCN Types supported by each
MME it is connected to, see step 1). During RRC Connection establishment the UE
indicates its DCN Type ('UE Usage Type' or the MMEGI of a dedicated resource)
which is used by the RAN Node to select the right MME to connect to. The UE can
optionally indicate its DCN type only during RRC connection establishment for
Mobile Originated (MO) services. If the RAN Node has been configured by the EPC
Nodes with DCN Type different from the DCN Type received from the UE (e.g. in
roaming scenarios where one or both, home and visited PLMNs deploy PLMN specific
values for DCN Type or in non-homogeneous coverage of DCNs), a mapping between
the DCN Type from the UE and the DCN Types from the EPC Nodes, based on
operator's policy or configuration is required.
[0036] Other RRC Connection Establishment messages (e.g. RRC Connection Request) can
also be used for indication the UE's DCN Type from the mobile terminal to the RAN
Node where the behavior of the RAN Node would be similar or same to the case when
the DCN Type indication from the UE is received within the RRC Connection Setup
Complete message.
[0037] If the UE does not indicate any DCN Type to the RAN Node, then the RAN Node
[0038]
behavior would be as specified in TS23.401 for Rel-13- RAN Node would forward the
UE to a default MME if there is no other available information about the UE' s or
user's DCN dedication.
Optionally, if RAN Node is not configured with the DCN Types (e.g. 'UE Usage
Type', or MMEGI or any other way of identification for a dedicated EPC resource) or
the RAN Node cannot decode the DCN Type indicated by the UE, the DCN Type can
also be passed further. from RAN Node to the EPC Node (e.g. MME or SGSN or CloT
EPC Node) within Initial UE Message or any other NAS message. as shown in Figure
5. So the EPC Node can analyse the DCN Type from the UE and map it to the right
dedicated network, based on operator's policy or local configuration.
9
wo 2017/061111 PCT/JP2016/0044 77
[0039] In another aspect (Figure 6) the UE can indicate its DCN Type (e.g. subscribed UE
Usage Type in a container within the above mentioned RRC messages (e.g. RRC
Connection Setup Complete or RRC Connection Request or any other AS or NAS
message), especially when DCN Type is a non-standardised one (e.g. te DCN Type is
the UE Usage Type which has a PLMN specific value, see Figure 6). A 'UE Usage
Type' flag parameter in the above messages would indicate whether the 'UE Usage
Type' in the UE Usage container is standardised or it is PLMN specific (e.g. a simple
flag to indicate via 1/0 or True/False or Standardised/PLMN specific the type of the
'UE Usage Type' element in the UE Usage Type container.
[0040] If the 'UE Usage Type' is globally standardised, the 'UE Usage Type' container
from the UE would be the standardised 'UE Usage Type value itself. '
[0041] If the' UE Usage Type' is PLMN specific (non-standardised), the UE Usage Type
container would contain:
-either the Home PLMN specific values for the 'UE Usage Type' in the UE Usage
Type container which would be analysed by the RAN Node or the EPC node based on
the operators roaming mapping and configuration and policies;
- or the Home PLMN provide the UE (over the air or via terminal/SIM/UICC configuration)
with the 'UE Usage Type' values for the roaming partners so that the UE
can use the visited PLMN's 'UE Usage Type' values in the UE Usage Type container
when roaming.
[0042] Figure 6 further shows that the RAN may forward the UE's UE Usage Type indication
to the EPC Node within the Sl-AP's Initial UE message. The UE Usage Type
indication from the UE can be used by the EPC Node to verify (with the HSS for
example) the validity of the UE subscription. In such a case there is no need for the UE
to indicate the "DCN Type" in the NAS signalling. The RAN node may need to have
internal processing unit in order to decide whether to forward the UE' s indication over
the AS signalling to the Sl-AP signalling over the Sl-MME interface. In one example
the eNB may always forward the UE's AS indication on the Sl-MME interface to the
EPC Node. In another example the eNB may forward the UE's AS indication
depending on the indication value. In yet another example the RAN node can forward
the UE's AS indication depending whether the value of the UE's AS indication is
known to the RAN node (or whether the RAN node is configured with the value) to
map to any of the available DCNs.
[0043] The diagram in Figure 7 demonstrate one practical example of how to select the right
DCN based on the above steps.
[0044] 1-2) EPC Nodes (e.g. MMEs) provide a list of supported DCN Type(s) to the RAN
Node within the MME Configuration Message (TS36.413, s8.7.5) or any other
message on the MME/eNB
10
wo 2017/061111 PCT/JP2016/0044 77
interface. The DCN Type could be represented with the already 3GPP defined 'UE
Usage Type' (i.e. the DCN Type values aligned with the 'UE Usage Type subscription
values' in TS23.401 for Rel-13) or via MMEGI that is designated for a dedicated
MME Pool or any other way of dedicated resource identification. This allows the RAN
Nodes to be configured with information about the DCN Types served by the MMEs
that the RAN Node is connected to so that the RAN Node uses this information to
select the right MME when the UE connects for service. In the above example one of
the MMEs is of 'default' type (a conventional, non-dedicated MME) and another one
is of 'mtc' (Machine Type Communication) and 'ciot' (Cellular Internet of Things)
types (e.g. 'mtc' and 'ciot' UE Usage Type values). It is also possible that default
MMEs do not indicate any DCN Type list (e.g. it is not present or empty), which
would mean that all DCN Types are supported.
[0045] This way the RAN Node is configured with the list of DCN Types supported by each
[0046]
MME the RAN Node is connected to.
3A) When a UE triggers RRC Connection establishment for a MO service the UE
indicates (in the RRC Connection Setup Complete message, for example) its DCN subscription
via DCN Type parameter= 'mtc', for example.
4A) Based on the DCN Type= 'mtc' indication from the UE, the RAN Node selects
a 'mtc' dedicated EPC Node (from the same type as the DCN Type received from the
UE). The RAN Node forwards the NAS message from the UE to the MME with 'mtc'
type dedication along with the DCN Type indication parameter from the UE for subscription
verification with the HSS.
[0047] 3B) When UE triggers RRC Connection establishment for a MO service the UE
indicates (in the RRC Connection Setup Complete message, for example) its DCN subscription
via DCN Type parameter= 'ciot', for example .
4B) Based on the DCN Type= 'ciot' indication from the UE, the RAN Node selects
a 'ciot' dedicated EPC Node (from the same type as the DCN Type received from the
UE). The RAN Node forwards the NAS message from the UE to the MME with 'ciot'
type dedication along with the DCN Type indication parameter from the UE for subscription
verification with the HSS.
[0048] 3C) If a UE triggers RRC Connection establishment for a MO service the UE
indicates (in the RRC Connection Setup Complete message, for example) its DCN subscription
via DCN Type parameter= 'sdt', for example
4C) Based on the DCN Type= 'sdt' (Small Data Transmission) indication from the
UE, the RAN Node attempts to select a 'sdt' dedicated EPC Node (from the same type
as the DCN Type received from the UE). As a dedicated MME from 'sdt' type
dedication is not available, the RAN Node, based on operators configuration or policy,
either
11
wo 2017/061111 PCT/JP2016/0044 77
forwards the NAS message from the UE to the MME with 'default' type dedication
along with the DCN Type indication parameter from the UE. The default MME,
depending on the operator's configuration can serve the UE or reject the NAS message
from the UE with back-off timers included in the reject or alternatively forward the
NAS message from the UE to an MME from different dedication if required by
operator's policy or configuration; or
the RAN Node forwards the NAS message from the UE to another dedicated resource
(MME) again, based on the local configuration or operator policies.
[0049] The diagram in Figure 8 illustrates a scenario where the network does not support a
DCN from the same type that the UE has indicated to RAN Node during the RRC
connection establishment (e.g. in the RRC Connection Setup Complete message or
RRC Connection Request message or any other RRC signalling). i.e. RAN Node is not
associated with a dedicated network from the 'DCN Type' indicated by the UE. In this
case, one possible behaviour (other than forwarding the UE to a default EPC Node) is
that the RAN Node rejects the UE by releasing the already created RRC connection via
RRC Connection Release message returned to the UE along with a new release cause,
e.g.:
- 'DCN not supported' (or any other name with similar meaning) - a DCN of the
DCN type indication by the UE is not supported by this RAN Node.
- 'DCN not available' (or any other name with similar meaning)- the DCN is
temporary not available because of failure or any other reason.
[0050] On receiving the RRC Connection Release message with the release cause:
'DCN not supported - the UE shall not initiate another attempt for RRC connection
to the same DCN while the UE is in the same TA/LA;
'DCN not available' -the UE shall not initiate another attempt for RRC Connection
establishment while the UE is in the same Cell. If an 'extended wait timer' is present in
the RRC Connection Release message, the UE can try another RRC connection establishment
in the same cell when the 'extended wait timer' expires.
[0051] Solution alternative 2:
[0052]
Another possible solution of the described problem is to configure the RAN nodes
(e.g. eNBs) in a proper way to forward the UE's message to the correct DCN. This
configuration can be e.g. done over the OAM system. Alternative 2 is a more static
way of configuration via the OAM. Thus, this solution is applicable to networks whose
DCN configuration does not change frequently.
Figure 9 shows an exemplary architecture how to configure the RAN node and
serving network node, more particular a base station, eNB and MME, using the Operations,
Administration and Management (OAM) system. Usually the RAN node (e.g.
eNB), and the network node (e.g. MME) implements an Element Manager (EM). The
12
wo 2017/061111 PCT/JP2016/0044 77
EM is connected to the network manager (NM) which is part of the OAM system
operated by the network operator.
[0053] In the particular scenario of this invention, the network operator can use the OAM
[0054]
system to configure the RAN nodes (eNBs) with the particular mapping of the UE's
DCN Type indication and the serving node configured to serve the particular DCN Indication.
The OAM system can be also used to configure the serving network node
with the corresponding DCN types. The eNB is able to route the UE's NAS message to
the correct serving network node based on the 'DCN type' indication from the UE.
With other words the configuration of the RAN node to map the 'DCN type' indication
from the UE to the available DCN types of the serving node is similar as the configuration
of the eNB from Alternative 1 above.
The configuration can be done in a kind of table containing e.g.
- UE "DCN type" indication maps to MMEGI(s) or SGSN group ID.
- UE "DCN type" indication maps to MME ID or SGSN ID.
[0055] Having such a configuration, the eNB can take a decision how to select a particular
serving node (MME) to which the UE's NAS message is forwarded.
[0056] Although the proposed solutions in this invention mostly use 4G terminology in the
[0057]
[0058]
description and examples (UE, MME, eNB and etc.) the solutions are equally applicable
to 3G/2G technology (including terminal indicated as MS, and network nodes
SGSN, MSC, RNC, Base Station and etc.) as to any old or new 3GPP compatible
technology, loT networks and terminals and more.

1. MME Configuration Update (DCN Type list)- New parameter DCN Type list in
the MME Configuration Update message that contains the list of the DCN Types (e.g.
UE Usage Types or MMEGI or any other way of identification for a dedicated EPC
resource) supported by the connected MME. This allows the MMEs (connected to a
specific RAN Node) to configure that RAN Node with the DCN Types they are
dedicated to serve.
2. RRC Connection Setup Complete (DCN Type)- New parameter DCN Type in
RRC Connection Setup Complete message (or any other AS or NAS message from the
UE) so that the UE can indicate to the RAN Node its subscription for dedicated
network (e.g. via 'UE Usage Type' or MMEGI or any other way to identify the UE's
dedicated network subscription).
In an alternative implementation two new parameters could be added to the RRC
Connection Setup message- RRC Connection Setup Complete (UE Usa&e Type fla&.
UE Usa&e Type container) to cover roaming between PLMNs where one or both of the
PLMN s uses PLMN specific values for the UE Usage Type. In this case the UE U sa&e
13
wo 2017/061111 PCT/JP2016/0044 77
flag would indicate whether the UE Usage Type value in the UE Usage Type container
from the UE is a standardized one or PLMN specific one.
[0059] 3. Dedicated EPC Node selection by RAN Node (e.g. eNB)- Based on the con-
[0060]
figuration by the MME with the DCN Type list and the DCN Type indication from the
UE, the RAN Node selects the right dedicated EPC Node to service the UE.
4. Initial UE Message (DCN Type)- New parameter in the Initial UE Message so
that the dedicated MME can verify the UE subscription for DCN or alternatively, when
the dedicated core network selection would be made by the EPC Node (e.g. when the
dedicated resource selection information in the RAN Node is still insufficient).
[0061] 5. RRC Connection Release (release cause)- RAN Node can reject the UE when a
dedicated network of the DCN Type indicated by the UE is not available or not
supported. The new values for the release cause - DCN not supported and DCN not
available.
[0062] 6. DCN Type list broadcast in the System Information - RAN Node may broadcast
[0063]
the list of DCNs supported by it- DCN access control by the RAN Node. If a default
MME is present in the MME Loop (service area), the RAN Node may not broadcast
any DCN Type list as it is possible that the default MME is configured (based on the
operator's policy) to serve the UEs for which there is no DCN support.

1. UE NAS Message Reroute is avoided. As the UE provides its subscription for
dedicated network via the DCN parameter and also the RAN Node is configured with
the MME' s DCN Types, the RAN Node can select the right dedicated resource without
having to forward the NAS message from the UE to a default MME
[0064] 2. Improved Load Balancing by the RAN Node. As the RAN Node is provided with
the DCN Types supported by the connected MMEs , the RAN Node can select a
dedicated MME by applying the existing load balancing principles only for MMEs of
the same DCN Type.
[0065] This application is based upon and claims the benefit of priority from EP Patent Application
No. 15189240.3, filed on October 9, 2015, the disclosure of which is Incorporated
herein in its entirety by reference.

Claims
A radio access network node comprising:
a receiver configured to receive from a core network node connected to
the radio access network node a message for configuring with at least
one dedicated core network supported by the core network node.
The radio access network node according to claim 1, wherein
the message includes a list of types of the at least one dedicated core
network, and
the radio access network node further comprising:
a memory storing instructions; and
at least one processor configured to process the instructions to:
select the core network node based on the configuration by the core
network node with the list.
The radio access network node according to claim 1, further
compnsmg:
a further receiver configured to receive from a mobile terminal Information
for indicating a dedicated core network at registration to a
new location in a network included in the radio access network node,
and wherein
the radio access network node further comprising:
a memory storing instructions; and
at least one processor configured to process the instructions to:
select the core network node based on the message and the information
for indicating the dedicated core network received from the mobile
terminal.
The radio access network node according to claim 1, wherein
the receiver receives the message during at least one of configuration of
the core network node and S 1 setup procedure.
The radio access network node according to claim 1, wherein
the receiver is configured to receive from the core network node
connected to the radio access network node the message for configuring
with the at least one dedicated core network supported by the
core network node via O&M.
The radio access network node according to claim 3, wherein
the further receiver is further configured to receive from the mobile
terminal the information for indicating the dedicated core network
included in a Radio Resource Control, RRC, connection complete
wo 2017/061111
[Claim 7]
[Claim 8]
[Claim 9]
[Claim 10]
[Claim 11]
[Claim 12]
[Claim 13]
15
PCT/JP2016/0044 77
message.
A communication method, comprising:
receiving from a core network node connected to a radio access
network node a message for configuring with at least one dedicated
core network supported by the core network node.
The communication method according to claim 7, wherein
the message includes a list of types of the at least one dedicated core
network, and
the method further comprising:
selecting the core network node based on the configuration by the core
network node with the list.
The communication method according to claim 7, further comprising:
receiving from a mobile terminal information for indicating a dedicated
core network at registration to a new location in a network included in
the radio access network node; and
selecting the core network node based on the message and the Information
for indicating the dedicated core network received from the
mobile terminal.
The communication method according to claim 7, wherein
the receiving is performed during at least one of configuration of the
core network node and S 1 setup procedure.
The communication method according to claim 7, further comprising:
receiving from the core network node connected to the radio access
network node the message for configuring with the at least one
dedicated core network supported by the core network node via O&M.
The communication method according to claim 9, further comprising:
receiving from the mobile terminal the information for indicating the
dedicated core network included in a Radio Resource Control, RRC,
connection complete message.
A mobile terminal comprising:
a transmitter configured to transmit to a radio access network node Information
for indicating a dedicated core network at registration to a
new location in a network included in the radio access network node,
and
wherein the information is forwarded to a core network node which is
connected to the radio access network node and which sends to the
radio access network node a message for configuring with the
dedicated core network supported by the core network node.
wo 2017/061111
[Claim 14]
[Claim 15]
[Claim 16]
[Claim 17]
16
PCT/JP2016/0044 77
The mobile terminal according to claim 13, wherein
the transmitter is configured to transmit to the radio access network
node the information for indicating the dedicated core network included
in a Radio Resource Control, RRC, connection complete message.
A communication method for a mobile terminal comprising:
transmitting to a radio access network node information for indicating a
dedicated core network at registration to a new location in a network
included in the radio access network node, and
wherein the information is forwarded to a core network node which is
connected to the radio access network node and which sends to the
radio access network node a message for configuring with the
dedicated core network supported by the core network node.
The communication method according to claim 15, further comprising:
transmitting to the radio access network node the information for indicating
the dedicated core network included in a Radio Resource
Control, RRC, connection complete message.
A communication method for a communication system, comprising:
receiving, by a radio access network, from a core network node
connected to the radio access network node a message for configuring
with a dedicated core network supported by the core network node;
transmitting from a mobile terminal to the radio access network node
information for indicating a dedicated core network at registration to a
new location in a network included in the radio access network node;
and
selecting, by the radio access network node, the core network node
based on the information for indicating the dedicated core network
received from the mobile terminal.