WO2018038012A1

WO2018038012A1 - Method of dual connectivity dependent charging in ims

Info

Publication number: WO2018038012A1
Application number: PCT/JP2017/029619
Authority: WO
Inventors: Andreas Kunz; Toshiyuki Tamura; Genadi Velev; Filipe LEITAO
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2016-08-22
Filing date: 2017-08-18
Publication date: 2018-03-01
Anticipated expiration: 2019-02-22

Abstract

This disclosure provides an access network node including: a receiver configure to receive an information from a core network node for restricting the access network node to configure dual connectivity with a New Radio (NR) for a User Equipment (UE); and a processor configured to process to determine whether the dual connectivity with the NR as secondary radio access technology is configured or not based on the information.

Description

METHOD OF DUAL CONNECTIVITY DEPENDENT CHARGING IN IMS

The present disclosure relates to a communication system. The present disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof. The present disclosure has particular although not exclusive relevance to dual connectivity dependent charging.

Currently, the Dual Connectivity (DC) feature, as defined in the 3GPP TS 36.300 [see, NPL 5], is focusing only on Long Term Evolution (LTE) Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access for both the Master eNB (MeNB) and Secondary eNB (SeNB). Within this scenario of the DC feature, a different charging scheme in case a User Equipment (UE) is connected through the SeNB is not considered since the access is the same (LTE) in both cases.

Assuming that radio access points or cells may include other access types, like small cells may include both LTE/E-UTRAN access and non-3GPP access (e.g. Wi-Fi access), it is foreseen that DC may be extended to include different radio access types used as a MeNB and a SeNB. More specifically, it could be possible to use wireless local area network (WLAN) as a SeNB option, e.g. via a WLAN Termination (WT) entity. Further the future New Radio (NR) access technology (commonly referred as 5G radio access) could also be integrated with the LTE system in a way similar, to the small cell scheme, to the SeNB. For this reason, we use the term Secondary Radio Node (SRN) instead of the SeNB, which means that the SRN is connected to the MeNB like the SeNB but can comprise of one or more different radio access technologies, not limited to LTE, LTE-Advanced (LTE-A), LTE-A-Pro, NR, wideband code division multiple access (WCDMA), High Speed Packet Access (HSPA), General Packet Radio Service (GPRS), ZigBEE, Bluetooth, CDMA2000 etc.

Considering the scenario described where DC could make use of more than one access type simultaneously, business models, regulators and service level agreements require a more fine granular way of differentiating the access network used in DC.

3GPP TR 23.799 v0.6.0, 2016-07-22, "Study on Architecture for Next Generation System" 3GPP TS 23.203, v14.0.0, 2016-06-22, "Policy and charging control architecture" 3GPP TS 23.401, v14.0.0, 2016-06-22, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access" 3GPP TS 29.213 v14.0.0, 2016-06-23, "Policy and charging control signalling flows and Quality of Service (QoS) parameter mapping" 3GPP TS 36.300 v13.4.0, 2016-07-07, "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; 3GPP TS 29.212 v14.0.0, 2016-06-22, "Policy and Charging Control (PCC); Reference points" 3GPP TS 29.214 v14.0.0, 2016-06-23, "Policy and Charging Control over Rx reference point" 3GPP TS 23.402 v14.0.0, 2016-06-22, "Architecture enhancements for non-3GPP accesses" BBF TR-134, September 2014, "Broadband Policy Control Framework (BPCF), Corrigendum 1" 3GPP TS 23.228, v14.0.0, 2016-06-22, "IP Multimedia Subsystem (IMS);

At the moment, only the MeNB radio access technology (RAT) type is provided to the core network, but the MeNB RAT type is not enough especially if specific service flows/bearers are moved to the SRN. As an example, it could be that voice over IP Multimedia Subsystem (IMS) sessions are free over WLAN, as non-licensed spectrum, but charged over NR, but the IMS does not know what kind of RAT is used and whether DC is used at all. As a consequence, operators might charge voice over IMS session wrongly if different tariffs are applied to one for LTE access and the other one for WLAN access.

