WO2019153300A1

WO2019153300A1 - Method and devices for communicating with a core network

Info

Publication number: WO2019153300A1
Application number: PCT/CN2018/076292
Authority: WO
Inventors: Weixing Wang; Jing He
Original assignee: Nokia Shanghai Bell Co., Ltd.; Nokia Solutions And Networks Oy
Priority date: 2018-02-11
Filing date: 2018-02-11
Publication date: 2019-08-15

Abstract

Embodiments of the present disclosure relate to methods, devices, and computer readable medium for communication. A method in a network device comprises: receiving a message from a terminal device; identifying capability of the terminal device for supporting an enhanced communication feature based on the received message; determining a core network node for the terminal device based on the identified capability of the terminal device; and sending at least a portion of the message to the determined core network node. Embodiments of the present disclosure may improve selection of a core network node for the terminal device, and improve quality of service for terminal devices.

Description

METHOD AND DEVICES FOR COMMUNICATING WITH A CORE NETWORK

FIELD

Non-limiting and example embodiments of the present disclosure generally relate to a technical field of wireless communication, and specifically to methods and devices for communicating with a core network.

BACKGROUND

This section introduces aspects that may facilitate better understanding of the disclosure. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

Currently a new fifth generation (5G) wireless communication technique is being studied in the third generation partnership project (3GPP) . An access technology called New Radio (NR) is to be adopted in 5G communication systems.

Considering reduction in capital expenditure (CAPEX) and the fact that user equipment (UE) with 5G capability may not take a dominant position in a 5G network in an initial phase of the 5G network deployment, a non-standalone NR architecture may be adopted as an interim solution. In the non-standalone NR architecture, UE may connect with a core network (CN) via a legacy evolved UMTS Terrestrial Radio Access (E-UTRA) access network and an NR access network using an (E-UTRA) -NR Dual Connectivity (EN-DC) technique.

Furthermore, during the 5G network deployment, a Mobile Network Operator (MNO) may upgrade core network nodes step by step to support new features introduced by the 5G network. As a result, core network nodes with different capabilities may coexist in the network.

How to support a network including UEs and networks nodes with different capabilities in an efficient way is still an open question.

SUMMARY

Various embodiments of the present disclosure mainly aim at improving communication of a terminal device with a core network.

In a first aspect of the disclosure, there is provided a method implemented at a network device for providing a communication service to a terminal device. The network device receives a message from the terminal device, identifies capability of the terminal device for supporting an enhanced communication feature based on the message, determines a core network node for the terminal device based on the identified capability of the terminal device, and sends at least a portion of the message to the determined core network node.

In an embodiment, the network device may identify the terminal device as being capable of supporting the enhanced communication feature in response to detecting Access Stratum information from the message indicating that the terminal device is capable of supporting the enhanced communication feature, .

In some embodiments, the message may be received during a radio resource control (RRC) connection set up procedure of the terminal device. In some embodiments, the message may be an RRCConnectionSetupComplete message. In another embodiment, the at least a portion of the message may include an Attach Request or a Track Area Update (TAU) Request included in the message. In still another embodiment, the core network node may be a mobility management entity (MME) .

In a second aspect of the disclosure, there is provided a method in a terminal device for communication. The method comprises generating a message by including an indication on capability of the terminal device for supporting an enhanced communication feature as an Access Stratum (AS) signaling, and transmitting the message to a network device.

In a third aspect of the disclosure, there is provided a method in a network device for providing a communication service to a terminal device. The method comprises receiving a first message from the terminal device; in response to receiving the first message, determining a core network node for the terminal device from a set of core network nodes, based on a predefined selection rule which assigns a higher selection priority to core network nodes capable of supporting an enhanced communication feature and a lower selection priority to core network nodes incapable of supporting the enhanced communication feature; and sending at least a portion of the first message to the determined core network node.

In some embodiments, the method further comprises receiving from the determined core network node a reroute request message including at least one of an indication on the capability of the terminal device for supporting the enhanced communication feature, and an identifier for a further core network node; selecting a further core network node based on the at least one of the indication and the identifier; and transmitting the at least a portion of the first message to the further core network node.

In a fourth aspect of the disclosure, there is provided a method in a core network node for providing a communication service to a terminal device. The method comprises receiving a first message from a network device, the first message including a Non-Access Stratum, NAS, request from the terminal device; identifying capability of the terminal device for supporting an enhanced communication feature based on the received first message; in response to identifying that the terminal device is incapable of supporting the enhanced communication feature, determining whether to reroute the terminal device to a further core network node based on a local policy; and in response to determining to reroute the terminal device to a further core network node, transmitting a second message to the network device, the second message including at least one of: an indication on the capability of the terminal device for supporting the enhanced communication feature and an identifier for the further core network node.

In a fifth aspect of the disclosure, there is provided a method in a core network node for providing a communication service to a terminal device. The method comprises receiving a message from a network device, the message including a Non-Access Stratum, NAS, request from the terminal device and additional information preventing the core network node from rerouting the NAS request; and accepting the NAS request in response to the received message.

In a sixth aspect of the disclosure, there is provided a method in a core network for providing a communication service to a terminal device. The core network node supports an enhanced communication feature, and the method comprises: receiving a message from a network device, the message including a Non-Access Stratum, NAS, request from the terminal device; identifying capability of the terminal device for supporting the enhanced communication feature based on the received message; and in response to identifying that the terminal device is capable of supporting the enhanced communication feature, informing the terminal device via the network device that the enhanced communication feature is supported by the core network.

In a seventh aspect of the disclosure, there is provided a method in a terminal device supporting an enhanced communication feature. The method comprises: transmitting a first message to a network device, the first message including a Non-Access Stratum (NAS) request to a core network; receiving a second message in response to the first message from a core network node via the network device; determining whether the enhanced communication feature is supported by the core network based on the second message; and in response to determining that the enhanced communication feature is supported by the core network, completing a procedure related to the NAS request.

In some embodiments, in response to determining that the enhanced communication feature is not supported by the core network, the terminal device initiates a further procedure related to the NAS request by transmitting a third message to the network device. The third message includes the NAS request to the core network.

In an eighth aspect of the disclosure, there is provided a network device. The network device comprises a processor and a memory, wherein the memory contains instructions executable by said processor whereby the network device is operative to perform a method according to the first aspect or third aspect of the present disclosure.

In a ninth aspect of the disclosure, there is provided a terminal device. The terminal device comprises a processor and a memory, wherein the memory contains instructions executable by said processor whereby the terminal device is operative to perform a method according to the second aspect or seventh aspect of the present disclosure.

