Tech-invite  3GPPspace  IETFspace
◀  ▶  21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.434  Word version:  19.7.0

Top   Top   Up   Prev   None
0…   6…   8…   9…   9.3…   9.3.3…   9.3.8…   9.3.13…   9.3.20…   9.3.23…   9.4…   10…   10.3…   10.3.3…   10.3.7…   10.4…   11…   12…   13…   14…   14.3…   14.3.3…   14.3.4…   14.3.4A…   14.3.4A.5…   14.3.4A.8…   14.3.5…   14.3.9…   14.4…   15…   17…   18…   A… 
A SEAL integration with 3GPP network exposure systems  B SEAL functional model mapping with Common functional architecture (CFA)  C Protocol realizations of LWP in the signalling control plane  D Exemplary location profile attributes  E Support for Mobile Metaverse use case  $ Change history 

 

A  SEAL integration with 3GPP network exposure systems  p. 346

Figure A-1 illustrates the service-based interface representation of the functional model for SEAL services integration with 5GC network exposure system.
Reproduction of 3GPP TS 23.434, Fig. A-1: SEAL integration with 5GC network exposure system
Figure A-1: SEAL integration with 5GC network exposure system
Up
The details of NEF and its role in exposing network capabilities of 5GS to 3rd party applications are specified in TS 23.501 and the details of NEF service operations are specified in TS 23.502.
Figure A-2 illustrates the service-based interface representation of the functional model for SEAL services integration with EPC network exposure system.
Reproduction of 3GPP TS 23.434, Fig. A-2: SEAL integration with EPC network exposure system
Figure A-2: SEAL integration with EPC network exposure system
Up
The details of SCEF and its role in exposing network capabilities of EPS to 3rd party applications are specified in TS 23.682.

B  SEAL functional model mapping with Common functional architecture (CFA)  p. 348

The Table B-1 shows the mapping between the SEAL functional model and the Common functional architecture (CFA). The details of CFA functional entities and reference points are specified in TS 23.280.
SEAL service Aspects SEAL CFA
Location managementFunctional entityLocation management clientLocation management client
Location management serverLocation management server
Reference pointsLM-UUCSC-14
LM-SCSC-15
LM-CNot defined
LM-ENot defined
LM-PC5Not defined
Group managementFunctional entityGroup management clientGroup management client
Group management serverGroup management server
Reference pointsGM-UUCSC-2
GM-SCSC-3
GM-CNot defined
GM-ECSC-16
GM-PC5CSC-12
Configuration managementFunctional entityConfiguration management clientConfiguration management client
Configuration management serverConfiguration management server
Reference pointsCM-UUCSC-4
CM-SCSC-5
CM-CNot defined
CM-ECSC-17
CM-PC5CSC-11
Identity managementFunctional entityIdentity management clientIdentity management client
Identity management serverIdentity management server
Reference pointsIM-UUCSC-1
IM-SNot defined
IM-CNot defined
IM-ENot defined
IM-PC5Not defined
Key managementFunctional entityKey management clientKey management client
Key management serverKey management server
Reference pointsKM-UUCSC-8
KM-SCSC-9
KM-PC5Not defined
Network resource managementFunctional entityNetwork resource management clientNot defined (see NOTE)
Network resource management serverNot defined (see NOTE)
Reference pointsNRM-UUNot defined (see NOTE)
NRM-SNot defined
NRM-CNot defined
NRM-ENot defined
NRM-PC5Not defined
NOTE:
Defined in the application layer for Mission Critical service (e.g. MCPTT).
Up

C (Normative)  Protocol realizations of LWP in the signalling control plane |R17|  p. 349

C.1  General  p. 349

This Annex specifies protocol realizations of the light-weight protocol in the signalling control plane.

C.2  Usage of CoAP as LWP  p. 349

