NEW GRANULARITY FOR IoT DATA TRANSFER FOR ANALYTICS

Abstract

It is provided a method, comprising monitoring if one of an input payload for a subscription and an output payload from the subscription is delivered; incrementing a payload counter by if one of the input payload and the output payload is delivered; providing the payload counter and an identifier of the subscription to a charging system at at least one of a predefined time and a predefined event.

Claims

1.-22. (canceled)

23. An apparatus comprising: at least one processor; and at least one memory including computer program code, where the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to at least: monitor if one of an input payload for a subscription and an output payload from the subscription is delivered; increment a payload counter by 1 if one of the input payload and the output payload is delivered; and provide the payload counter and an identifier of the subscription to a charging system at at least one of a predefined time and a predefined event.

24. The apparatus of claim 23, wherein the payload counter comprises an input payload counter and an output payload counter; the input payload counter is incremented by 1 if the input payload for the subscription is delivered; and the output payload counter is incremented by 1 if the output payload from the subscription is delivered.

25. An apparatus comprising: at least one processor; and at least one memory including computer program code where the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to at least: monitor if a value of a payload counter and a related identifier of a subscription are received, wherein the payload counter indicates a number of times at which one of an input payload for the subscription and an output payload from the subscription is delivered; and generate charging information related to the subscription based on the payload counter.

26. The apparatus of claim 25, wherein the payload counter comprises an input payload counter and an output payload counter; the input payload counter indicates a number of times the input payload for the subscription is delivered; and the output payload counter indicates the number of times the output payload from the subscription is delivered.

27. The apparatus of claim 25, wherein the at least one memory including the computer program code is configured, with the at least one processor, to cause the apparatus to: check if the value of the payload counter is within a predetermined range; trigger a first activity if the value of the payload counter is not in the predetermined range.

28. The apparatus of claim 25, wherein the value of the payload counter is received related to a time interval, and the at least one memory including the computer program code is configured, with the at least one processor, to cause the apparatus to: calculate a delivery frequency based on the value of the payload counter and the time interval; check if the delivery frequency is within a predetermined range; and trigger a second activity if the delivery frequency is not in the predetermined range.

29. The apparatus of claim 25, wherein plural values of the payload counter are received; each of the plural values is related to a different time interval, and the at least one memory including the computer program code is configured, with the at least one processor, to cause the apparatus to: analyze the plural values with respect to a time behavior; and trigger a third activity if the time behavior shows a predefined pattern.

30. The apparatus of claim 27, wherein the respective one of the first activity, the second activity, and the third activity is at least one of issuing an alarm, and reporting the respective one of the value of the payload counter, the delivery frequency, and the pattern.

31. The apparatus of claim 27, wherein the respective one of the first activity, the second activity, and the third activity is instructing an actor or a control entity of the actor to perform a respective predefined action, wherein the respective predefined action is suitable to modify a future value of the payload counter.

32. A method, comprising: monitoring if one of an input payload for a subscription and an output payload from the subscription is delivered; incrementing a payload counter by 1 if one of the input payload and the output payload is delivered; providing the payload counter and an identifier of the subscription to a charging system at at least one of a predefined time and a predefined event.

33. The method of claim 32, wherein the payload counter comprises an input payload counter and an output payload counter; the input payload counter is incremented by 1 if the input payload for the subscription is delivered; and the output payload counter is incremented by 1 if the output payload from the subscription is delivered.

34. A method, comprising: monitoring if a value of a payload counter and a related identifier of a subscription are received, wherein the payload counter indicates a number of times at which one of an input payload for the subscription and an output payload from the subscription is delivered; generating charging information related to the subscription based on the payload counter.

35. The method of claim 34, wherein the payload counter comprises an input payload counter and an output payload counter; the input payload counter indicates a number of times the input payload for the subscription is delivered; and the output payload counter indicates the number of times the output payload from the subscription is delivered.

36. The method of claim 34, further comprising checking if the value of the payload counter is within a predetermined range; triggering a first activity if the value of the payload counter is not in the predetermined range.