An example aspect of the present disclosure is an access network node including: a receiver configured to receive an information from a core network node for restricting the access network node to configure dual connectivity with a New Radio (NR) for a User Equipment (UE); and at least one processor configured to process to determine whether the dual connectivity with the NR as secondary radio access technology is configured or not based on the information.

Figure 1 shows the different connection options via a MeNB and a SRN; Figure 2 shows the high level architecture on the basis of an E-UTRAN/EPC network; Figure 3 shows the overall high-level architecture in case the MeNB/SRN are connected to the NG CN; Figure 4 shows the dedicated bearer setup when the UE is sending an INVITE message; Figure 5 illustrates an exemplary procedure for RAT reporting to IMS using SIP SUBSCRIBE/NOTIFY message; Figure 6 illustrates an exemplary procedure for RAT reporting to IMS with OPTIONS; Figure 7 illustrates an exemplary DC-POLICY execution in the UE; Figure 8 is a block diagram illustrating the main components of the PCRF; Figure 9 is a block diagram illustrating the main components of the P-CSCF; Figure 10 is a block diagram illustrating the main components of the MeNB; Figure 11 shows an example to indicate how parameter DC-RAT in Rx AAR (TS 29.214) may be integrated; and Figure 12 shows an example to indicate how parameter DC-POLICY in Gx CCR (TS 29.212) could be integrated.

Figure 1 shows the different connection options via a MeNB 12 and a SRN 14. The dotted box comprising the secondary cell options can be also seen as one functional entity SRN 14 that is capable of supporting the different RATs (although it will be appreciated that different RATs may be supported by different functional entities, if appropriate). For this case, the interface between the MeNB 12 and the SRN 14 may be common and support a protocol able to serve all different RATs. The new reference points gX2 refer to the interface between the MeNB 12 and a New Radio Base Station (NR BS) 16, and gUu refer to the radio interface between the NR BS 16 and a UE 18.

Figure 2 shows the high level architecture on the basis of an E-UTRAN network 2. The SRN 14 is used here as a general term including different radio access technologies, e.g. LTE, Universal Mobile Telecommunications System (UMTS), WLAN (IEEE 802.11 variants), NR etc. or same radio access technology but provided over an unlicensed frequency band (e.g. LTE-U). The MeNB/SRN 12/14 can use the two different deployment options as described for DC in TS 36.300 [see, NPL 5]. Further the MeNB/SRN 12/14 can be connected to the Evolved Packet core (EPC) network [see, NPL 3] and as well to the next generation core network (NG CN) as described in [NPL 1].

In case that the MeNB/SRN 12/14 are connected to the NG CN, then the following mapping of the EPC entities apply according to TR 23.799 [see, NPL 1]:

Figure 3 shows the overall high-level architecture in case the MeNB/SRN 12/14 are connected to the NG CN.

The present disclosure is not limited to IMS services, thus, the technique of the present disclosure is applicable to all services using an Application Function (AF) 20 or the Service Capability Exposure Function (SCEF) that interacts with the core network through the policy control entity in a similar way.

The present disclosure includes the following parts:
1.　　　Dedicated bearer (service flow) setup and DC-POLICY installation
2.　　　RAT type notification in case of RAT type changes
3.　　　Example purely based on Policy Call Session Control Function (P-CSCF) 22 and UE control

Further, the call flows are described with functional entities from the E-UTRAN but can be mapped to the next generation core network as described above in a similar way. The terms service (data) flow, data connection, Internet Protocol (IP) flow etc., could be used synonymously for other networks instead of the term “bearer” used here in the E-UTRAN context.

1. Dedicated bearer (service flow) setup and DC policy installation
Figure 4 shows the dedicated bearer setup when the UE 18 is sending an INVITE message. Alternatively, the AF 20 could be triggered, for example, by a Traffic Detection Function (TDF) which interacts with a Policy Control Rule Function (PCRF) 24 for the dedicated bearer setup.

Step 1: As a precondition, the UE 18 is attached to the 3GPP system according to TS 23.401 [see, NPL 3] and already IMS registered according to TS 23.228 [see, NPL 10], and the P-CSCF 22 may be subscribed to the IP Connectivity Access Network (IP-CAN) changes at the time of IMS registration (see TS 23.203 [see, NPL 2]).
　　　　The default Session Initiation Protocol (SIP) bearer may be set over only LTE access, only UMTS access, only WLAN (IEEE 802.11 variants) access, only NR or DC that has been configured between different RATs.