This clause specifies how the CoAP protocol shall be used to realize the generic light-weight protocol in the signalling control plane.
The Constrained Application Protocol (CoAP) is a light-weight protocol defined by IETF in RFC 7252 and designed specifically for application layer communication for constrained devices. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. RFC 7252 specifies bindings to UDP and DTLS. RFC 8323 specifies bindings to TCP, WebSocket and TLS.
Figure C.2-1 illustrates the functional model for the LWP signalling control plane when CoAP is used as the LWP.
Reproduction of 3GPP TS 23.434, Fig. C.2-1: Functional model for LWP signalling control plane when CoAP is used as LWP
Figure C.2-1: Functional model for LWP signalling control plane when CoAP is used as LWP
Up
When CoAP is used to realize the generic light-weight protocol defined in clause 6.2, then,
  1. CoAP client is a realization of the LWP client
  2. CoAP proxy is a realization of the LWP proxy, with the following clarifications:
    1. CoAP proxy shall be able to terminate a DTLS, TLS or secure WebSocket session on LWP-1 reference point;
    2. CoAP proxy shall be able to act as a cross-protocol CoAP-HTTP proxy to support LWP-HTTP-2 and LWP-HTTP-3 reference points;
  3. CoAP server is a realization of the LWP server
  4. CoAP supports the interactions over LWP-1, LWP-2 and LWP-3 reference points
  5. The usage of CoAP by the SEAL service enablers shall follow the rules set out in clause 6.4.3.5.
Up

D  Exemplary location profile attributes |R18|  p. 350

The Table D-1 shows the example of attributes that can be used for the location profiles.
Profile ID / name Vertical / use case/environment Positioning Service Level (for IIOT) / QoS / accuracy Positioning Method(s) / Priorities Involved 3GPP functionalities / Priorities Required APIs / API info Other
Location profile #1Industrial scenario; indoors; mobile robots/ AGVsService Level 6 / cm level accuracy / absolute/relative/ both1. DL-TDOA,
2. UL-TDOA,
3. Multi-RTT methods,
4. WLAN, 5. motion sensors,
6. Bluetooth		1. LMF
2. RAN-LMC, 3. SEAL LMS		NEF APIs, SEAL APIs Verification / augmentation required
Location profile #2V2X; outdoorDecimeter level accuracy /... absolute/relative/both1. DL-TDOA,
2. Multi-RTT methods,
3. GNSS-RTK,
4. Sensor fusion,
5. A-GPS		1. LMF
2. SEAL LMS
3. Other UEs		NEF APIs, MEC APIs Support for sidelink positioning
Up

E  Support for Mobile Metaverse use case |R19|  p. 350

In Mobile Metaverse one use case is the 5G-enabled Traffic Flow Simulation and Situation Awareness in which the real conditions of a road including vehicles and other factors are captured with sensors, modelled in a simulation and used to provide guidance for vehicles and users for efficiency and safety. This is a specific example of a broad category of 'situational awareness' services that capture 'virtual representations' of the real world to then advise or control actions taken in the real world. As shown in Figure E-1. real-time processing and computing can be conducted to support traffic simulation and also situational awareness and real time path guidance and real-time safety, or security alerts can be generated for ICVs as well as the driver and passengers.
Copy of original 3GPP image for 3GPP TS 23.434, Fig. E-1: Use case of 5G-enabled Traffic Flow Simulation and Situational Awareness [3GPP TR 22.856]
Figure E-1: Use case of 5G-enabled Traffic Flow Simulation and Situational Awareness [3GPP TR 22.856]
(⇒ copy of original 3GPP image)
Up
In this use case, the mobile metaverse service requirements are applicable to communication among different entities for multi-user interactions (as can be seen also in Figure E-1). The sessions include UE to UE communications and UE to virtual UE (at the server side) communications.
More specifically, in an example for two identified VAL UEs the following types of VAL sessions may be present:
  • VAL session #1: Metaverse app in VAL client 1 sends to virtual UE 1 (in DN side at the VAL server) sensor data / measurements on the physical environment related to VAL UE1 over VAL-UU interface. Virtual UE1 sends back haptic feedback to UE1 (for UE1 and/or UE2 and the environment).
  • VAL session #2: Metaverse app in VAL client 2 sends to virtual UE 2 (in DN side at the VAL server) sensor data / measurements on the physical environment related to VAL UE2 over VAL-UU interface. Virtual UE2 sends back haptic feedback to UE2 (for UE1 and/or UE2 and the environment).
  • App-specific session #3: Exchange of service related / feedback data between virtual UEs (for example micro-transactions such as avatar updates/modifications or environment changes).
  • App-specific session #4: Sensor data / measurements are exchanged between VAL UEs (communication can be over side link) for traffic related to the metaverse service.
To support such use case, SEAL NRM as in clause 14.3.9.2.3 supports the discovery of the virtual UEs (as counterparts of the physical UEs) and identify the sessions required as well as the per session requirement in both physical and virtual world.
Up

$  Change history  p. 352

Up   Top