Minutes by: Erik Guttman, Samsung
Attendees list: (incomplete, but included the following) - Kenta (NTT Docomo), Lei, Yuhang (Tencent), Alice (Huawei), Eng Wei (Keysight), Wongjung (LGUplus), Gongrong (Spreadtrum), Chinglin (China Telecom), Yvette (ZTE), Philippe (Orange)
We agreed on the agenda.
We opened papers that had had problems in previous meetings to solicit constructive comments.
draft_S1-22xxxx_work delegation.docx
Kenta explained the changes, mainly using the term ‘autonomous virtual alter ego’ instead of ‘avatar’ which is not usually thought of as autonomous.
Comments:
- Erik
- what motivates the second requirement on tactile aspects. How does this relate to a virtual alter ego?
- Erik
- the terminology ‘call’ is confusing. If this is the means that the autonomous virtual alter ego communicates with the user, why do you need the 3rd requirement?
Also: - the numbering of the requirements is currently wrong)
- the terminology of the 3rd requirement is stage 2 not stage 1, use AS not AF, session not PDU session, etc. for stage 1.
- Kenta
- the idea is that the contact is at the application layer, that is why there need to be AF initiated PDU sessions
- Alice
- tighten the description, please. Step 1 apps are used, not ‘calling’
what is the purpose of the app on a mobile device? Is this what controls the virtual alter ego? or is it an AS? What is the impact on the network? This is not clear now.
- Kenta
- it is the AS
- Erik
- it appears from the use case that managing the ‘tasks’ for the virtual alter ego to perform is the main focus of the use case, but in fact this is entirely out of 3GPP scope. Plesae capture the real intent which is to allow a user to create a ‘software entity’ that can operate with the user’s credentials. The flow could use more motivation - corresponding to the requirements. Perhaps ‘AS initiating a user session’ is not needed, as there are existing ‘triggering’ services as part of IoT.
S1-22xxxx_New use case_Virtual universes interconnection DRAFT 05 delta.docx
Philippe explained the updates (mainly terminology) since the last version.
- Erik
- perhaps combine the two documents? the first requirement in this is the same as the requirements in the ‘digital asset container’ use case. What ‘selection’ is needed in the 2nd requirement
[PR 5.x.6-2] Based on the user configurations and privacy options, the 5G system shall support mechanisms to securely provide the selected information of the user to an immersive XR media service when the user accesses the service.
- Alice
- the emphasis should not be on ‘selecting’ but rather on the user configuring content to expose / use with different services.
S1-22xxxx_New use case_Digital asset container access DRAFT 05 delta.docx
Philippe explained the updates (mainly terminology) since the last version.
- Erik
- There is very useful information in the EU digital wallet initiative. This could be generally useful even outside Europe. Please add Samsung as a supporting company. The first requirement must be reworked.
The use case service flow is abstract. Please use a concrete one. Example: e-government. Here is some proposed text:
The user wants to dispose of old paint and solvent at a local dump. They have to identify themselves as being a local resident, authorized to use the dump. They have to provide payment information, to pay the fee to dispose of toxic waste. The user interacts with the dump (services) and the ID and payment information is shared with the service. The authorities that run the facility now expect the user and take the paint and solvent.
There are limits to the battery because of battery technology and AR glasses form factors. Given a plausible scenario of 2 hours video, this exceeds the power capacity of AR glasses and low power devices.
The goal is to first study how power consumption for metaverse services can be reduced, made more efficienct, etc. How can these devices operate at a lower power requirement?
Then, if there is agreement, consider a new specialized UE type with a specific power storage rating.
- Erik
- the assumptions for battery life may be true today, but in 8 years when Rel-19 is deployed? This is really not a good basis for deciding power rating. Further, we fundamnentally disagree that 3GPP should create device classes on the basis of power storage capacity, except for the case of CIoT assumptions made in Rel-13 for devices that must operate autonomously without a chance of recharge.
Definition of classes of devices based on form factor goes close to ‘commercial’ aspects that are completely out of scope of 3GPP.
Samsung is supportive of the first goal.
Tencent presented their proposal for requirements for use case 5.2
There are 3 requirements that were present in S1-222025r8 but removed by the end of SA1 99e to gain agreement. These were discussed in the call:
[PR 5.2.1.6-2] The 5G system shall be able to support delivery of structured and unstructured data originating from sensors of physical objects to metaverse server when 5G system is utilized as wireless backhaul.
- Erik
- is structured data going to be standardized in 3GPP?
- Lei
- it makes a difference if data is structured, in this case optimizations are possible, e.g. at the network edge the structured data could be converted into a more efficient structure, with less resolution, etc.
- Erik
- is this just over the top or is the structure standardized in 3GPP?
- Lei
- the structure is defined outside of 3GPP
- Erik
- use the KPI table to define different rows for the data communication.
- Yvette
- this is too close to stage 2
- Erik
- I agree with Yvette. STructured data can be handled in ‘special ways’ by the architecture, e.g. store and forwarding, caching, etc. In stage 1 we cannot discuss data at all unless it is standardized in format, e.g. as in AVPROD where raw video was defined, as well as specific kinds of compressed video.
- Alice
- if the terms are used at all, what does the 5GS need to understand and to handle structured differently? What is the impact?
[PR 5.2.1.6-3] The 5G system shall be able to support mechanisms to enable a trusted third party (e.g. metaverse server) to associate the physical objects with its corresponding virtual objects in the mobile metaverse.
Editor’s Note: 5GS functionalities of the above two potential requirements need to be clarified further.
- Lei
- this relates to ‘digital twin’ and IDs in the 5GS
- Erik
- does the 5GS itself recognize objects, or is this done by services not defined in the of scope of 3GPP? If out of scope, how can 3GPP recognize an object at all (virtual or physical)?
I suggest that you look at the Spatial Anchor use case from Samsung, where the spatial location (which is a value, though it can be changed - it is a reference to a well defined position, in 3D space), to service information e.g. a URL and possibly client configuration information. This association is very clear and actionable as a requirement, whereas I do not understand how PR 5.2.1.6-3 can be clear or actionable.
- Lei
- if the physical object has an ID this ID can be associated with another ID, for the virtual object. The physical object could be a UE.
- Erik
- Is this only for UEs or other objects? Why is the ID association meaningful to the 5GS? Isn’t this merely at the application layer where ‘situational awareness’ is determined?
[PR 5.2.1.6-4] The 5G system shall provide means to minimize service disruptions as a result of mobility considering a diverse QoS characteristics of the devices involved in the metaverse.
- Erik
- What does ‘minimize service disruptions’ mean? Normally mobility requirements are for service continuity. What does QoS characteristics of devices mean? I cannot understand this requirement at all.
- Alice
- Distruption is not a good word - is this a matter of ‘better’ or ‘worse’?
- Lei
- this requirement and related aspects in the use case are from Interdigital.