Step 2: The UE 18 sends a SIP INVITE message according to TS 23.228 [see, NPL 10] to the P-CSCF 22 including the DC-RAT indication (new parameter) in the SIP header field. The DC-RAT indication indicates a list of acceptable RATs to be used for a certain media in the Session Description Protocol (SDP), e.g. LTE, and UMTS access are only acceptable for IMS Voice. The DC-RAT indication may be configured in the IMS client based on the operator policy, e.g. by the Access network discovery and selection function (ANDSF), the Open Mobile Alliance-Device Management (OMA-DM) or any Operations, Administration and Maintenance (OAM) configuration services, taking UE capability into account.

Step 3: The P-CSCF 22 takes the received information into account and generates a Diameter Authentication Authorization Request (AAR) message and sends the Diameter AAR message towards the PCRF 24 over the Rx Reference Point. The P-CSCF 22 provides the PCRF 24 with a service information includes the DC-RAT (new parameter), to create a new Rx Diameter session.

Step 4: The PCRF 24 stores the received service information, including the DC-RAT indication if received, and performs session binding.

Step 5: The PCRF 24 replies to the P-CSCF 22 with a Diameter Authentication Authorization Answer (AAA) message, accordingly.

Step 6: The PCRF 24 may interact with the Subscriber Profile Repository/User Data Repository (SPR/UDR) to generate a Policy and Charging Control/Quality of Service (PCC/QoS) rule for updating the subscriber Packet Data Network (PDN) session. Based on subscription information obtained from the SPR/UDR and the DC-RAT indication received in the Diameter AAR message from the P-CSCF 22 as well as the session information, the PCRF 24 selects a DC-POLICY indication to be further used in the dedicated bearer setup. The DC-POLICY indication is explained further below this call flow.

Step 7: If the P-CSCF 22 requests an access network information in step 3, the PCRF 24 does not use the access network information that is used to send the current SIP request message, but the access network information results from the policy decision of step 6 and forwards the access network information results from the policy decision of step 6 in a Diameter Re-Authentication-Request (RAR) message. This access network information may be overwritten in step 17 and step 18 where the result of the MeNB decision is provided back to the P-CSCF 22.

Step 8: The P-CSCF 22 acknowledges the receipt of the Diameter RAR message.

Step 9: The P-CSCF 22 verifies the PCRF decision and may already prepare or enable fine granular radio access dependent charging, else the P-CSCF 22 may wait with this decision until step 18.

Step 10: The P-CSCF 22 includes the DC-RAT indication (new parameter), as received from the PCRF 24 in Step 7, in the INVITE message forwarded to the Interrogating/Serving Call Session Control Function (I/S-CSCF).

Step 11: According to the policy decision taken in Step 6, the PCRF 24 initiates the IP-CAN Session modification according to the procedures defined in [NPL 4]. In step 11, the PCRF 24 sends the Diameter RAR message including the DC-POLICY indication (new parameter) to the Packet Data Network-Gateway, PDN-GW (PGW) 26.

Step 12: According to the PCC/QoS-Rule received in Step 11, the PDN-GW 26 assigns the Evolved Packet System (EPS) Bearer QoS, i.e., the PDN-GW 26 assigns the values to the bearer level QoS parameters: the QoS Class Identifier (QCI), the Allocation and Retention Priority (ARP), the Guaranteed Bit Rate (GBR) and the Maximum Bit Rate (MBR), according to the procedures defined in [NPL 4]. The PDN-GW 26 sends a Create Bearer Request message (including the International Mobile Subscriber Identifier (IMSI), the Procedure Transaction Identity (PTI), the EPS Bearer QoS, the Traffic Flow Template (TFT), the S5/S8 Tunnel Endpoint Identifier (TEID), the Charging Id, the Linked EPS Bearer Identity (LBI), the Protocol Configuration Options, and the DC-POLICY indication) to the Serving GW (SGW) 28.

