Embodiments herein relate generally to a network node and a method performed by the network node. More particularly the embodiments herein relate to handling a subscription to a service in a communications network.
A subscriber may have one, two or multiple subscriptions to a communications network, i.e. subscriptions to services provided by the service provider of the communications network. Each subscription is identified with a unique subscription identity. The Mobile Station International Integrated Services Digital Network (ISDN) Number (MSISDN) is an example of such unique subscription identity. The subscription identity may also be referred to as a phone number or a mobile number.
A customer management system is a system which handles subscriptions, billing, accounts etc. in relation to services provided the service provider in his communications system.
In a charging system, multiple SDPs 115 may be used to balance load segmentation of customer data over several SDPs 115. The charging system may be different from the billing system. The charging system and the billing system may be standalone systems or they may be co-located. When contract data has to be retrieved from the SDP 115 or contract data has to be provided to the SDP 115, the corresponding request is addressed to one of the AIRs 113. In order to execute the request, the AIR 113 has to find the ID of the SDP instance where the contract is handled. To enable this, the AF 108 has been implemented as a DNS service that runs on an AIR network element. The AF's 108 main function is to supply the AIRs 113 with the IDs for SDP 115. The AF 108 can map a single MSISDNs or MSISDN ranges to SDP identifiers. It stores the SDP per MSISDN where the respective contract is located to allow the AIR 115 and CCN to look up the SDP 115 for a given MSISDN.
For the maintenance and retrieval of subscriptions in the charging system, some data has to be provided to or obtained from the charging system network elements instead of storing the data in the customer management system 100. The customer management system 100 is responsible for data distribution. For the process of providing and obtaining data from and to the billing database 120, the MA adapter 103, is comprised in the customer management system 100. The MA adapter 103 is responsible for the communication and connection to Multi Activation interface or CA/3G interface.
An orchestration layer of the customer management system 100 provides the distribution of the data to the MA adapter 103. In case data has provided to the billing database 120, the appropriate business action is triggered in the customer management system 100 which is forwarded to the orchestration layer. The orchestration layer again calls an appropriate action of the MA adapter 103. Finally, the MA adapter 103 distributes the data to MA 110 and the billing database 120. Response data from the billing database 120 and the MA 110 is forwarded from the MA 110 through the MA adapter 103 and the orchestration layer to the business logic layer. In case data has to be read from the MA 110 and the billing database 120 for display purposes only, the business logic layer directly triggers an appropriate action of the MA adapter 103.
In the charging system, account data are stored on and obtained from the SDP 115 using the AIR 113 element. For this reason, all requests for account information and any changes to accounts that originate from the customer management system 100 must go through the AIR 113. The AIR adapter 105 provides a mapping interface between the customer management system 100 and the AIR 113 element.
Business actions in the customer management system 100, for example the creation of a new contract or a request for contract information, are mapped to AIR services. Entities in the customer management system 100, for example contract identifiers, are mapped to entities required by the AIR 113 services. Data, for example monetary amount values, is mapped to the required format. If business actions are being executed as part of a batch, the actions can be executed in parallel. In this case, the customer management system 100 and the AIR adapter 105 work in several threads, with each thread having its own connection to the AIR application.
The AF 108 is a Domain Name Server (DNS) service that runs on an AIR 113 element. The AF's 108 main function is to supply the AIR 113 with the IDs for the SDP 115. The AF 108 can map a single MSISDNs or MSISDN ranges to SDP identifiers. The AF 108 stores the SDP 115 per MSISDN where the respective contract is located to allow the AIR 113 and the CCN to look up the SDP 115 for a given MSISDN.
The MA 110 may be referred to as an MA interface or a CA/3G interface and is adapted to provide and obtain data from the billing database 120.
In the charging system, account data are stored on and obtained from the SDP 115 using the AIR 113 element.
The charging system includes one or more SDPs 115 that performs online rating and balance management for calls and events of prepaid and post-paid contracts, known as subscriptions in the charging system.
The assignment of contracts to the SDP 115 is stored in the AF 108.
The batch execution engine 118 is adapted to carry out batch jobs that are used to change specific contract data of many charging system contracts at the same time and to create pre activated-prepaid charging system contracts. The batch jobs are initiated in Configuration Management (ADMX).
Currently, it is possible for the service provider to reassign the MSIDN of a deactivated subscription identity to a new subscriber as depicted in the MSISDN life cycle diagram in
A MSISDN is generated by an operator node. The generated MSISDN may be referred to as a new MSISDN after it has been generated and during the first time it is assigned to a subscriber's subscription.
The generated MSISDN is in a free state. When the MSISDN is in a free state, it is not associated to any subscription.
The MSISDN is assigned to a subscriber's subscription to the communications network.
When the MSISN has been assigned to the subscription, then the MSISDN is in a reserved state. The MSISDN cannot be assigned to other subscriptions when the MSISDN is in the reserved state.
The MSISDN is deactivated.
The MSISDN is in a quarantine period when it has been deactivated. The MSISDN cannot be assigned to another subscription when it is in the quarantine period. The quarantine period may be any suitable period, for example between ½-12 months, between 1-8 months, between 2-6 months, it may be 3 months, 4 months etc.
The MSISDN goes back to the free state after the quarantine period has expired. When it has entered the free state, it can be assigned to another subscription. After the MSISDN has gone back to free state, the MSISDN may be referred to as an old MSISDN. When the MSISDN is again in a free state, it may be reassigned to a subscription again.
When a new subscriber's subscription is assigned with an old MSISDN, the subscriber might get unwanted calls or messages from the existing contacts of the old subscriber. These unwanted communications from the old subscriber's contacts annoy the new subscriber and result in a bad user experience and eventually result in opportunity loss for the service provider.
When the subscription identity gets deactivated and reassigned to another subscriber's subscription, the frequent calls and messages from the close contacts of the previous subscriber might annoy the new subscriber receiving the calls. This might bring down the user experience of the new subscriber who is in danger of churning out from the network.
Reusing the MSISDN is unavoidable which results in the problems described above. Hence it is necessary to handle the problems associated with such number reallocations for better user experience.
Therefore, there is a need to at least mitigate or solve this issue.
An objective of embodiments herein is therefore to obviate at least one of the above disadvantages and to provide improved handling of subscriptions to service in a communications network.
According to a first aspect, the object is achieved by a method performed by a network node for handling a subscription to service in a communications network. The network node detects that a subscriber's subscription has been deactivated from the communications network. The network node obtains data related to usage of the service. The network node analyzes the data to determine one or more contacts of the subscriber that should be notified about the deactivated subscription. The network node initiates one or more notifications to the determined one or more contacts about the deactivated subscription.
According to a second aspect, the object is achieved by a network node adapted to detect that a subscriber's subscription to a service has been deactivated from a communications network. The network node is adapted to obtain data related to usage of the service. The network node is adapted to analyze the data to determine one or more contacts of the subscriber that should be notified about the deactivated subscription. The network node is adapted to initiate one or more notifications to the determined one or more contacts about the deactivated subscription.
Thanks to the analysis of the data, contacts of the subscriber can be notified when the subscription has been deactivated, which improves the handling of subscriptions to service in the communications network.
Embodiments herein afford many advantages, of which a non-exhaustive list of examples follows:
An advantage of the embodiments herein is that they provide improved user experience by avoiding unwanted communication from contacts of the old subscriber.
Another advantage of the embodiments herein is that they are easily adaptable with any system and is feasible to implement.
Reusing the subscriber identity is unavoidable. Hence it an advantage of the embodiments herein to improve the reuse of the subscriber identities in order to obtain a better user experience.
The embodiments herein are not limited to the features and advantages mentioned above. A person skilled in the art will recognize additional features and advantages upon reading the following detailed description.
The embodiments herein will now be further described in more detail by way of example only in the following detailed description by reference to the appended drawings illustrating the embodiments and in which:
The drawings are not necessarily to scale and the dimensions of certain features may have been exaggerated for the sake of clarity. Emphasis is instead placed upon illustrating the principle of the embodiments herein.
A UE, e.g. a subscriber UE 303 and/or the contact UE 305 may be a device by which a subscriber may access services offered by an operator's network and services outside operator's network to which the operator's radio access network and core network provide access, e.g. access to the Internet. The UE may be any device, mobile or stationary, enabled to communicate over a radio channel in the communications network, for instance but not limited to e.g. user equipment, mobile phone, smart phone, sensors, meters, vehicles, household appliances, medical appliances, media players, cameras, Machine to Machine (M2M) device, Internet of Things (IOT) device, terminal device, communication device or any type of consumer electronic, for instance but not limited to television, radio, lighting arrangements, tablet computer, laptop or Personal Computer (PC). The UE may be portable, pocket storable, hand held, computer comprised, or vehicle mounted devices, enabled to communicate voice and/or data, via the radio access network, with another entity, such as another UE or a server.
The network node 300 is adapted to be connected to a database 308. The database 308 may be the billing database 120 exemplified in
A subscription associated with the subscriber UE 303 is deactivated. This may also be referred to as the subscription identity associated with the subscription is deactivated. The deactivation may be due to that the subscriber has ended the subscription, that the subscriber has not paid the cost for the subscription etc. When the subscription is deactivated, the subscription identity is no longer used by the subscriber. The subscriber UE 303 may notify the network node 300 about the deactivated subscription.
The network node 300 detects the deactivation of the subscription. The network node 300 comprises information about subscriptions that are going to be deactivated. The internal scheduler or e.g. a Batch Execution engine may trigger a new action with a specific code for deactivation. The network node may receive that request and identify the deactivation event.
When the network node 300 has detected the deactivation, it sends, to the database 308, a request for data related to usage of the service which has been used with the subscription. The usage may be associated with the one or more contact UEs 303.
The database 308 sends the requested data to the network node 300. The data may be a list of contacts of the subscriber, i.e. contacts which the subscriber has communicated with using the service provided by the communications network. For example, it may be list of phone numbers, email addresses etc. to contacts of the subscriber.
The network node 300 analyzes the data from the database 308 and determines one or more contacts that should be notified about the deactivation.
The network node 300 initiates notification of the deactivated subscription to the determined one or more contacts.
The one or more contacts receive notifications about the deactivated subscription. The notification may be for example a SMS, MMS etc.
The contact UE 303 may remove the subscription identity associated with the deactivated subscription from their contact lists. The contact UE 303 may also send, to the network node 300, a response confirming that the subscription identity has been removed.
The SDH 500 is adapted to notify the frequent contact list in their preferred notification channel when the subscription identity is deactivated from the communications network. Some examples of functionalities of the components in the SDH 500 will be provided when describing
Some functionalities of the SDH 500 are given below and described in the form of a method performed by the SDH 500:
When the subscription identity deactivation event has been sent to the SDH 500, the SDH 500 may request information about past periods, e.g. 3 months, subscriber Call Detail Records (CDR) from the database 308. The past period may be configurable. It may be the he Call Record Handler 501 that requests the past periods from the database 308.
The Batch Execution Engine 118 may trigger sending of the subscription identify deactivation event based on the subscriber life cycle end date.
The database 308 sends the requested CDR to the SDH 500.
The SDH 500 analyses the CDR in order to determine which contacts of the subscriber that should be notified about the deactivation. The analysis may involve use of a learning model to process the CDRs and creates a directed graph connecting the subscription identity and frequent contacts. It may be the Call Record Analyzer 503 of the SDH 500 that performs step 603.
The SDH 500 invokes the frequent contact list by communicating with an external Notification Handler 507 to notify the subscriber's contacts according to their notification preference. It may be the notification execution engine 505 comprised in the SDH 500 that performs step 604.
The contacts may provide a response to the SDH 500 indicating that they have removed the subscriber identify from their contact lists.
The analysis of the data will now be described in more detail. In this example the data is exemplified by a CDR and where the used service is a call. However, the below example is equally applicable to the data in any other suitable format and to any other service type. The following example uses the last 3 months CDR data for the subscriber Ted whose subscription identity is deactivated. Learning models may be used when analyzing the CDR which gives out a relationship matrix for the subscriber. A relationship matrix illustrates the relationship between parameters, i.e. between the contacts and e.g. the frequency of call and elapsed time. The relationship matrix gives the score for the various parameters based on which the subscriber is connected to his close contacts. It may be seen as a correlation between the various parameters which will further lead to a statistical relationship between a subscriber and his contacts. The relationship matrix may further lead to a directional graph which may show the density of the connection between the subscription and his connected contact. The higher the density of the connection, the better it is to choose the contact to be notified.
A directional graph may also be referred to as a weighted directional graph or a digraph. A directional graph is a set of vertices connected by edges. The edges have a direction associated with them. Weights are assigned to the edges in a weighted directional graph. The vertices may be represented by the contacts, and the direction represents the way of communication between the contacts and Ted.
In the example shown below, the density is mapped to a scale of 1-10, where a value of >=5 shows the higher connection with the contact and vice versa.
At least one of the following input parameters may be input to the network node 300 when analyzing the CDR:
Let's take an example of a subscriber Ted who's MSISDN is 98XXXXXXXX. After analysis of the above four parameters, the frequent contacts of Ted are four subscribers whose relationship matrix is given in
The method described above will now be described seen from the perspective of the network node 300.
This step corresponds to step 401 in
This step corresponds to steps 402 and 403 in
The obtained data may be associated with a time period. The time period may be for example x number of days prior to the deactivation of the subscription, y number of weeks prior to the deactivation of the subscription, z number of months prior to the deactivation of the subscription etc. x, y and z are any positive integers.
The obtained data may indicate a usage frequency to and/or from contacts. The usage frequency may indicate the frequency of usage of the service which has taken place between the subscriber and his contacts. The frequency may be represented by a % of the used service with each of the contacts.
The obtained data may indicate a usage duration of service usage between the subscription identity and the contacts. The usage duration may indicate the duration of the used service. The usage duration may be an average usage duration of all services which has taken place between the subscriber and each of the contacts. The duration may be for example in seconds, minutes, hours. The usage duration may be in the obtained data when the service is for example a voice call or a video call.
The obtained data may comprise at least one of:
The identity of the contact may be represented by a subscription identity of the contact, e.g. a MSISDN.
The obtained data may be a CDR.
The data may be obtained from a database 308.
This step corresponds to step 404 in
The analysis of the data may comprise creating a graph representing a connection between the subscription identity and the contact. The graph may be a directional graph or a weighted directional graph, for example as shown in
The graph may show a density of a connection between the subscription identity and the contact.
The determined one or more contacts to be notified may be contacts associated with a usage frequency that is above a frequency threshold. The frequency threshold is related to the frequency of the used service between the subscriber and the contacts.
The determined one or more contacts to be notified may be contacts associated with a usage duration that is above a duration threshold. The duration threshold is related to the duration of the used service between the subscriber and the contacts.
The determined one or more contacts to be notified may be one or more contacts associated with values in the graph that are larger than a graph threshold.
This step corresponds to step 405 in
The subscription identity may be a MSISDN and may be comprised in the notification to the one or more contacts.
The determined one or more contacts may be notified via SMS, and/or email and/or IVR, or any other suitable notification type.
In
The network node is adapted to, e.g. by means of the processor 1001, detect that a subscriber's subscription to a service has been deactivated from a communications network. The service may be for example a voice call, a SMS, a MMS, a video call etc.
The network node is adapted to, e.g. by means of the interface 1003, obtain data related to usage of the service. The usage may be usage of the service used by the subscriber which has a subscription to the service.
The obtained data may be associated with a time period. The time period may be for example x number of days prior to the deactivation of the subscription, y number of weeks prior to the deactivation of the subscription, z number of months prior to the deactivation of the subscription etc. x, y and z are any positive integers.
The obtained data may indicate a usage frequency to and/or from contacts.
The obtained data may indicate a usage duration of service usage between the subscription identity and the contacts.
The data may be obtained from a database 308.
The obtained data may be a CDR.
The usage may be usage of the service used by the subscriber. The obtained data may comprise at least one of:
The identity of the contact may be represented by a subscription identity of the contact, e.g. a MSISDN.
The network node is adapted to, e.g. by means of the processor 1001, analyze the data to determine one or more contacts of the subscriber that should be notified about the deactivated subscription.
The network node may be adapted to, e.g. by means of the processor 1001, create a graph representing a connection between the subscription identity and the contact. The graph may be a weighted directional graph. The graph may show a density of a connection between the subscription identity and the contact.
The network node is adapted to, e.g. by means of the processor 1001, initiate one or more notifications to the determined one or more contacts about the deactivated subscription. The determined one or more contacts to be notified may be contacts associated with a usage frequency that is above a frequency threshold. The determined one or more contacts to be notified may be contacts associated with a usage duration that is above a duration threshold. The one or more contacts to be notified may be one or more contacts associated with values in the graph that are larger than a graph threshold. The subscription identity may be a MSISDN and may be comprised in the notification to the one or more contacts.
The network node may be adapted to, e.g. by means of the processor 1001, initiate the one or more notifications to the determined one or more contacts via SMS and/or email and/or IVR.
The present mechanism for handling a subscription to service in a communications network may be implemented through one or more processors, such as a processor in the network node 300 together with computer program code for performing the functions of the embodiments herein. The processor may be for example a Digital Signal Processor (DSP), Application Specific Integrated Circuit (ASIC) processor, Field-programmable gate array (FPGA) processor or microprocessor. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the network node 300. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code can furthermore be provided as pure program code on a server and downloaded to the network node 300.
A computer program may comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method described above. A carrier may comprise the computer program, and the carrier may be one of an electronic signal, optical signal, radio signal or computer readable storage medium.
Summarized, the embodiments herein relate to handling of subscription identity deactivation when the deactivation request is being received from the billing system. The frequent contacts of the deactivated subscriber are notified so that they can remove the subscription identity from their own contact list.
Reusing the subscription identity is unavoidable and at the same time, providing a better user experience to the new subscriber which reuses the subscription identity is very critical, and hence it is very important to handle the problems associated with such reused number which is achieved herein.
The embodiments herein are not limited to the above described embodiments. Various alternatives, modifications and equivalents may be used. Therefore, the above embodiments should not be taken as limiting the scope of the embodiments, which is defined by the appended claims. A feature from one embodiment may be combined with one or more features of any other embodiment.
The term “at least one of A and B” should be understood to mean “only A, only B, or both A and B.”, where A and B are any parameter, number, indication used herein etc.
It should be emphasized that the term “comprises/comprising” when used in this specification is taken to specify the presence of stated features, integers, steps or components, but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof. It should also be noted that the words “a” or “an” preceding an element do not exclude the presence of a plurality of such elements.
The term “configured to” used herein may also be referred to as “arranged to”, “adapted to”, “capable of” or “operative to”.
It should also be emphasised that the steps of the methods defined in the appended claims may, without departing from the embodiments herein, be performed in another order than the order in which they appear in the claims.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/IN2019/050004 | 1/3/2019 | WO | 00 |