37. The method of claim 34, wherein the value of the payload counter is received related to a time interval, and the method further comprises calculating a delivery frequency based on the value of the payload counter and the time interval; checking if the delivery frequency is within a predetermined range; triggering a second activity if the delivery frequency is not in the predetermined range.

38. The method of claim 34, wherein plural values of the payload counter are received; each of the plural values is related to a different time interval, and the method further comprises analyzing the plural values with respect to a time behavior; triggering a third activity if the time behavior shows a predefined pattern.

39. The method of claim 36, wherein the respective one of the first activity, the second activity, and the third activity is at least one of issuing an alarm, and reporting the respective one of the value of the payload counter, the delivery frequency, and the pattern.

40. The method according to of claim 36, wherein the respective one of the first activity, the second activity, and the third activity is instructing an actor or a control entity of the actor to perform a respective predefined action, wherein the respective predefined action is suitable to modify a future value of the payload counter.

41. A non-transitory computer-readable medium storing program code, the program code executed by at least one processor to perform the method of claim 32.

42. A non-transitory computer-readable medium storing program code, the program code executed by at least one processor to perform the method of claim 34.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Further details, features, objects, and advantages are apparent from the following detailed description of the preferred embodiments of the present invention which is to be taken in conjunction with the appended drawings, wherein:

[0039] FIG. 1a shows a LTE architecture with SCEF;

[0040] FIG. 1b shows a 5G architecture with NEF;

[0041] FIG. 2 shows an apparatus according to an embodiment of the invention;

[0042] FIG. 3 shows a method according to an embodiment of the invention;

[0043] FIG. 4 shows an apparatus according to an embodiment of the invention;

[0044] FIG. 5 shows a method according to an embodiment of the invention;

[0045] FIG. 6 shows an apparatus according to an embodiment of the invention.

[0046] FIG. 7 shows a protocol extension according to an embodiment of the invention;

[0047] FIG. 8 shows a protocol extension according to an embodiment of the invention;

[0048] FIG. 9 shows a protocol extension according to an embodiment of the invention; and

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

[0049] Herein below, certain embodiments of the present invention are described in detail with reference to the accompanying drawings, wherein the features of the embodiments can be freely combined with each other unless otherwise described. However, it is to be expressly understood that the description of certain embodiments is given by way of example only, and that it is by no way intended to be understood as limiting the invention to the disclosed details.

[0050] Moreover, it is to be understood that the apparatus is configured to perform the corresponding method, although in some cases only the apparatus or only the method are described.

[0051] According to some embodiments of the invention, a new count for the measurement and calculation for Non-IP Data Delivery (NIDD) is established. It may be used for the charging model of any small data business, e.g. for the payload of sensors or for application which are not focusing on media. According to these embodiments, the transfer of non-media and small data will be counted and recorded in charging as number of payload deliveries.

[0052] In some embodiments of the invention, the number of deliveries in the access network is counted which would bring a new business option on Mobile IoT (MIoT) in the different areas of Spectrum used for IoT: e.g. LPWA technologies operating in licensed spectrum such as LTE-M, NB-IoT and EC-GSM-IoT, and LPWA technologies operating in in unlicensed radio spectrum as well, such as RPMA, LoRaWAN and Sigfox.

[0053] In some embodiments of the invention, the charging system may evaluate and analyse the payload content itself. However, this needs to be clarified in conjunction with the country specific regulation authority.

[0054] In some embodiments of the invention, this new type of measurement (i.e. number of deliveries) may be taken into account on execution basis for billing purposes and, in addition, for new value added services. For example, one may supervise the number of deliveries via analytics and trigger a corresponding real-time interaction. Thus, operators may collect data which enrich the enterprise business model, potentially even without inspecting the payload itself.

[0055] Such application may be favourably implemented in an OCS, due to the real-time characteristics of the CDR data transfer from the network elements to the OCS. However, if the delays due to the CDR data transfer to OFCS are acceptable, such application may be implemented in OFCS, too.

[0056] The analytics of the deliveries may be based on at least one of the number of deliveries, a frequency of the deliveries (e.g. compared to the average frequency), and a time behaviour of the deliveries (e.g. compared with an expected time behaviour within a dedicated timeframe).