Step 13: The Serving GW 28 sends the Create Bearer Request (including the IMSI, the PTI, the EPS Bearer QoS, the TFT, the S1-TEID, the PDN GW TEID (GTP-based S5/S8), the LBI, the Protocol Configuration Options, and the DC-POLICY indication) message to a Mobility Management Entity (MME) 30.

Step 14: The MME 30 then builds a Bearer Setup/Session Management Request message including the PTI, the TFT, the EPS Bearer QoS parameters (excluding the ARP), the Protocol Configuration Options, the EPS Bearer Identity, the LBI, a WLAN offloadability indication and the DC-POLICY indication, and sends the Bearer Setup/Session Management Request message to the MeNB 12. The MME 30 may modify the DC-POLICY indication based on the subscriber data obtained from a Home Subscriber Server (HSS) 32 at the Authentication/Security procedures described in [NPL 3].

Step 15: The MeNB 12 authorizes the Bearer Setup Request and establishes the radio bearer between the MeNB 12 and UE 18. The DC-POLICY indication is kept in the MeNB 12. The DC-POLICY indication may be used in the MeNB 12 when the MeNB 12 initiates the SRN Addition procedure. The DC-POLICY indication is transferred to the old eNB to the new eNB in case X2 Handover (HO) procedure takes place.

Step 16: The MeNB 12 acknowledges the bearer activation to the MME 30 with a Bearer Setup Response (including the EPS Bearer Identity, the S1-TEID, and the DC-RAT indication) message. The MeNB 12 indicates the DC-RAT indication selected for the bearer and sends a Session Management Response message to the MME 30 as well.

Step 17: Upon reception of the Bearer Setup Response message and the Session Management Response message, the MME 30 acknowledges the bearer activation to the Serving GW 28 by sending a Create Bearer Response (including the EPS Bearer Identity, the S1-TEID, the User Location Information (E-UTRAN Cell Global Identifier (ECGI)), and the DC-RAT indication) message. The Serving GW 28 acknowledges the bearer activation to the PDN-GW 26 by sending a Create Bearer Response (including the EPS Bearer Identity, the S5/S8-TEID, and the User Location Information (ECGI), and the DC-RAT indication) message. The PDN-GW 26 indicates to the PCRF 24 that the requested PCC decision (including the QoS policy and the DC-POLICY indication) could be enforced and which DC-RAT indication is used. The PCRF 24 provides the DC-RAT indication to the P-CSCF 22. In order to provide this DC-RAT indication, the PGW/PCRF 26/24 and P-CSCF 22 may have subscribed to DC-RAT changes only, i.e. the RAT changes not subject to the DC feature are not reported to the P-CSCF 22.

Step 18: The P-CSCF 22 verifies whether there is a change in the DC-RAT originally provided in the PCRF decision in step 7 and enables fine granular radio access dependent charging.

Step 19: The remote end acknowledges the SIP INVITE message with a SIP 200 OK, which is forwarded by the P-CSCF 22 to the UE 18.

Description of the proposed parameters DC-RAT and DC-POLICY
DC-RAT
The DC-RAT indication can be a bit map style, integer type or Extensible Markup Language (XML) scheme type indicating at least the following meanings:
　　　　- DC is allowed or DC is not allowed.
　　　　- List of allowed RAT type: all RAT type that can be used to transport media data are listed. The RAT type can be found in the section 5.3.31 in 3GPP TS 29.212 [see, NPL 6].
　　　　- Licensed or Unlicensed: This is an associated information to the RAT type. In addition to the RAT type, this information further indicates whether unlicensed 3GPP access is further usable or not.

When the DC-RAT indication is sent from the AF/P-CSCF 20/22 to the PCRF 24 (Step 3 of Figure 4), then the AAR message as defined in the 3GPP TS 29.214 [see, NPL 7] can be used as example to indicate how this parameter may be integrated. This is shown in Figure 11.

Specifically, in the example shown in Figure 11: if the DC-RAT indication comes at the AAR command level, the DC-RAT indication indicates the list of allowed RAT types for all the media sessions described in this AAR message; if the DC-RAT indication comes at the Media-Component-Description level, the DC-RAT indication indicates the list of allowed RAT types for the particular media session described in this component.

The same analogy may be used for the RAR message depicted in Step 7 of Figure 4.

