Consumption Reporting - Generating the reportingClientId

[dsilhavy]

Description

TS 26.512 defines the reportingClientId as a property of the ConsumptionReport format:

Identifier of the reporting client that consumed the streaming media service associated with this consumption report.
If available to the Media Session Handler, a GPSI value (see clause 28.8 of TS 23.003 [7]); otherwise, a stable and globally unique string.

We are currently manually generating a reportingClientId:

import java.util.UUID

fun generateUUID(): String {
   val uuid = UUID.randomUUID()
   return uuid.toString()
}

utils.generateUUID()

We should switch to a Generic Public Subscription Identifier (GPSI) value if available. For that reason, we need to check how we can derive this value using the Android API.

[rjb1000]

Just to add that in cases where you can't get hold of the GPSI, a UUID is a perfectly fine substitute provided it persists between different media streaming sessions and restarts of the Media Session Handler. To balance this out, it would be highly desirable to offer the end user the ability to manually reset the UUID-based reporting client identifier at will as an anti-tracking feature.

You could display the current reporting client identifier in some UI element of the Media Session Handler service and (if it is a UUID) offer a "Reset" button that picks and displays the replacement value.

[shilinding]

@dsilhavy I've implemented it as : when GPSI availabe, use GPSI; else, use UUID.

But I have a question: If a phone with two SIM card registered to two mobile operaters, I think it will get two GPSI. If so, which one should we select? My understanding is any one of them is OK, we can select the first simply.

[dsilhavy]

Thanks @shilinding , have you verified that the the GPSI you are deriving has the following format:

The GPSI is either an MSISDN or an External Identifier

MSISDN = CC + NDC + SN

I just did a quick check and this is what I found

The getSubscriptionId() method returns a unique identifier for a specific subscription or SIM card. It provides an integer value that represents the subscription ID associated with the SIM card, which is typically used to differentiate between multiple SIM cards or subscriptions on a device

What might help is this method: https://developer.android.com/reference/android/telephony/SubscriptionManager#getPhoneNumber(int)

[shilinding]

Thanks Daniel.
I always test in Android Studio with emulator and I can't test with real phone. Because phones are not permitted to access the company's network, and the fake AF is in intranet. In emulator there is no SIM cards therefor it gets nothing. So I plan to pick out the code slice and create another simple Android project and test it in a real phone with SIM cards. After done, I'll update it here.

[shilinding]

I verified the latest version in a test project on real phone, it seems works now as below:

• If there are SIM cards, the GPSI will be MSISDN:

2023-11-15 18:23:36.373 18223-18223   permission-simcnt:2
2023-11-15 18:23:36.376 18223-18223   permission[1]-subscriptionName:China Telecom
2023-11-15 18:23:36.376 18223-18223   permission[1]-subscriptionIcc:
2023-11-15 18:23:36.381 18223-18223   permission[1]-MSISDN:+8619166208511
2023-11-15 18:23:36.381 18223-18223   permission[2]-subscriptionName:China Unicom
2023-11-15 18:23:36.381 18223-18223   permission[2]-subscriptionIcc:
2023-11-15 18:23:36.384 18223-18223   permission[2]-MSISDN:+8613352938834
2023-11-15 18:23:36.385 18223-18223   GPSI: +8613352938834

It seems the format is correct:
MSISDN = CC(+86) + NDC(133) + SN(52938834)

• If there is no SIM card, the GPSI will be UUID:

2023-11-15 18:56:24.571  1799-1799  Consumptio...Controller GPSI: 2d2aced9-363b-4b3a-820c-2b0e081fe81a

[shilinding]

@dsilhavy I've implemented it as : when GPSI availabe, use GPSI; else, use UUID.

But I have a question: If a phone with two SIM card registered to two mobile operaters, I think it will get two GPSI. If so, which one should we select? My understanding is any one of them is OK, we can select the first simply.

@dsilhavy If there are more than one SIM cards, we'll get several MSISDNs, can we simply choose the first one?

[dsilhavy]

Thanks @shilinding that looks good. I would choose the first MSISDN unless you can tell which SIM is used for the traffic?

[shilinding]

Thanks @shilinding that looks good. I would choose the first MSISDN unless you can tell which SIM is used for the traffic?

I think there should be API to get which SIM is using, I'll figure it out and choose base on it. But as far as I know, it seems that some mobile phones (such as Xiaomi) now support the case of two cards joint Internet access, this case we still can only choose one MSISDN such as the first.

