User Story 2 - Outdoor Live Streaming

[chinaunicomyangfan]

Problem description Add the second User Story for Region User Count

User Story 2 - Outdoor Live Streaming I am an outdoor anchor and plan to conduct outdoor live streaming activities in different regions. In order to estimate the possible number of viewers and effectively choose a live streaming location, I need to understand the potential number of viewers in different regions User requirements 1.I hope to obtain the number of users in a specific area through an API, so that I can choose locations with high audience potential for live streaming based on this data. 2.I need an API that can provide information on the activity level of users in the area, in order to determine the activity time of users in that area and arrange the best live broadcast time. 3.I hope the response time of the API is fast, so that decisions can be made quickly before planning and actual live broadcasts. Acceptance criteria 1.I can provide coordinates or boundary information of the area by calling the API, and successfully obtain the potential number of viewers in that area. 2.The API can return the total number of users and the distribution of active time of users in that area, helping me analyze the optimal live streaming time slot. 3.The response time of the API should be within a few seconds to ensure that data can be quickly received and live streaming arrangements can be made in a timely manner. Remarks 1.This API can be implemented through the operator's data platform or relevant location service providers. 2.When using this data, it is necessary to consider user privacy protection and data usage compliance to ensure the legitimate collection and use of information.

[ShutingQing]

LGTM.

[gregory1g]

1. As discussed, "user" is a a complex term. Moreover, a streamer has their own view on their user base and therefore must be able to define filter. This means that acceptance criteria must include: possibility for a streamer to define device filter. for a random video streamer this could be be 5G enabled smartphones

2. This UC clearly highlights the needs to provide a prediction as well (many other UC can benefit from this as well). The streamer wants "effectively choose a live streaming location". To do this the streamer needs to know audience forecast for the time they plan to stream - Data from Monday morning is not a very useful for selection Saturday Evening outdoor stream.

[gregory1g]

According to the described acceptance criteria teh API must expose "The API can return the total number of users". afaik, we have agreed that the API exposes number of connected devices, not users (the term which is not easy to define).

[chinaunicomyangfan]

As discussed, "user" is a a complex term. Moreover, a streamer has their own view on their user base and therefore must be able to define filter. This means that acceptance criteria must include: possibility for a streamer to define device filter. for a random video streamer this could be be 5G enabled smartphones

This UC clearly highlights the needs to provide a prediction as well (many other UC can benefit from this as well). The streamer wants "effectively choose a live streaming location". To do this the streamer needs to know audience forecast for the time they plan to stream - Data from Monday morning is not a very useful for selection Saturday Evening outdoor stream.

1.As we discussed earlier, it is indeed difficult to obtain the number of all users, and the number of users can only be estimated based on the number of devices. Regarding filters, we can refer to the discussion here. We do intend to add statistics on the number of users of different categories in the return parameters. For this use case, I believe it is meaningful to obtain the number of all human devices, but there is no need to distinguish what type of device it is(e.g. 4G,5G). Outdoor anchors only want to find areas with a larger number of people for live streaming, and do not care about what type of device it is. 2.The prediction is indeed meaningful for this use case, but it is not within the scope of this API. Perhaps PopulationDensityData is more suitable? In this use case, the demand for outdoor anchors is to obtain locations with high current population density, so that live streaming locations can be changed based on the current real-time population density

[gregory1g]

"Outdoor anchors only want to find areas with a larger number of people for live streaming, and do not care about what type of device it is." - depends on very specific situation.

Exactly this user story is hardly implementable without a prediction. Realtime is not really useful if one plans a stream for the coming weekend. And if this userstory is important we cannot simply ignore this.

Where one can find decision saying that prediction is not in scope?

[chinaunicomyangfan]

Our internal usage scenarios for this API are to obtain real-time device count, so when initially submitting this API, we only considered the need for real-time statistics. If we add predictions, it will indeed enrich the content of this API and adapt to more scenarios, such as outdoor live streaming planning and security protection planning in densely populated areas. My only concern is whether it will conflict with PopulationDensityData, as this part seems to overlap

[gregory1g]

Yes, the APIs have some overlapping use cases even without a future prediction. If an API user wants an estimation about number of people in the area - ppl density provides exactly this. While DeviceCount delivers number of connected devices for a single MNO only (population estimation on top of this info is a work for API user).

Anyways, the use story introduced in this issue very explicitly requires either prediction or historical data. Just thinking loud: As an "outdoor streamer" I want to choose a region to do some activities (in at least few days in the future). My target audience are other outdoor enthusiasts which will be traveling the same place, therefore I'm after mobile devices (people who just live there are not my target audience). So, I need to know how many phones with fast internet will be on day X in the locations I choice from. I could probably even be focused on roamers only! For this I either need a future forecast (best option for me) or a historical data (so I can do forecast myself).

Near-real time data is useful if I want to start my stream within an hour form now. This hardly match "outdoor" story. To split topic I suggest: 1) keep prediction/history to a separate discussion 2) adjust this user story to something which works well with near real-time data. for the #2 we can change "outdoor" streamer to a a youtube channel driver in music (show, sport, etc) branch who visits a big city where an open-air music (or another target topic) festival happens. In the city there are many different locations where different bands do play. The youtuber has to select which location to go and stream from. For this they call DeviceCount to see where the people are and go there. In this case real-time data is more useful (and accurate) than historical or prediction

Sorry for a long comment.

[chinaunicomyangfan]

@gregory1g Thank you for the suggestion.I agree with you. 1.I will create another issue to discuss whether to add historical data queries and future data prediction functions 2.I will modify the user story to better match the needs of real-time queries