DC-POLICY
Depending on the situation, and the interface/reference point used, the DC-POLICY indication may be represented in different ways. For example:
　　　　* If the DC-POLICY indication is indicated on a per-bearer granularity, then the DC-POLICY indication may be represented by a bitmap with (although not limited to) the options:
　　　　- DC Allowed via LTE: yes/no
　　　　- DC Allowed via NR: yes/no
　　　　- DC Allowed via Wi-Fi: yes/no
　　　　- DC Allowed via RAT: yes/no.
　　　　Another option would be to indicate a list with the PCRF 24 authorized RAT types to be used in DC.
　　　　When the DC-POLICY indication is sent from the PCRF 24 to the PGW 26 (Step 11 of Figure 4), then the Credit Control Request (CCR) message as defined in the 3GPP TS 29.212 [see, NPL 6] may be used as example to indicate how this parameter could be integrated. This is shown in Figure 12.
　　　　Although in the example shown in Figure 12 the Diameter Gx CCR command [see, NPL 6] is used, the same analogy should be valid for other policy enforcement reference points/interfaces, such as Sd Reference Point [see, NPL 6], St Reference Point [see, NPL 6], S14 Reference Point [see, NPL 8] or R Reference Point for fixed-access [see, NPL 9].

　　　　* If the DC-POLICY indication is indicated for all UE sessions/bearers, the DC-POLICY indication may be represented by a bitmap with involving QoS indication parameters, e.g. QCI, and ARP. For example:
　　　　- QCI1: no DC / yes via LTE / yes via NR / yes via WLAN, / yes via other RAT;
　　　　- QCI2: no DC / yes via LTE / yes via NR / yes via WLAN, / yes via other RAT;
　　　　- QCI3, QCI4, QCI5, etc.

NOTE: analogically also the ARP parameter may be included together in a combination with the QCI, i.e. yes/no configuration is done per combination of QCI and ARP.

　　　　* If the DC-POLICY indication is for any UE and any bearer, then the DC-POLICY indication may be similar to the structure as shown in the previous bullet.

2. RAT type notification in case of RAT type changes
The following procedures provide different example embodiments on how the UE 18 can provide RAT type notifications in case of RAT type changes. All example embodiments of

option

1, 2 and 3 have in common that they are based on the Dedicate Bearer Setup/IMS Session Setup procedure described in Figure 4.

Option 1: RAT Reporting with SIP SUBSCRIBE/NOTIFY
Figure 5 illustrates an exemplary procedure for RAT reporting to IMS using SIP SUBSCRIBE/NOTIFY message.
Step 1: The UE 18 performs the Dedicated Bearer Setup/IMS Session setup procedure as described in Figure 4.
Step 2: The P-CSCF 22 decides to subscribe to DC-RAT changes directly from the UE 18.
Step 3: The P-CSCF 22 sends a SIP SUBSCRIBE message with a DC-RAT Reporting Event Package to the UE 18.
Step 4: The UE 18 installs a trigger on DC-RAT change and acknowledges the subscription with a SIP 200 OK message.
Step 5: Due to handover, MeNB 12 decisions or other circumstances, the UE 18 changes the DC-RAT.
Step 6: The UE 18 recognizes the DC-RAT change and notifies the P-CSCF 22 with a SIP NOTIFY message and the DC-RAT.
Step 7: The P-CSCF 22 may verify the information from the UE 18 with network provided location information (NPLI) from the PCRF 24, if available and may adjust the charging accordingly.
Step 8: The P-CSCF 22 acknowledges the notification with a SIP 200 OK message.

Option 2: RAT Reporting with SIP OPTIONS
In this example, the P-CSCF 22 provides a DC-RAT Reporting Indication to the UE 18 in a 200 OK message from the remote end.