[0057] For example, if the number or the frequency of deliveries is outside a predetermined range (e.g. exceeds a certain value), an activity may be triggered. Such an activity may be reporting the value and/or issuing an alarm.

[0058] In some embodiments, the activity may be suitable to influence the number of deliveries. That is, some embodiments of the invention actively control the environment of the IoT device and/or the IoT device itself.

[0059] Some example use cases are as follows:

[0060] Traffic: a traffic sensor (IoT device) may detect bridge usage and report each time if a frequency of cars (or of trucks only) exceeds a certain value. If such message is sent, the application may limit the number of cars (trucks) on the bridge by adapting corresponding traffic signs.

[0061] Correspondingly, based on the number of received payloads from another traffic sensor being an IoT device, the number of lanes released per direction may be controlled.

[0062] As a still further example, parking slots may be managed based on the number of deliveries from sensors (IoT devices) reporting if a status of a parking slot is changed (from occupied to free and/or vice versa)

[0063] Sensors: The IoT device may be a temperature sensor reporting only if the temperature is outside a predefined range, e.g. above a certain limit. In case of such a delivery, the application according to some embodiments of the invention may instruct a cooling device to cool the environment of the temperature sensor.

[0064] In another example, the IoT device may be a temperature sensor supervising the heaters and/or air-condition of a house. If it is detected that the outdoor temperature is outside a predefined range (e.g. below a limit), it is expected that the heater and/or air condition starts to operate within a predefined time frame, which may be reported by an inner-circle report. If such inner-circle report is missing within the predetermined time frame and the temperature is reported to be outside the predefined range, an alarm may be generated. Correspondingly, if the IoT device is a liquid filling sensor reporting only if the filling level is outside a predefined range, the application may, based on the number of deliveries, instruct a control device to open or close some valves, to start or to stop a pump, etc.

[0065] As a still further example according to some embodiments of the invention, a network operator may provide the NIDD (Non-IP data delivery) for a rental car company renting cars of certain types. The rental car operator may offer analytics option to the car vendors to get a better rent. In addition to the communication service provided by the operator to the rental car company, the operator may offer the collected payload analytics (e.g. based on deliveries) for the differentiation of the brand of the rental car company while relieving the rental car company from the effort for analytics. A typical benefit of the rental company in respect of customer experience could be the compare of gas consumption between the car vendors to improve the environment by a preference on environmentally friendly cars.

[0066] FIG. 2 shows an apparatus according to an embodiment of the invention. The apparatus may be a gateway such as a PGW, a SCEF, a NEF, or a SMF or an element thereof. FIG. 3 shows a method according to an embodiment of the invention. The apparatus according to FIG. 2 may perform the method of FIG. 3 but is not limited to this method. The method of FIG. 3 may be performed by the apparatus of FIG. 2 but is not limited to being performed by this apparatus.

[0067] The apparatus comprises monitoring means 10, incrementing means 20, and providing means 30. The monitoring means 10, incrementing means 20, and providing means 30 may be monitoring processor, incrementing processor, and providing processor, respectively.

[0068] The monitoring means 10 monitors if one of an input payload for a subscription and an output payload from the subscription is delivered (S10).

[0069] If one of the input payload and the output payload is delivered (S10=“yes”), the incrementing means increments a payload counter by 1. The payload counter may comprise two (sub-)counters, one for input payload and one for output payload. In this case, the respective one of the (sub-) counters is incremented if an input payload or an output payload is delivered. If both an input payload and an output payload are delivered, the payload counter is incremented by 2 (each of the (sub-)counters by 1, if applicable).

[0070] The providing means 30 provides the payload counter and an identifier of the subscription to a charging system at at least one of a predefined time (e.g. periodically) and a predefined event (e.g. upon request) (S30).

[0071] FIG. 4 shows an apparatus according to an embodiment of the invention. The apparatus may be a charging system such as a OCS or OFCS, or an element thereof. FIG. 5 shows a method according to an embodiment of the invention. The apparatus according to FIG. 4 may perform the method of FIG. 5 but is not limited to this method. The method of FIG. 5 may be performed by the apparatus of FIG. 4 but is not limited to being performed by this apparatus.