In a tenth aspect of the disclosure, there is provided a core network device. The core network device comprises a processor and a memory, wherein the memory contains instructions executable by said processor whereby the core network device is operative to perform a method according to the fourth, fifth or sixth aspect of the present disclosure.

In an eleventh aspect of the disclosure, there is provided a computer readable medium with a computer program stored thereon which, when executed by at least one processor of a device, causes the device to carry out the method of any of the first to seventh aspect of the present disclosure.

Embodiments of the present disclosure enables to select a proper core network node for a terminal device based on capability of the terminal device and/or other factors, thereby an advanced terminal device may benefit from enhanced communication features.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other aspects, features, and benefits of various embodiments of the present disclosure will become more fully apparent from the following detailed description with reference to the accompanying drawings, in which like reference signs are used to designate like or equivalent elements. The drawings are illustrated for facilitating better understanding of the embodiments of the disclosure and are not necessarily drawn to scale, in which:

FIG. 1 illustrates an example communication network in which embodiments of the present disclosure may be implemented;

FIG. 2 shows a flow chart of a method in a network device for providing communication service to a terminal device according to an embodiment of the present disclosure;

FIG. 3 shows an Attach/Track Area Update (TAU) procedure according to an embodiment of the present disclosure;

FIG. 4 shows a flow chart of a method in a terminal device for communication according to an embodiment of the present disclosure;

FIG. 5 show another Attach/TAU procedure according to an embodiment of the present disclosure;

FIG. 6 shows a flow chart of another method in a network device according to an embodiment of the present disclosure;

FIG. 7 shows a flow chart of a method in a core network device capable of an enhanced communication feature according to an embodiment of the present disclosure;

FIG. 8 shows a flow chart of a method in another core network device according to an embodiment of the present disclosure;

FIG. 9 shows a further Attach/TAU procedure according to an embodiment of the present disclosure;

FIG. 10 show a flow chart of a method in a further core network node for providing a communication service to a terminal device according to an embodiment of the present disclosure;

FIG. 11 shows a flow chart of a method in another terminal device for communication according to another embodiment of the present disclosure; and

FIG. 12 illustrates a simplified block diagram of an apparatus that may be embodied as or comprised in a terminal device, a network device, or a core network node according to embodiments of the present disclosure.

DETAILED DESCRIPTION

Hereinafter, the principle and spirit of the present disclosure will be described with reference to illustrative embodiments. It should be understood that all these embodiments are given merely for one skilled in the art to better understand and further practice the present disclosure, but not for limiting the scope of the present disclosure. For example, features illustrated or described as part of one embodiment may be used with another embodiment to yield still a further embodiment. In the interest of clarity, not all features of an actual implementation are described in this specification.

References in the specification to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It shall be understood that although the terms “first” and “second” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and/or” includes any and all combinations of one or more of the listed terms.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be liming of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and/or “including” , when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

As used herein, the term “wireless communication network” refers to a network following any suitable wireless communication standards, such as New Radio (NR) , Long Term Evolution (LTE) , LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , and so on. The “wireless communication network” may also be referred to as a “wireless communication system. ” Furthermore, communications between network devices, between a network device and a terminal device, or between terminal devices in the wireless communication network may be performed according to any suitable communication protocol, including, but not limited to, Global System for Mobile Communications (GSM) , Universal Mobile Telecommunications System (UMTS) , LTE, NR, wireless local area network (WLAN) standards, such as the IEEE 802.11 standards, and/or any other appropriate wireless communication standard either currently known or to be developed in the future.

As used herein, the term “network device” refers to a device in a wireless communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a base station (BS) or an access point (AP) , for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , a gNB, a Remote Radio Unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, a low power node such as a femto NB, a pico NB, and so forth, depending on the applied terminology and technology.

The term “terminal device” refers to any end device capable of accessing a wireless communication network and receiving services therefrom. By way of example and not limitation, a terminal device may be referred to as UE, a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) . The terminal device may include, but is not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, wearable terminal devices, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment (CPE) and the like. In the following description, the terms “terminal device” , “terminal” , “user equipment” and “UE” may be used interchangeably.

As one example, a terminal device may represent a UE configured for communication in accordance with one or more communication standards promulgated by the 3GPP, such as 3GPP’s GSM, UMTS, LTE, and/or 5G standards. As used herein, a “user equipment” or “UE” may not necessarily have a “user” in the sense of a human user who owns and/or operates the relevant device. In some embodiments, a terminal device may be configured to transmit and/or receive information without direct human interaction. For instance, a terminal device may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the wireless communication network. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but that may not initially be associated with a specific human user.

The terminal device may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, and may in this case be referred to as a D2D communication device.