Figure 6 illustrates an exemplary procedure for RAT reporting to the IMS with a SIP OPTIONS message.
Step 1: The UE 18 performs the Dedicated Bearer Setup/IMS Session setup procedure as described in Figure 4.
Step 2: The P-CSCF 22 decides to subscribe to DC-RAT changes directly from the UE 18.
Step 3: The P-CSCF 22 receives the SIP 200 OK message from the remote end as described in step 19, Figure 4 and sends the SIP 200 OK message with a DC-RAT Reporting Indication to the UE 18.
Step 4: The UE 18 installs a trigger on DC-RAT change. Due to handover, MeNB 12 decisions or other circumstances, the UE 18 changes the DC-RAT.
Step 5: The UE 18 recognizes the DC-RAT change and notifies the P-CSCF 22 with a SIP OPTIONS message and the DC-RAT indication.
Step 6: The P-CSCF 22 may verify the information from the UE 18 with the NPLI from the PCRF 24, if available and may adjust the charging accordingly.
Step 7: The P-CSCF 22 acknowledges the notification with a SIP 200 OK message.

3. Embodiment purely based on P-CSCF and UE control
Option 3: Reactive approach with UE based policy enforcement
Figure 7 illustrates an exemplary DC-POLICY execution in the UE 18.
Step 1: The UE 18 performs the Dedicated Bearer Setup/IMS Session setup procedure as described in TS 23.401 [see, NPL 3]. There is no special DC treatment during the setup.
Step 2: The P-CSCF 22 selects a DC-POLICY indication for the service for the UE 18. The DC-POLICY indication may be stored in an attached database or configured in the P-CSCF 22 and based on the session description in the INVITE message, e.g. the SDP, and may have a preferred DC-RAT for a requested service, e.g. voice over LTE, video over NR. The UE 18 uses this DC-POLICY indication to accept/reject requests from the MeNB 12 to move bearers with the matching service of the policy to the SRN 14.
Step 3: The P-CSCF 22 receives the SIP 200 OK message from the remote end (answer to original SIP INVITE message from the UE 18) and sends the SIP 200 OK message with a DC-POLICY indication to the UE 18 and the UE 18 installs policy for DC-RAT change
Step 4: The MeNB 12 decides to move the bearer to the SRN 14.
Step 5: The MeNB 12 sends the RRC Connection Reconfiguration message to the UE 18 including the new radio resource configuration of Secondary Cell Group (SCG) according to the SCG-Config.
Step 6: The UE 18 validates the new radio resource configuration from the MeNB 12 for the SRN DC-RAT with the DC-POLICY indication. In this case, the UE 18 decides not to apply DC.
Step 7: The UE 18 does not apply the new configuration and may reply with RRC Connection Reconfiguration Complete message including a “No DC” indication, or start the reconfiguration failure procedure and may initiate the connection re-establishment procedure with “No DC” indication.
Step 8: The MeNB 12 does not use the SRN 14 for this bearer for the UE 18 anymore.

Policy control rule function (PCRF)
Figure 8 is a block diagram illustrating the main components of the PCRF 24. As shown, the PCRF 24 includes transceiver circuit 34 which is operable to transmit signals to and to receive signals from the connected node(s) via a network interface 36 (e.g. Gx and Rx). A controller 38 controls the operation of the transceiver circuit 34 in accordance with software stored in a memory 40. The software includes, among other things, an operating system 42 and a communications control module 44 having at least a transceiver control module 46. In the example shown in Figure 4, the communications control module 44 is operable to control the generation of the policy and charging rules provision. The communications control module 44 is responsible for signaling, to the PGW 26, the policy and charging rules provision based on the reception of the indication of IP-CAN session Establishment. In the example shown in Figure 4, the communications control module 44 is operable to receive the AAR message with the DC-RAT indication and to select a DC-POLICY indication used for the dedicated bearer setup. The PCRF 24 provides updated DC-RAT indication to the P-CSCF 22 once the resource indicated by the updated DC-RAT indication became available, either based on subscription by the P-CSCF 22 or by request from the P-CSCF 22. The DC-RAT indication reporting may be independent to other location information reporting, e.g. NPLI.

Proxy call session control function (P-CSCF)
Figure 9 is a block diagram illustrating the main components of the P-CSCF 22. As shown, the P-CSCF 22 includes a transceiver circuit 48 which is operable to transmit signals to and to receive signals from the connected node(s) via a network interface 50 (e.g. Rx, Gm, Mw). A controller 52 controls the operation of the transceiver circuit 48 in accordance with software stored in a memory 54. The software includes, among other things, an operating system 56 and a communications control module 58 having at least a transceiver control module 60. In the example shown in Figure 4, the communications control module 60 is operable to control the generation of the Rx request. The communications control module 58 is responsible for signaling, to the PCRF 24, the Rx request message with the DC-RAT indication of the UE 18 and for receiving an answer. The communications control module 58 is operable to retrieve DC-RAT indication and to compare the DC-RAT indication with the charging rule in order to enable fine granular charging based on the DC-RAT indication. The communications control module 58 is operable to control the generation of the SIP REGISTER request message (or 200 OK or any other SIP message) which includes the DC-RAT indication.