[0072] The apparatus comprises monitoring means 110 and generating means 120. The monitoring means 110 and generating means 120 may be monitoring processor and generating processor, respectively.

[0073] In addition, the apparatus may comprise analyzing means 130 and triggering means 140. The analyzing means 130 and triggering means 140 may be analyzing processor and triggering processor, respectively. These means and the corresponding S130 and S140 are shown by dashed lines because they are optional.

[0074] The monitoring means 110 monitors if a value of a payload counter and a related identifier of a subscription are received (S110). The payload counter indicates a number of times at which one of an input payload for the subscription and an output payload from the subscription is delivered.

[0075] Based on the payload counter received in S110, the generating means 120 generates charging information related to the subscription (S120).

[0076] If available, the analyzing means 130 may analyze the payload counter (S130). E.g., the analyzing means may analyze each value of the payload counter separately, and/or it may comprise a sequence of received payload counters for the device. As a result of the analysis, the analysis means may decide if the payload counter or the sequence of payload counter values fulfills a respective predefined condition (e.g. payload counter outside a predefined range, or sequence of payload counter values shows predetermined pattern).

[0077] Based on the analysis result, the triggering means 140 may trigger a respective predefined activity (S140), such as reporting the value of the payload counter or issuing an alarm. In some embodiments of the invention, the triggering means 140 may trigger an action suitable to influence a future value of the payload counter.

[0078] FIG. 6 shows an apparatus according to an embodiment of the invention. The apparatus comprises at least one processor 610, at least one memory 620 including computer program code, and the at least one processor 610, with the at least one memory 620 and the computer program code, being arranged to cause the apparatus to at least perform at least one of the methods according to FIGS. 3 and 5.

[0079] The following technical specifications in 3GPP are related to the extension of the measurement from data traffic to payload deliveries.

[0080] 3GPP TS 23.401 “EPC Network Architecture” is the overall architecture specification and the primary reference for the trigger of charging functions for Offline and Online Charging for data traffic in the Charging model.

[0081] The evolution of the EPC network architecture for Non-IP Data Delivery (NIDD) with the SCEF is specified in 3GPP TS 23.682.

[0082] 3GPP TS 23.501 “System Architecture for the 5G System” is the overall architecture specification and the primary reference for 5G.

[0083] The used Charging model in 3GPP is specified 3GPP TS 32.240 “Charging architecture and principles” with the specific description for the EPC bearer traffic of PDN connections in 3GPP TS 32.251 and for small data in 3GPP TS 32.253 “Control Plane Data Transfer charging”.

[0084] The new objects for the measurement may be defined in the Diameter Charging protocol as specified in 3GPP TS 32.299 “Diameter Charging applications” as well as in the Charging Data Record (CDR) in ASN.1 format specified in 3GPP TS 32.298.

[0085] The details on the extension on the AVP definitions of the Diameter Charging protocol may be described separately for Offline Charging for the AVPs in Diameter Accounting application and for Online Charging for the AVPs in Diameter Credit-Control Application (DCCA).

[0086] The following section shows the extension of the AVP definitions that may be used for Accounting application and DCCA. If some embodiments of the invention will be standardized, these specifications may be adapted as shown in bold in the following sections:

[0087] The Traffic-Data-Volumes AVP (AVP code 2046) is of type Grouped. Its purpose is to allow the transmission of the IP-CAN bearer container, on encountering change on charging condition for this IP-CAN bearer. This container reports the volume count (separated for uplink and downlink). The 3GPP-Charging-Id AVP for the IP-CAN bearer is included when charging per IP-CAN session is active.

TABLE-US-00001 Traffic-Data-Volumes :: = < AVP Header: 2046>  [ QoS-Information ]  [ Accounting-Input-Octets ]  [ Accounting-Output-Octets ]  [ Payload-Input-Count ]  [ Payload-Output-Count ]  [ Change-condition ]  [ Change-Time ]  [ 3GPP-User-Location-Info ]  [ UWAN-User-Location-Info ]  [ 3GPP-Charging-Id ]  [ Presence-Reporting-Area-Status ]  [ User-CSG-Information ]  [ 3GPP-RAT-Type ]  [ Access-Availability-Change-Reason ]  [ Related-Change-Condition-Information ]  [ Diagnostics]  [ Enhanced-Diagnostics ]  [ CP-CloT-EPS-Optimisation-Indicator ]  [ Serving-PLMN-Rate-Control ]