As yet another example, in an Internet of Things (IOT) scenario, a terminal device may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another terminal device and/or network equipment. The terminal device may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as a machine-type communication (MTC) device. As one particular example, the terminal device may be a UE implementing the 3GPP narrow band internet of things (NB-IoT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances, for example refrigerators, televisions, personal wearable devices such as watches etc. In other scenarios, a terminal device may represent a vehicle or other equipment capable of monitoring and/or reporting on its operational status or other functions associated with its operation.

FIG. 1 illustrates an example communication network 100 in which embodiments of the present disclosure may be implemented. As shown, the communication network 100 includes an access network 110 and a core network (CN) 120. The access network 110 includes one or more network devices, for example BSs 111 and 112, which may communicate with each other via, for example, an X2 interface. Note that

BSs

111 and 112 may be in different forms or support different access techniques. For instance, BS 111 may be in a form of an NB or an eNB, while the BS 112 may be in a form of an NR gNB. The one or more network devices provide service to a set of UEs 102-1 and 102-2, which may be collectively referred to as “UE (s) 102” . Though only two UEs are shown in FIG. 1 for simplicity, it should be appreciated that more or less UEs may be included in the communication network in practice.

As shown in FIG. 1, the core network 120 may include one or more core network nodes, for example Mobility Management Entity (ies) (MMEs) 121-124 which may communicate with a BS (for example BS 111) via a S1-MME interface. Note that the core network 120 may include further CN nodes, such as one or more gateway (GW) and/or Home Subscriber Server (HSS) , not shown in FIG. 1.

In the communication network 100, a non-standalone NR solution may be adopted, especially in an initial phase of 5G network deployment. That is to say, an NR (i.e., 5G) access network may connect to the core network (e.g., Evolved Packet Core (EPC) ) via EN-DC or NR option 3/3a/3x as specified in 3GPP standard TS 37.340 V15.0.0 (2017-12) .

Furthermore, in the communication network 100, one or more EPC nodes (for example MMEs 121-124) may be upgraded to support some enhanced feature, for example, EPC enhanced features to support dual connectivity with NR which are specified in 3GPP TS 23.401 V15.2.0 (2017-12) . For illustration rather than limitation, the enhanced features may include secondary Radio Access Technique (RAT) usage data reporting as specified in sub clause 5.7A of TS 23.401. The enhanced features may include a communication feature for supporting EN-DC technique, in some embodiments.

Note that a network operator may upgrade only part of the EPC nodes (e.g. virtualized MME 123-124) to support the non-standalone NR deployment, which leads to a mixed MME pool deployment in which MMEs with different capabilities coexist in an MME pool 130, as illustrated in FIG. 1. In this case, the network operator may expect that EN-DC capable UEs be attached to an upgraded MME while legacy LTE UEs be attached to an upgraded MME or a non-upgraded MME.

To enable MME selection, the following two enhanced MME selection mechanisms may be considered; however, drawbacks in both mechanisms have been identified.

In order to support EN-DC related features, the core network requires EN-DC capable UE to indicate its capability in a Non-Access Stratum (NAS) indicator to the CN as specified in clause 5.11.3 of TS 23.401 which is reproduced below.

5.11.3 UE Core Network Capability

If the UE supports dual connectivity with NR (see clause 4.3.2a) , then the UE shall indicate its support in a NAS indicator

This NAS indicator is specified via a new UE Network Capability bit defined in clause 9.9.3.34 of TS 24.301 which is reproduced below.

9.9.3.34 UE network capability

Table 9.9.3.34.1: UE network capability information element

Inventors of the present disclosure have observed that since the NAS message carrying UE capability indicator is transparent to the radio access network (RAN) node (i.e., the eNB) , the eNB is unaware of UE’s EN-DC capability when UE initiates an Attach or track area update (TAU) procedure in evolved packet system (EPS) . That is, eNB is unable to acquire UE’s EN-DC capability during RRC Connection establishment phase, and cannot select an MME for the UE based on this capability. Instead, eNB can only be informed of the EN-DC capability of the UE by the selected MME according to clause 18 of TS 36.300.

That is to say, with the existing MME selection mechanism, when forwarding the first NAS message from UE to an MME, the eNB is unaware of the UE capability indicated by the capability indicator in the NAS message. Therefore, in this case, eNB cannot select an appropriate MME from a mixed MME pool, even if eNB supports UE capability based network node selection function (NNSF) mechanism for MME selection. On the other hand, if NNSF is executed randomly without considering UE capability, a legacy MME may be selected for a 5G capable UE, and as a result, the 5G capable UE cannot be served by the EPC with enhanced functions.

Another MME selection mechanism is Dedicated Core Network (DCN) selection based on user’s subscription data, instead of UE capability. However, when deploying a non-standalone NR solution, a mobile network operator may decide to offer 5G access service to LTE subscribers without considering whether there is a “subscription” agreement. That is, provision of 5G access may only depend on EN-DC capability of the UE. In this case, the DCN selection based on user’s subscription data cannot apply any more. In addition, the DCN selection mechanism imposes an impact on all users’subscription data, which is undesirable.

In present disclosure, methods and apparatuses have been proposed to enable efficient core network node selection without significant impact on legacy MME and UEs. Though embodiments of the present disclosure may be used for MME selection based on EN-DC capability of UEs, it should be appreciated that embodiments of the present disclosure are not limited to such a specific communication scenario, but could be applied to any communication scenario where similar problem exists.

Generally speaking, in some embodiments of the present disclosure, a mechanism for EPS enhancement is proposed, in order to support, for example, a non-standalone NR/5G solution. The proposed mechanism, including methods and apparatuses, may be applied for selecting a core network node from a mixed pool of core network nodes with different capabilities. The core network nodes may include, but is not limited to, CN entry network nodes such as MME, or Access and Mobility Management Function (AMF) . For instance, the mixed pool of core network nodes may include combo MME&AMF node (s) (a combined entity with collocated MME and AMF functions) and legacy MME nodes.

FIG. 2 shows a flow chart of a method 200 for providing a communication service to a terminal device. The method may be implemented by, for example, the eNB 111 shown in FIG. 1. For ease of discussion, the method 200 will be described below with reference to eNB 111 and the communication network 100 illustrated in FIG. 1. However, embodiments of the present disclosure are not limited thereto.

As shown in FIG. 2, at block 210, eNB 111 receives a message from a terminal device, for example terminal device 102 in FIG. 1, and identifies capability of the terminal device 102 for supporting an enhanced communication feature based on the message at block 220. The enhanced communication feature may include, but is not limited to, EN-DC.

Alternatively or in addition, in some embodiments, the message received by the eNB 111 at block 210 may be sent by the terminal device 102 during an RRC connection set up procedure. It should be appreciated that embodiments are not limited to any specific name or format for the message. Just for illustration purpose, in some embodiments, the message may be an RRCConnectionSetupComplete message, transmitted by the terminal device 102 during an Attach or Track Area Update (TAU) procedure.

If the terminal device 102 is capable of the enhanced communication feature, it may include its capability information in the message, for example, as an Access Stratum (AS) signaling, such that eNB 111 is able to identify capability of the terminal device 102 by detecting the AS signaling included in the received message. Correspondingly, in some embodiment, at block 220, eNB 111 may identify the terminal device 102 as being capable of supporting the enhanced communication feature, in response to detecting from the message AS information indicating that the terminal device is capable of supporting the enhanced communication feature.

Alternatively, in some embodiments, at block 220, eNB 111 may identify the terminal device 102 as being incapable of supporting the enhanced communication feature, if it fails in detecting an indication of the capability of the terminal device from the message.

At block 230, eNB 111 determines/selects a core network node for the terminal device 102 based on the identified capability of the terminal device 102. The core network node may be, but is not limited to, an MME.

For instance, at block 230, the eNB 111 may determine a core network node for the terminal device randomly from a set of core network nodes (e.g., MME pool 130 in FIG. 1) if the terminal device 102 is identified as being incapable of supporting the enhanced communication feature at block 220. Alternatively, in some embodiments, if the terminal device 102 is identified as being incapable of supporting the enhanced communication feature at block 220, the eNB 111 may determine for the terminal device a core network node (e.g., MME 121 in FIG. 1) incapable of supporting the enhanced communication feature from the set of core network nodes or determine for the terminal device a core network node (e.g., MME 123 in FIG. 1) capable of supporting the enhanced communication feature from the set of core network nodes at block 230.

In some embodiments, at block 230, in response to identifying the terminal device as being capable of supporting the enhanced communication feature at block 220, eNB 111 may determine a core network node (e.g., MME 123 in FIG. 1) capable of supporting the enhanced communication feature from the set of core network nodes for the terminal device.

At block 240, eNB 111 sends at least a portion of the message received at block 210 to the determined core network node. The at least a portion of the message may be, but is not limited to, an Attach Request or a TAU Request included in the message.

Method 200 enables the network device (for example eNB 111) , to select a core network node for a terminal device (e.g., UE 102) based on capability of the terminal device. In this way, a terminal device supporting enhanced communication features may be served by an upgraded core network node and obtain better quality of service.

Method 200 requires a terminal device capable of the enhanced communication feature to indicate its capability to the eNB. Such a solution is also referred to as Solution 1 in the present disclosure. In some embodiments of method 200, a new capability indication may be added in an RRCConnectionSetupComplete message which is transmitted from a UE to an eNB during an Attach/TAU procedure to indicate that the UE supports EN-DC. If the eNB identifies EN-DC capability of the UE from the RRCConnectionSetupComplete message, it may send an INITIAL UE MESSAGE to an MME supporting EN-DC directly; otherwise, eNB may randomly select an MME from an MME pool and send the INITIAL UE MESSAGE to it. However, it should be appreciated that embodiments are not limited to any specific way for indicating the capability of the terminal device to the eNB. Or in other words, the capability indication may be included in any suitable message.

FIG. 3 shows an Attach/TAU procedure 300 according to an embodiment of the present disclosure (e.g., an embodiment of method 200 or solution 1) schematically. In this example, it is assumed that there is a pool of CN nodes in which some CN nodes have been upgraded to support an enhanced communication feature (e.g., EN-DC) , while other nodes have not been upgraded. As an example, MME 303 in FIG. 3 is assumed to be an upgraded MME supporting EN-DC, while MME 304 is assumed to be a legacy MME without EN-DC capability. The network operator may maintain a record on capability of the MMEs, for example in a table, and inform the capability information to a RAN node, for example eNB 302 in FIG. 3, via Operation and Management (OAM) function. Each RAN Node (e.g., eNB or gNB) has an independent interface (e.g., S1 or N2) to a CN node included in the pool of CN nodes.

The network operator may make a policy which requires UE capable of an enhanced communication feature to camp on a CN node which supports the enhanced communication feature as well. With the example procedure shown in FIG. 3, the above requirement from the network operator may be satisfied.

In the example, eNB 302 maintains (310) a table of capability of CN nodes for NNSF (e.g., MME selection) based on UE capabilities. The table may be maintained via either local OAM configuration or signaling exchange. UE 301 camping on an E-UTRAN cell managed by eNB 302 initiates a radio resource control (RRC) connection establishment procedure for Attach or TAU by sending (320) an RRCConnectionRequest message to the eNB 302. eNB 302 sends (330) an RRCConnectionSetup message to UE 301 in response to the received RRCConnectionRequest message. Then, UE 301 sends (340) an RRCConnectionSetupComplete message to eNB 302. The RRCConnectionSetupComplete message carries a NAS Attach/TAU Request message to a core network node, and in addition, an EN-DC capability indication to the eNB 302 if UE 301 supports EN-DC. The EN-DC capability indication may be included in the RRCConnectionSetupComplete message as an AS signaling. If UE 301 has not been designated to an available MME, eNB 302 selects (350) an appropriate MME according to a UE capability based NNSF mechanism. The selection mechanisms described with reference to method 200 may be utilized here. For example, if UE 301 is capable of EN-DC, eNB 302 selects (350) MME 303 which supports EN-DC as well, and forwards (360) to it the NAS Attach/TAU Request message from UE 301. IfUE 301 is a legacy UE without EN-DC capability, eNB selects (350) a legacy MME 304, and forwards (370) to it the NAS Attach/TAU Request message from the UE 301. Thereafter, UE 301 may perform (380) Attach/TAU to the core network, for example using a normal attach/TAU procedure as defined in TS 23.401 which may involve further CN nodes, for example PDN GW (P-GW) or Serving GW (S-GW) 305 and HSS 306.

Similar to method 200, the above example procedure requires adding an indication on EN-DC capability (e.g., 1 bit) of UE into the RRCReconfigurationComplete message, but imposes no impact on NAS and CN.

Reference is now made to FIG. 4 which shows a flow chart of a method 400 for communication. The method may be implemented by, for example, terminal device 102 shown in FIG. 1 or UE 301 shown in FIG. 3. For ease of discussion, the method 200 will be described below with reference to terminal device 102 and the communication network 100 illustrated in FIG. 1. However, embodiments of the present disclosure are not limited thereto.

As shown in FIG. 4, at block 410, terminal device 102 generates a message by including an indication on capability of the terminal device 102 for supporting an enhanced communication feature as an AS signaling. For illustration rather than limitation, the message may be an RRCConnectionSetupComplete message as shown in FIG. 3. In some embodiments, the enhanced communication feature may include, but is not limited to, EN-DC.

At block 420, terminal device 102 transmits the message to a network device, for example, eNB 111 in FIG. 1. The message may be same as that received by eNB 111 at block 210 of method 200, and therefore descriptions with respect to the message provided with reference to method 200 also applies here.

In some embodiments, terminal device 102 may transmits the message to eNB 111 during an Attach/TAU procedure as shown in FIG. 3, and the message may include an Attach/TAU Request to a core network.

Alternatively, in some embodiments of the present disclosure, UEs are not required to indicate its EN-DC capability to the RAN node, for example, eNB. That is, a legacy RRCConnectionSetupComplete message may be transmitted from the UE to the eNB instead. In one embodiment, in response to receiving the legacy RRCConnectionSetupComplete message from the UE, the eNB may firstly try to select an MME supporting EN-DC for the UE without considering UE capability, and sends an INITIAL UE MESSAGE to the selected MME. The selected MME supporting EN-DC is able to identify from a NAS signaling (for example, an Attach/TAU Request included in the initial UE message) whether the UE is capable of EN-DC. If the UE is EN-DC capable, the MME accepts the UE’s Attach/TAU request, and a normal Attach procedure is performed. If the UE in incapable of EN-DC, the MME may decide whether to accept the Attach/TAU request from the UE based on one or more factors including, but not limited to, a local policy. In some embodiments, the local policy may include one or more of: a policy defined by a network operator on core network node (e.g., MME) selection preference, and a policy on load distribution. For illustration rather than limitation, in some embodiments, if the load of the MME is low, the MME may accept the UE and then a normal Attach procedure will be performed. If the load of the MME is high or the MME is only allowed to serve EN-DC capable UEs according to an operator’s policy, the MME may reroute the Attach request message via the eNB. The eNB in turn reroutes the Attach/TAU Request to a further MME. In some embodiments, the policy made by the network operator may require UE capable of an enhanced communication feature to camp on a CN node which supports the enhanced communication feature as well, and require UE incapable of an enhanced communication feature to camp on a CN node incapable of the enhanced communication feature.

In some embodiments, together with the rerouted INITIAL UE MESSAGE, the eNB may send additional information to the further MME to indicate that the INITIAL UE MESSAGE is a rerouted message; thereby prevent rerouting of the message by the further MME to other MMEs again. If the further MME accepts the UE, a normal Attach procedure will be performed; otherwise, the further MME may return the NAS message to the eNB for next rerouting. Such a solution is also referred to as Solution 2 in the present disclosure. Solution 2 avoids impact on legacy MME, UE and air interface, and only requires a minor change to the RAN node (e.g., eNB, S1 interface, and NNSF) and upgrade of the MME which supports the EN-DC feature.

FIG. 5 shows an Attach/TAU procedure according to an embodiment of Solution 2 of the present disclosure. In this example, eNB 502 maintains (510) a table of capability of CN nodes for NNSF (e.g., MME selection) . The table may be maintained via either local OAM configuration or signaling exchange. UE 501 camping on an E-UTRAN cell managed by the eNB 502 initiates (520) a NAS Attach/TAU Request message which is piggybacked on an RRCConnectionSetupComplete message to the eNB 502. Since NAS message is transparent to eNB 502, eNB 502 is unaware of EN-DC capability of the UE 501. If the UE 501 has not been designated to an available MME, eNB 502 may select (530) an appropriate MME for UE 501 according to an MME preference policy which assigns a higher selection priority to MMEs capable of EN-DC and a lower selection priority to legacy MMEs. For instance, MME 503 capable of EN-DC is selected, and eNB 502 forwards (540) the NAS Attach/TAU Request message towards the MME 503 in an initial UE message. Upon receiving the NAS Attach/TAU Request message, the MME 503 checks (550) EN-DC capability of UE 501. In an embodiment, ifUE 501 supports the EN-DC feature, MME 503 executes (560) subsequent Attach/TAU procedure normally, for example according to TS 23.401. In another embodiment, if UE 501 does not support EN-DC, MME 503 decides (570) whether to reroute the NAS message to another MME in the same MME pool, for example, legacy MME 504, according to a local policy, e.g., a policy of load redistribution for non-EN-DC UEs. The local policy of load redistribution may specify an allowed load level or a predefined ratio between 5G (including EN-DC) capable UEs and non-5G UEs. If the load redistribution criteria are not met, the MME 503 executes (580) subsequent Attach/TAU procedure normally, for example, according to TS 23.401. If the load redistribution criteria are met, the MME 503 sends (590) a Reroute NAS Request message back to the eNB 502. In addition, a new parameter may be included in the S1-AP message to indicate one or more of: capability of the UE, a reason for the rerouting, and/or an identity associated with a target MME (e.g., an MME group ID, MMGI) . When receiving the Reroute NAS Request message, the eNB 502 will select (591) another MME for the UE 501 by performing a conventional NNSF mechanism if target MME identity is not received, then forward (592) the NAS Attach/TAU request message to the selected MME (e.g., MME 504) in the same MME group. Then an Attach/TAU procedure is performed (593) normally, for example according to TS 23.401. For example, the Attach/TAU procedure may involve other CN nodes, such as S/P-GW 505 and HSS 506; however, embodiments are not limited thereto.

The embodiments described with reference to FIG. 5 does not require a new capability indication to be added in the RRCConnectionSetupComplete message, but UEs supporting EN-DC are still provided with a high possibility to be served by an EN-DC capable MME, since the eNB assigns a higher selection priority to the MMEs with EN-DC capability.

Reference is now made to FIG. 6 which illustrates a method 600 for providing communication service to a terminal device. The method may be implemented by, for example, the eNB 111 shown in FIG. 1 or the eNB 502 shown in FIG. 5. For ease of discussion, the method 600 will be described below with reference to eNB 111 and the communication network 100 illustrated in FIG. 1. However, embodiments of the present disclosure are not limited thereto.

As shown in FIG. 6, at block 610, eNB 111 receives a first message from a terminal device, for example UE 102 in FIG. 1. The first message may be sent by the terminal device during an RRC connection set up procedure. For example rather than limitation, the first message may be an RRCConnectionSetupComplete message transmitted by UE 102 during an Attach or TAU procedure as shown in FIG. 5.

At block 620, eNB 111 determines a core network node for the terminal device from a set of core network nodes based on a predefined selection rule in response to receiving the first message. The predefined selection rule defines a preference for selecting a core network node capable of supporting an enhanced communication feature for serving terminal devices. For instance, the predefined selection rule may assign a high selection priority to core network nodes capable of supporting an enhanced communication feature and a low selection priority to core network nodes incapable of supporting the enhanced communication feature. Correspondingly, in some embodiments, at block 620, eNB 111 may firstly select a core network node supporting the enhanced communication feature (e.g., MME 123 in FIG. 1) for the UE 102.

At block 630, eNB 111 sends at least a portion of the first message, for example an Attach/TAU Request included in the first message, to the determined core network node. In some embodiments, at block 630, eNB 111 may include the Attach/TAU Request into an Initial UE Message, and sends the Initial UE Message to the selected MME, as shown in FIG. 5.

In some embodiments, the selected MME (e.g., MME 123) may decide to reroute the Attach/TAU Request based on load requirement or capability of the UE 102, and in this case, eNB 111 may receive a reroute request message from the selected MME 123 at block 640. In response to the received reroute request message, eNB 111 reselects a further MME, for example MME 121, at block 650, and transmits the at least a portion of the first message again to the MME 121 at block 660.

In some embodiments, the reroute request message received by eNB 111 at block 640 may include at least one of: an indication on the capability of UE 102 for supporting the enhanced communication feature, and/or an identifier for a further core network node, for example, MMGI for MME 121. Correspondingly, at block 650, eNB 111 may select the further MME based on the capability of UE 102 and/or the identifier for the further core network node.

In some further embodiments, at block 660, eNB 111 may send additional information to the reselected MME 121, preventing MME 121 from rerouting the at least a portion of the first message (e.g., Attach/TAU Request) again. For example, the additional information may indicate that the at least a portion of the first message is a rerouted message.

FIG. 7 shows a method 700 implemented in a core network node for providing communication service to a terminal device. The method may be implemented by, for example,

MME

123 or 124 shown in FIG. 1 or MME 503 shown in FIG. 5. For ease of discussion, the method 700 will be described below with reference to MME 123 and the communication network 100 illustrated in FIG. 1. However, embodiments of the present disclosure are not limited thereto.

As shown in FIG. 7, at block 710, MME 123 receives a first message from a network device, for example eNB 111. In some embodiments, the first message may be an Initial UE Message shown in FIG. 5. Alternatively or in addition, the first message may include a NAS request from a terminal device, e.g., UE 102. As an example, the NAS request may include an Attach Request or a TAU Request.

At block 720, MME 123 identifies capability of the UE 102 for supporting an enhanced communication feature, e.g., EN-DC, based on the received first message. If UE 102 is incapable of supporting the enhanced communication feature, at block 730, MME 123 determines whether to reroute UE 102 to a further core network node, e.g., MME 121, based on a local policy, e.g., a local policy on load distribution. The local policy of load distribution may specify an allowed load level or a predefined ratio between 5G capable UEs (supporting EN-DC) and non-5G UEs. If the load redistribution criteria are not met, the MME 123 determines to execute subsequent Attach/TAU procedure normally, for example according to TS 23.401. If the load redistribution criteria are met, the MME 123 determines to reroute the UE 102.

At block 740, in response to determining to reroute the terminal device to a further core network node, MME 123 transmits a second message to eNB 111. The second message may be a reroute request message and may include at least one of an indication on the capability of the terminal device for supporting the enhanced communication feature, and/or an identifier for the further core network node, for example, MMGI for MME 121. Therefore, the second message enables eNB 111 to reselect a proper core network node, e.g., MME 121 in FIG. 1, for UE 102.

FIG. 8 shows a method 800 implemented in a core network node for providing communication service to a terminal device. The method may be implemented by, for example,

MME

121 or 122 shown in FIG. 1 or MME 504 shown in FIG. 5. For ease of discussion, the method 800 will be described below with reference to MME 121 and the communication network 100 illustrated in FIG. 1. However, embodiments of the present disclosure are not limited thereto.

As shown in FIG. 8, at block 810, MME 121 receives a message from a network device; the message includes a NAS request from a terminal device and additional information preventing MME 121 from rerouting the NAS request. In some embodiments, the message may be transmitted by eNB 111 at block 660. As an example, the message may be an Initial UE Message. In an embodiment, the message may include additional information indicating that the message is a rerouted message, thereby preventing MME 121 from rerouting it again.

At block 820, MME 121 accepts the NAS request in response to the received message. Thereafter, UE 102 may perform a normal attach/TAU procedure as defined in TS 23.401.

Embodiments described with reference to FIGs. 5-8 may be attractive solutions to network operators since these implementations only require a change to S1 interface between eNB and MMEs, without imposing an impact on air interface between UE and eNB.

In the following, another solution, referred to as solution 3, proposed in the present disclosure will be described. Solution 3 imposes no impact on the RAN node, for example eNB, but requires new operation at the core network node side and the UE. Generally speaking, with solution 3, eNB randomly selects an MME without considering UE capability and sends an INITIAL UE MESSAGE to the MME. If the MME is an upgraded MME supporting an enhanced communication feature, and identifies that UE is also capable of the enhanced communication feature, e.g., EN-DC, the MME will add a NAS EN-DC capability indicator in an Attach Accept message to the UE to indicate that EN-DC is supported by the core network. EN-DC capable UE recognizes the new NAS EN-DC capability indication and completes the Attach procedure. On the other hand, if the MME is incapable of EN-DC (i.e., a legacy MME) , and cannot identify the EN-DC capability of the UE, it will not add a NAS EN-DC capability indicator in the Attach Accept message to the UE. As a result, a normal legacy Attach procedure is performed. However, if the UE supports EN-DC, and fails to detect the EN-DC capability indicator in the Attach Accept message, it may initiate another Attach/TAU procedure without designated MME information, in order to seek a chance to be served by an upgrade MME. Some embodiments of the solution 3 will be described below with reference to FIGs 9-11.

FIG. 9 illustrates an example Attach/TAU procedure 900 according to an embodiment of Solution 3 of the present disclosure. In the example, UE 901 camping on an E-UTRAN cell managed by eNB 902 initiates (910) a NAS Attach/TAU Request message which is piggybacked on a legacy RRCConnectionSetupComplete message. Note that no EN-DC capability indication is added into the legacy RRCConnectionSetupComplete message. If UE 901 has not been designated to an available MME, eNB 902 may select (920) an MME randomly for UE 901 without considering capability of UE 901 and send (930) an INITIAL UE MESSAGE bearing the NAS Attach/TAU Request to the selected MME 903. Alternatively, eNB 902 may select an MME based on predefined selection rule, for example the selection rule described with reference to FIG. 5; however, embodiments are not limited thereto.

Upon receiving the NAS Attach/TAU Request message, MME 903 may optionally communicate (940) with other core network nodes (e.g., S/P-GW 904 and HSS 905) to perform location update and/or session creation, or any other procedure required.

In addition, if MME 903 is an upgraded MME supporting EN-DC, it may check (950) EN-DC capability and/or HSS subscription data of UE 901, and verify whether the enhanced feature of EN-DC can be enabled for UE 901 or not. In an embodiment, if both MME 903 and UE 901 supports EN-DC feature (and optionally HSS subscription data allow UE 901 to use the EN-DC feature) , MME 903 may send (960) a NSA Attach Accept message (and an Initial Context Setup Request) with a NAS EN-DC Supported Indication to UE 901 via eNB 902. In another embodiment, if either UE 901 or MME 903 (or optionally HSS subscription data) does not support EN-DC feature, MME 903 sends (970) a normal Attach Accept message without the new NAS EN-DC Supported Indication to UE 901 via eNB 902.

Then subsequent normal Attach/TAU procedure may be performed (980) , which may include, for example, but is not limited to, RRC connection reconfiguration and initial context setup.

Optionally, in some embodiments, after receiving the NAS Attach Accept message from MME 903, UE 901 supporting EN-DC feature may check whether the NAS EN-DC supported indication is included in the NAS Attach Accept message, and may initiate (990) another Attach/TAU procedure without designated MME information in case no NAS EN-DC supported indication is detected. In this way, a terminal device supporting EN-DC is enabled to switch to another MME is current MME allocated to it is incapable supporting the EN-DC feature.

Reference is now made to FIG. 10 which shows a flow chart of a method 1000 for providing a communication service to a terminal device according to an embodiment of the present disclosure. The method may be implemented in a core network node supporting an enhanced communication feature, for example (but is not limited to) EN-DC. The core network may be, for example,

MME

123 or 124 in FIG. 1 or MME 903 in FIG. 9. For ease of discussion, method 1000 will be described below with reference to MME 123 and the communication network 100 illustrated in FIG. 1. However, embodiments of the present disclosure are not limited thereto.

As shown in FIG. 10, at block 1010, MME 123 receives a first message from a network device, for example eNB 111 in FIG. 1. The first message includes a NAS request from a terminal device, for example UE 102. In an embodiment, the first message may be an Initial UE Message as shown in FIG. 9. Alternatively or in addition, the NAS request may include an Attach Request or a TAU Request.

At block 1020, MME 123 identifies capability of UE 102 for supporting the enhanced communication feature (e.g., EN-DC) based on the received first message. If UE 102 is capable of supporting the enhanced communication feature, at block 1030, MME 123 informs UE 102 that the enhanced communication feature is supported by the core network. For example, MME 123 may transmit a second message to UE 102 via the network device 111, to indicate that the enhanced communication feature is also supported by the core network. Upon receiving the second message, UE 102 knows that service may be provided by using the enhanced communication feature. In some embodiments, at block 1030, the second message is transmitted to UE 102 via a NAS signaling. It means that impact to the eNB 111 may be avoided.

In some embodiments, optionally, MME 123 may determine at block 1025 whether to enable the enhanced communication feature for UE 102 based on HSS subscription data of UE 102. Then only when the HSS subscription data of UE 102 allows the enhanced communication feature for UE 102, MME 123 informs UE 102 that the enhanced communication feature is supported by the core network.

FIG. 11 shows a flow chart of a method 1100 in a terminal device according to an embodiment of the present disclosure. The terminal device supports an enhanced communication feature, for example (but not limited to) EN-DC. The terminal device may be, for example, UE 102 in FIG. 1 or UE 901 in FIG. 9. For ease of discussion, method 1100 will be described below with reference to UE 102 and the communication network 100 illustrated in FIG. 1. However, embodiments of the present disclosure are not limited thereto.

As shown in FIG. 11, at block 1110, UE 102 transmits a first message to a network device, e.g., eNB 111. The first message includes a NAS request to a core network. In an embodiment, the first message may be an RRCConnnectionSetupComplete message as shown in FIG. 9. Alternatively or in addition, the NAS request may include an Attach or TAU Request.

At block 1120, UE 102 receives a second message in response to the first message from a core network node, e.g., MME 123 in FIG. 1, via eNB 111. In an embodiment, the second message may be received in a NAS signaling transparent to eNB 111.

At block 1130, UE 102 determines whether the enhanced communication feature is supported by the core network based on the second message. In some embodiments, if the enhanced communication feature, e.g., EN-DC, is supported by MME 123 (and optionally a HSS not shown in FIG. 1) , the second message received at block 1120 includes an indication showing that EN-DC is supported by the core network.

If UE 102 determines at block 1130 that the enhanced communication feature is supported by the core network, at block 1140, it completes a procedure related to the NAS request, e.g., completing an Attach/TAU procedure normally.

In some embodiments, if UE 102 determines at block 1130 that the enhanced communication feature is not supported by the core network, it may initiate a further procedure related to the NAS request (e.g., another Attach/TAU procedure without designated MME information) at block 1150, for example by transmitting a third message to eNB 111, and the third message includes another NAS request to the core network.

Method 1100 allows UE capable of EN-DC to switch from a legacy MME to an upgraded MME, without imposing obvious impact on the RAN node, e.g., eNB.

FIG. 12 illustrates a simplified block diagram of an apparatus 1200 that may be embodied as or comprised in a communication device, for example, a terminal device, an eNB or an MME shown in FIG. 1, FIG. 3, FIG. 5, or FIG. 9.

The apparatus 1200 comprises at least one processor 1211, such as a data processor (DP) and at least one memory (MEM) 1212 coupled to the processor 1211. The apparatus 1210 may further include a transmitter TX and receiver RX 1213 coupled to the processor 1211, which may be operable to communicatively connect to other apparatuses. The MEM 1212 stores a program (PROG) 1214. The PROG 1214 may include instructions that, when executed on the associated processor 1211, enable the apparatus 1200 to operate in accordance with embodiments of the present disclosure, for

example method

200, 400, 600, 700, 800, 1000 or 1100. A combination of the at least one processor 1211 and the at least one MEM 1212 may form processing means 1215 adapted to implement various embodiments of the present disclosure.

Various embodiments of the present disclosure may be implemented by computer program executable by one or more of the processor 1211, software, firmware, hardware or in a combination thereof.

The MEM 1212 may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory, as non-limiting examples.

The processor 1211 may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples.

In addition, the present disclosure may also provide a carrier containing the computer program as mentioned above. The carrier includes computer readable storage medium which may be, for example, an optical compact disk or an electronic memory device like a RAM (random access memory) , a ROM (read only memory) , Flash memory, magnetic tape, CD-ROM, DVD, Blue-ray disc and the like.

The techniques described herein may be implemented by various means so that an apparatus implementing one or more functions of a corresponding apparatus described with an embodiment comprises not only prior art means, but also means for implementing the one or more functions of the corresponding apparatus described with the embodiment and it may comprise separate means for each separate function, or means that may be configured to perform two or more functions. For example, these techniques may be implemented in hardware (one or more apparatuses) , firmware (one or more apparatuses) , software (one or more modules) , or combinations thereof. For a firmware or software, implementation may be made through modules (e.g., procedures, functions, and so on) that perform the functions described herein.

Exemplary embodiments herein have been described above with reference to block diagrams and flowchart illustrations of methods and apparatuses. It will be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, respectively, can be implemented by various means including computer program instructions. These computer program instructions may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create means for implementing the functions specified in the flowchart block or blocks.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any implementation or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular implementations. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.

It will be obvious to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The above described embodiments are given for describing rather than limiting the disclosure, and it is to be understood that modifications and variations may be resorted to without departing from the spirit and scope of the disclosure as those skilled in the art readily understand. Such modifications and variations are considered to be within the scope of the disclosure and the appended claims. The protection scope of the disclosure is defined by the accompanying claims.

Some abbreviations used in the present disclosure and their corresponding expressions are list below:

CAPEX Capital Expenditure

DCN Dedicated Core Network

EN-DC E-UTRA-NR Dual Connectivity

EPC Evolved Packet Core

EPS Evolved Packet System

MME Mobility Management Entity

MNO Mobile Network Operator

NR New Radio.

Claims

A method in a network device for providing a communication service to a terminal device, comprising:

receiving a message from the terminal device;

identifying capability of the terminal device for supporting an enhanced communication feature based on the message;

determining a core network node for the terminal device based on the identified capability of the terminal device; and

sending at least a portion of the message to the determined core network node.
The method of Claim 1, wherein identifying capability of the terminal device for supporting an enhanced communication feature based on the message comprises:

in response to failure in detecting an indication on the capability of the terminal device from the message, identifying the terminal device as being incapable of supporting the enhanced communication feature.
The method of Claim 1, wherein identifying capability of the terminal device for supporting an enhanced communication feature based on the message comprises:

in response to detecting Access Stratum information from the message indicating that the terminal device is capable of supporting the enhanced communication feature, identifying the terminal device as being capable of supporting the enhanced communication feature.
The method of Claim 1, wherein determining a core network node for the terminal device based on the identified capability of the terminal device comprises one of:

in response to identifying the terminal device as being incapable of supporting the enhanced communication feature, determining a core network node for the terminal device randomly from a set of core network nodes;

in response to identifying the terminal device as being incapable of supporting the enhanced communication feature, determining for the terminal device a core network node incapable of supporting the enhanced communication feature from the set of core network nodes or a core network node capable of supporting the enhanced communication feature from the set of core network nodes; and

in response to identifying the terminal device as being capable of supporting the enhanced communication feature, determining for the terminal device a core network node capable of supporting the enhanced communication feature from the set of core network nodes.
The method of Claim 1, wherein receiving a message from the terminal device comprises receiving the message during a radio resource control, RRC, connection set up procedure of the terminal device, and

wherein the at least a portion of the message includes an Attach Request or a Track Area Update Request included in the message.
The method of any of Claims 1 to 5, wherein the core network node includes a mobility management entity.
A method in a terminal device for communication, comprising:

generating a message by including an indication on capability of the terminal device for supporting an enhanced communication feature as an Access Stratum signaling; and

transmitting the message to a network device.
The method of Claim 7, wherein transmitting the message to a network device comprises transmitting the message to the network device during a radio resource control, RRC, connection set up procedure.
A method in a network device for providing a communication service to a terminal device, comprising:

receiving a first message from the terminal device;

in response to receiving the first message,

determining a core network node for the terminal device from a set of core network nodes, based on a predefined selection rule which assigns a higher selection priority to core network nodes capable of supporting an enhanced communication feature and a lower selection priority to core network nodes incapable of supporting the enhanced communication feature; and

sending at least a portion of the first message to the determined core network node.
The method of Claim 9, further comprising:

receiving, from the determined core network node, a reroute request message including at least one of an indication on the capability of the terminal device for supporting the enhanced communication feature, and an identifier for a further core network node;

selecting a further core network node based on the at least one of the indication and the identifier; and

transmitting the at least a portion of the first message to the further core network node.
The method of Claim 10, wherein transmitting the at least a portion of the first message to the further core network node comprises:

transmitting the at least a portion of the first message together with additional information to the further core network node, the additional information preventing the further core network node from rerouting the at least a portion of the first message again.
The method of any of Claims 9 to 11, wherein the core network node includes a mobility management entity.
A method in a core network node for providing a communication service to a terminal device, comprising:

receiving a first message from a network device, the first message including a Non-Access Stratum, NAS, request from the terminal device;

identifying capability of the terminal device for supporting an enhanced communication feature based on the received first message;

in response to identifying that the terminal device is incapable of supporting the enhanced communication feature, determining whether to reroute the terminal device to a further core network node based on a local policy; and

in response to determining to reroute the terminal device to a further core network node, transmitting a second message to the network device, the second message including at least one of:

an indication on the capability of the terminal device for supporting the enhanced communication feature, and

an identifier for the further core network node.
The method of Claim 13, wherein the load policy includes one or more of:

a policy on load distribution; and

a policy defined by a network operator on core network node selection preference.
The method of Claim 13, wherein the core network node includes a mobility management entity.
The method of Claim 13, wherein the NAS request includes an Attach Request or a Track Area Update Request.
A method in a core network node for providing a communication service to a terminal device, comprising:

receiving a message from a network device, the message including a Non-Access Stratum, NAS, request from the terminal device and additional information preventing the core network node from rerouting the NAS request; and

accepting the NAS request in response to the received message.
A method in a core network node for providing a communication service to a terminal device, the core network node supporting an enhanced communication feature, and the method comprising:

receiving a message from a network device, the message including a Non-Access Stratum, NAS, request from the terminal device;

identifying capability of the terminal device for supporting the enhanced communication feature based on the received message; and

in response to identifying that the terminal device is capable of supporting the enhanced communication feature, informing the terminal device via the network device that the enhanced communication feature is supported by the core network.
The method of Claim 18, further comprises:

determining whether to enable the enhanced communication feature for the terminal device based on subscription data of the terminal device; and

wherein informing the terminal device comprises:

informing the terminal device in response to determining to enable the enhanced communication feature for the terminal device.
The method of Claim 18, wherein the NAS request includes an Attach Request or a Track Area Update Request.
The method of Claim 19, wherein informing the terminal device comprises:

informing the terminal device via a NAS signaling.
A method in a terminal device supporting an enhanced communication feature, comprising:

transmitting a first message to a network device, the first message including a Non-Access Stratum, NAS, request to a core network;

receiving a second message in response to the first message from a core network node via the network device;

determining whether the enhanced communication feature is supported by the core network based on the second message; and

in response to determining that the enhanced communication feature is supported by the core network, completing a procedure related to the NAS request.
The method of Claim 22, further comprising:

in response to determining that the enhanced communication feature is not supported by the core network, initiating a further procedure related to the NAS request by transmitting a third message to the network device, the third message including the NAS request to the core network.
The method of Claim 22 or 23, wherein the NAS request includes an Attach Request or a Track Area Update Request.
The method of Claim 22 or 23, wherein receiving a second message includes:

receiving the second message via a NAS signaling.
A network device, comprising a processor and a memory, said memory containing instructions executable by said processor whereby said network device is operative to perform a method according to any of Claims 1-6 and 9-12.
A terminal device, comprising a processor and a memory, said memory containing instructions executable by said processor whereby said terminal device is operative to perform a method according to any of Claims 7-8 and 22-25.
A core network device, comprising a processor and a memory, said memory containing instructions executable by said processor whereby said terminal device is operative to perform a method according to any of Claims 13-21.
A computer readable medium with a computer program stored thereon which, when executed by at least one processor of a device, causes the device to carry out the method of any of claims 1-6 and 9-12.
A computer readable medium with a computer program stored thereon which, when executed by at least one processor of a device, causes the device to carry out the method of any of claims 7-8 and 22-25.
A computer readable medium with a computer program stored thereon which, when executed by at least one processor of a device, causes the device to carry out the method of any of claims 13-21.