The communications control module 58 is operable to subscribe to updates of DC-RAT changes with a SIP SUBSCRIBE message with a DC-RAT Reporting Event Package to the UE 18. The UE 18 will notify DC-RAT changes with a SIP NOTIFY to the P-CSCF 22 and the communications control module 58 is operable to retrieve DC-RAT indication and to update the fine granular charging rule accordingly.

Alternatively, the communications control module 58 is operable to subscribe to updates of DC-RAT changes in the SIP 200 OK message with a DC-RAT Reporting Indication to the UE 18. The UE 18 will notify DC-RAT changes with a SIP OPTIONS to the P-CSCF 22 and the communications control module 58 is operable to retrieve DC-RAT indication and to update the fine granular charging rule accordingly.

Alternatively, the communications control module 58 is operable to generate a DC-POLICY indication for the service for the UE 18 at the time of the session setup, e.g. SIP INVITE message arrival. The UE 18 uses this DC-POLICY indication to accept/reject requests from the MeNB 12 to move bearers to the SRN 14.

Master base station (MeNB)
Figure 10 is a block diagram illustrating the main components of the MeNB 12. As shown, the MeNB 12 includes a transceiver circuit 62 which is operable to transmit signals to and to receive signals from the connected node(s) via a network interface 64 (e.g. S1). A controller 66 controls the operation of the transceiver circuit 62 in accordance with a software stored in a memory 68. The software includes, among other things, an operating system 70 and a communications control module 72 having at least a transceiver control module 74. In the example shown in Figure 4, the communications control module 72 is operable to control the authorization of the Bearer Setup Request message, to select the appropriate SRN RAT for DC and to establish a radio bearer between the MeNB 12 and the UE 18. The memory 68 is operable to store the DC-POLICY indication. In the example shown in Figure 4, the communications control module 72 is operable to indicate the DC-RAT selected for the bearer in the response message to the SGW 28.

Summary
Beneficially, the above described example embodiments include, although they are not limited to, one or more of the following functionalities.
1) Applying of fine granular charging in the P-CSCF 22 in dependency of the selected DC-RAT of the MeNB 12 based on a DC-POLICY indication provided by the PCRF 24, taking input from the UE/P-CSCF/PGW 18/22/26 into account.
2) Updating the DC-RAT during the active IMS session with SIP SUBSCRIBE/NOTIFY message or SIP OPTIONS message from the UE 18.

It can be seen that the above example embodiments describe a method comprising:
1) Provisioning of a DC-RAT to the P-CSCF 22 at IMS Session establishment
2) Interaction between the P-CSCF 22 and the PCRF 24 for generating a DC-POLICY indication
3) Provisioning of the DC-POLICY indication to the MeNB 12 in the dedicated bearer setup signaling in order to assist the MeNB 12 to apply the policy accordingly and to assign a DC-RAT for the bearer.
4) Indication of the assigned RAT type to the P-CSCF 22 in the setup response message
5) Applying of fine granular charging in the P-CSCF 22 in dependency of the selected DC-RAT
6) Update of the DC-RAT during the active IMS session with the SIP SUBSCRIBE/NOTIFY or SIP OPTIONS message
7) Optionally, provision of DC-POLICY indication to the UE 18 in the IMS Session setup, and relying on the UE 18 to reject RRC Connection Reconfigurations from the MeNB 12 to a SRN not compliant to the policy.

Benefits
It can be seen that the above example embodiments provide a number of benefits, including (but not limited to) enabling fine granular charging based on the actual used radio access for dual connectivity.

Modifications and Alternatives
Detailed example embodiments have been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above example embodiments whilst still benefiting from the inventions embodied therein. By way of illustration only a number of these alternatives and modifications will now be described.