[dsilhavy]

Thanks @shilinding that looks good. I would choose the first MSISDN unless you can tell which SIM is used for the traffic?

I think there should be API to get which SIM is using, I'll figure it out and choose base on it. But as far as I know, it seems that some mobile phones (such as Xiaomi) now support the case of two cards joint Internet access, this case we still can only choose one MSISDN such as the first.

Makes sense, let's discuss this question tomorrow in the call. I would choose the first then if multiple SIMs are active at the same time.

[shilinding]

Updated the code to select GPSI by which SIM is used for the traffic(+8613352938834 selcted before).

2023-11-16 17:54:08.121 13285-13285 com.example.test_demo    D  permission-simcnt:2
2023-11-16 17:54:08.126 13285-13285 com.example.test_demo    D  permission-active:China Telecom
2023-11-16 17:54:08.126 13285-13285 com.example.test_demo    D  permission[1]-subscriptionName:China Telecom
2023-11-16 17:54:08.126 13285-13285 com.example.test_demo    D  permission[1]-subscriptionIcc:
2023-11-16 17:54:08.126 13285-13285 com.example.test_demo    D  permission[1]-MSISDN:+8619166208511
2023-11-16 17:54:08.126 13285-13285 com.example.test_demo    D  permission[1]-Active: Y
2023-11-16 17:54:08.126 13285-13285 com.example.test_demo    D  permission[2]-subscriptionName:China Unicom
2023-11-16 17:54:08.126 13285-13285 com.example.test_demo    D  permission[2]-MSISDN:+8613352938834
2023-11-16 17:54:08.126 13285-13285 com.example.test_demo    D  permission[2]-Active: N
2023-11-16 17:54:08.134 13285-13285 com.example.test_demo    D  GPSI selected: +8619166208511

[rjb1000]

Updated the code to select GPSI by which SIM is used for the traffic

Well done. This sounds exactly what's needed.

[rjb1000]

...as far as I know, it seems that some mobile phones (such as Xiaomi) now support the case of two cards joint Internet access...

This is an interesting edge case. And it's something that might become more prevalent with more widespread adoption of multipath TCP (for HTTP/1.1) and multipath QUIC (for HTTP/3). The 5GMS consumption reporting feature doesn't take into account the possibility that the same ConsumptionReportingUnit might have used PDU Sessions on different PLMNs at reference point M4. What value should the reportingClientId have in such cases? At first sight, there are potentially multiple GPSI values to be reported.

However, when you stop to think about it, I'm not sure it's actually a problem. A media streaming session is always initiated by the Media Session Handler interacting with a 5GMS AF in the 5GMS System of one of the PLMNs available to the UE. The Media Entry Point URL selected from the streamingAccess in the Service Access Information will point at a 5GMS AS in the same 5GMS System. And the consumption reporting endpoint in the Service Access Information points to a 5GMS AF on the same 5GMS System.

So, even if there are multiple PDU Sessions available simultaneously to the UE on different PLMNs, and even if both PLMNs have a 5GMS System deployed, once the UE has picked a 5GMS AF in one PLMN from which to acquire its Service Access Information (e.g. based on Round Robin DNS resolution of the well-known 5GMS AF host name in Rel-18 onwards), I think that the media streaming session is then tied to that one 5GMS System. The IP routing table in the UE's URSP Rules will ensure that packets are routed down the correct PDU Session to the correct target 5GMS AS and 5GMS AF. And the lack of an IP address for those servers in the subnet of the "wrong" PDU Session will prevent any packets being routed down that path. Hence, the "wrong" PDU Session isn't a candidate route for multipath transport protocols.

If you are in any doubt, my recommendation would be to populate reportingClientId with the UUID in cases where you can't establish definitively which of multiple GPSI values was used to access the content. But, for the reasons explained above, I don't think you will encounter any ambiguity in practice. (If we find corner cases, we can discuss further, perhaps with SA4 colleagues.)

Tagging @tlohmar, @haudiobe and @ibouazizi for information.)

[shilinding]

This issue has been addressed in :

• DevelopmentConsumption Reporting - Generating the reportingClientId #61

• Request permission for getting GPSI (Consumption Reporting - Generating the reportingClientId #57) rt-5gms-application#33

[dsilhavy]

Implemented in #61, minor changes in #64