[0088] The Service-Data-Container AVP (AVP code 2040) is of type Grouped. Its purpose is to allow the transmission of the container to be reported for Flow based Charging in PCEF or application based charging in Traffic Detection Function (TDF). On encountering change on charging condition in Flow based Charging, this container identifies the volume count (separated for uplink and downlink), elapsed time or number of events, per service data flow identified per rating group or combination of the rating group and service id within an IP-CAN bearer. On encountering change on charging condition in application based Charging, this container identifies the volume count (separated for uplink and downlink), elapsed time or number of events, per rating group or combination of the rating group and service identifier within a TDF session.

TABLE-US-00002 Service-Data-Container :: = < AVP Header: 2040>  [ AF-Correlation-Information ]  [ Charging-Rule-Base-Name ]  [ Accounting-Input-Octets ]  [ Accounting-Output-Octets ]  [ Payload-Input-Count ]  [ Payload-Output-Count ]  [ Local-Sequence-Number ]  [ QoS-Information ]  [ Rating-Group ]  [ Change-Time ]  [ Service-Identifier ]  [ Service-Specific-Info ]  [ ADC-Rule-Base-Name ]  [ SGSN-Address ]  [ Time-First-Usage ]  [ Time-Last-Usage ]  [ Time-Usage ] *[ Change-Condition]  [ 3GPP-User-Location-Info ]  [ 3GPP2-BSID ]  [ UWAN-User-Location-Info ]  [ Sponsor-Identity ]  [ Application-Service-Provider-Identity ]  [ Presence-Reporting-Area-Status ]  [ User-CSG-Information ]  [ 3GPP-RAT-Type ]  [ Related-Change-Condition-Information ]  [ Serving-PLMN-Rate-Control ]  [ APN-Rate-Control ]

For the Diameter AVP Definition of Small Data Via SCEF

[0089] The NIDD-Submission AVP (AVP code 3928) is of type Grouped and holds information about the NIDD submission for CP data transfer.

TABLE-US-00003 NIDD-Submission :: =  < AVP Header: 3928> [ Submission-Timestamp ] [ Event-Timestamp ] [ Accounting-Input-Octets ] [ Accounting-Output-Octets ] [ Payload-Input-Count ] [ Payload-Output-Count ] [ Change-Condition ]

[0090] In Online Charging is the Multiple-Services-Credit-Control AVP used in the DCCA as the central AVP and Payload counts may be defined as follows:

[0091] The Multiple-Services-Credit-Control AVP (AVP code 456) is of type grouped as specified in RFC 4006 [402]. It contains additional 3GPP specific charging parameters.

TABLE-US-00004 Multiple-Services-Credit-Control ::= < AVP Header: 456 >  [ Granted-Service-Unit ]  [ Requested-Service-Unit ] * [ Used-Service-Unit ]  :

[0092] The Used-Service-Unit AVP (AVP code 446) is of type grouped as specified in RFC 4006 [402]. It contains additional 3GPP specific charging parameters.

TABLE-US-00005 Used-Service-Unit ::=  < AVP Header: 446 >  [ Reporting-Reason ]  [ Tariff-Change-Usage ]  [ CC-Time ]  [ CC-Total-Octets ]  [ CC-Input-Octets ]  [ CC-Output-Octets ]  [ CC-Input-Payloads ]  [ CC-Output- Payloads ]  [ CC-Service-Specific-Units ] *[ Event-Charging-TimeStamp ]

[0093] The following AVPs from the IETF may be added to TS 3GPP 32.299 and modified accordingly:

TABLE-US-00006 CC-Unit-Type AVP extended with new values: TIME 0 MONEY 1 TOTAL-OCTETS 2 INPUT-OCTETS 3 OUTPUT-OCTETS 4 SERVICE-SPECIFIC-UNITS 5 INPUT-PAYLOADS 6 OUTPUT-PAYLOADS 7 Requested-Service-Unit ::= <AVP Header: 437 >  [ CC-Time ]  [ CC-Money ]  [ CC-Total-Octets ]  [ CC-Input-Octets ]  [ CC-Output-Octets ]  [ CC-Input-Payloads ]  [ CC-Output- Payloads ]  [ CC-Service-Specific-Units ]   Granted-Service-Unit ::= < AVP Header: 431 >  [ Tariff-Time-Change ]  [ CC-Time ]  [ CC-Money ]  [ CC-Total-Octets ]  [ CC-Input-Octets ]  [ CC-Output-Octets ]  [ CC-Input-Payloads ]  [ CC-Output- Payloads ]  [ CC-Service-Specific-Units ]  

[0094] The final recording for the analytics may be based on the extension of the CDR parameter definition in ASN.1 following the rules which are specified in 3GPP TS 32.298:

[0095] For small data transfer in a PDN connection via SGi interface (tunnel), the extension shown in bold in FIG. 7 may cover the recordings.

[0096] For small data transfer in a Service Data Flow (SDF) via SGi interface, the extension shown in bold in FIG. 8 may cover the recordings.

[0097] For the CDR parameter definition of NIDD via SCEF, the extension shown in bold in FIG. 9 may cover the recordings.

[0098] The above shown modifications are example proposals only. In particular, the respective parameter number of the proposed extension and the names of the parameters may be different from that shown in the above proposals. These detailed proposals are not to be considered as limiting in any way.

[0099] Embodiments of the invention may be used for NIDD. However, the invention is not restricted to NIDD. E.g., in some embodiments of the invention, the number of deliveries of IP traffic may be counted.

[0100] Embodiments of the invention may be employed in a 3GPP network such as LTE or LTE-A, or in a 5G network. They may be employed also in other wireless or wireline communication networks such as CDMA, EDGE, UTRAN networks, WiFi networks, etc. In particular, embodiments of the invention may not be applied to mobile networks only, but also to fixed networks. This might be particularly useful if IoT devices are connected via WLAN or LAN to a router, which is connected via fixed line (e.g. DSL or a variant thereof) to the network.

[0101] A terminal may be any apparatus capable to access the respective network. E.g., in 3GPP networks, a terminal may be a UE, an IoT device, etc. The terminal may be a smartphone, a laptop, a mobile phone, a sensor, a module etc. In particular, embodiments of the invention may be applied to non-IoT devices, too.

[0102] A subscription may be related to a device (such as a terminal), a group of devices, an IoT application, an external identifier, or any other identifier for a service function. For example, a subscription may be related to a user of a device. One or more subscriptions may be related to one device. One subscription may be related to one or more devices.

[0103] One piece of information may be transmitted in one or plural messages from one entity to another entity. Each of these messages may comprise further (different) pieces of information.

[0104] Names of network elements, protocols, and methods are based on current standards. In other versions or other technologies, the names of these network elements and/or protocols and/or methods may be different, as long as they provide a corresponding functionality.

[0105] If not otherwise stated or otherwise made clear from the context, the statement that two entities are different means that they perform different functions. It does not necessarily mean that they are based on different hardware. That is, each of the entities described in the present description may be based on a different hardware, or some or all of the entities may be based on the same hardware. It does not necessarily mean that they are based on different software. That is, each of the entities described in the present description may be based on different software, or some or all of the entities may be based on the same software. One or more of the described entities may be implemented in the cloud. In particular, each of the described entities may be implemented as a network slice.

[0106] According to the above description, it should thus be apparent that example embodiments of the present invention provide, for example, a gateway function, such as a PGW or a SCEF or a NEF or a SMF, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s). According to the above description, it should thus be apparent that example embodiments of the present invention provide, for example, an charging system, such as a OCS or a OFCS, or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).

[0107] Implementations of any of the above described blocks, apparatuses, systems, techniques or methods include, as non-limiting examples, implementations as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof. They may be implemented fully or partly in the cloud.

[0108] It is to be understood that what is described above is what is presently considered the preferred embodiments of the present invention. However, it should be noted that the description of the preferred embodiments is given by way of example only and that various modifications may be made without departing from the scope of the invention as defined by the appended claims.