In the above description, the PCRF 24, the P-CSCF 22, and the MeNB 12 are described for ease of understanding as having a number of discrete modules (such as the communication control modules). Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the invention, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities. These modules may also be implemented in software, hardware, firmware or a mix of these.

Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input/output (IO) circuits; internal memories / caches (program and/or data); processing registers; communication buses (e.g. control, data and/or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and/or timers; and/or the like.

In the above example embodiments, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the PCRF 24, the P-CSCF 22, and the MeNB 12 as a signal over a computer network, or on a recording medium. Further, the functionality performed by part or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the PCRF 24, the P-CSCF 22, and the MeNB 12 in order to update their functionalities.

Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

<List of abbreviations>
3PSP: 3rd Party Service Provider
AAA: Authentication Authorization Answer
AAR: Authentication Authorization Request
AF: Application Function
API: Application Programming Interface
AS: Application Server
AuC: Authentication Center
CPE: Control Plane Entity
DC: Dual Connectivity
eNB: Evolved NodeB
GGSN: Gateway GPRS Support Node
GPRS: General Packet Radio Service
HLR: Home Location Register
HO: Handover
HSS: Home Subscriber Server
IMS: IP Multimedia Subsystem
IMSI: International Mobile Subscriber Identifier
IP: Internet Protocol
IWF: Interworking Function
LAI: Location Area Identifier
LAU: Location Area Update
LTE: Long Term Evolution
MeNB: Master eNB
MGW: Media Gateway
MME: Mobility Management Entity
MSC: Mobile Switching Centre
MSC-S: MSC-Server
MTC: Machine Type Communication
NAS: Non Access Stratum
NG: Next Generation
NG-CP: NG Core Control Plane functions
NG-UP: NG Core User Plane functions
NR BS: New Radio Base Station
NW: Network
P-CSCF: Proxy Call Session Control Function
PCEF: Policy Control Enforcement Function
PCRF: Policy Control Rule Function
PDN: Packet Data Network
PGW: PDN Gateway
PLMN: Public Land Mobile Network
QoS: Quality of Service
RAA: Re-Authentication-Answer
RAE: Radio Access Entity
RAR: Re-Authentication-Request
RRC: Radio Resource Control
SCEF: Service Capability Exposure Function
SCS: Service Capability Server
SeNB: Secondary eNB, used here as SRN also to cover other RATs than LTE
SGSN: Serving GPRS Support Node
SGW: Serving Gateway
SP: Service Provider
SPR: Subscriber Profile Repository
SRN: Secondary Radio Node, a SeNB with one or more RATs
SSS: Slice Security Server
TDF: Traffic detection Function
TE: Terminal
UDM: NG User Data Management
UE: User Equipment
UPE: User Plane Entity
URI: Uniform Resource Identifier
WT: WLAN Termination

This application is based upon and claims the benefit of priority from European Patent application No. EP16185223.1, filed on August 22, 2016, the disclosure of which is incorporated herein in its entirety by reference.

Claims

An access network node comprising:
a receiver configured to receive an information from a core network node for restricting the access network node to configure dual connectivity with a New Radio (NR) for a User Equipment (UE); and
at least one processor configured to process to determine whether the dual connectivity with the NR as secondary radio access technology is configured or not based on the information.
The access network node according to claim 1, wherein
the information is based on information from a subscriber information management apparatus.
A communication method of an access network node, comprising:
receiving an information from a core network node for restricting the access network node to configure dual connectivity with a New Radio (NR) for a User Equipment (UE); and
determining whether the dual connectivity with the NR as secondary radio access technology is configured or not based on the information.
A communication system comprising:
a core network node; and
an access network node, wherein
the core network node is configured to transmit an information to the access network node for restricting the access network node to configure dual connectivity with a New Radio (NR) for a User Equipment (UE), and
the access network node is configured to:
receive the information, and
determine whether the dual connectivity with the NR as secondary radio access technology is configured or not based on the information.
A communication method of a communication system, comprising:
generating an information to an access network node in the communication system for restricting the access network node to configure dual connectivity with a New Radio (NR) for a User Equipment (UE), and
determining whether the dual connectivity with the NR as secondary radio access technology is configured or not based on the information.