A.3 Based on CoAP
24.5383GPPEnabling MSGin5G ServiceProtocol specificationRelease 17TS
The following clauses describe example of the MSGin5G Constrained UE message format based on CoAP.
NOTE: Message format and protocol defined in this clause can be used if the communication between the Constrained UE and the MSGin5G GW UE is not based on PC5 / NR-PC5.
Editor’s note: How CoAP message is routed from constrained UE to MSGin5G UE is FFS.
A.3.1 message contents and functions
A.3.1.1 for sending a message to MSGin5G Client
In order to send a message, the Application Client on the constrained UE may generate an CoAP POST request according to procedures specified in IETF RFC 7252 [5] to the MSGin5G Client on a MSGin5G UE. In the CoAP POST request message, the Application Client:
a) set the "T" field in the CoAP header to 0 if delivery status report from the recipient is requested, i.e. indicates this message is the type of Confirmable, to ensure the application layer delivery status report;
b) include the MSGin5G Client address in an CoAP Option, e.g. if the MSGin5G Client address is a URI, include a Uri-Path Option with the value of the URI;
c) set the CoAP Content-Format to "50", i.e. application/json; and
d) include the information elements specified in clause 6.4.2.3.1 in the CoAP payload encoded in JSON format as specified in clause A.3.2.1.
A.3.1.2 for sending a message delivery status report to MSGin5G Client
In order to send a message delivery status report, the Application Client on the constrained UE may generate an CoAP POST request according to procedures specified in IETF RFC 7252 [5] to the MSGin5G Client on a MSGin5G UE. In the CoAP POST request message, the Application Client:
a) set the "T" field in the CoAP header to 0 indicating this message is the type of Confirmable;
b) include the MSGin5G Client address in an CoAP Option, e.g. if the MSGin5G Client address is a URI, include a Uri-Path Option with the value of the URI;
c) set the CoAP Content-Format to "50", i.e. application/json;
d) include the information elements specified in clause 6.4.2.3.2 in the CoAP payload encoded in JSON format as specified in clause A.3.2.2.
A.3.1.3 for sending a message to Application Client
In order to send a message, the MSGin5G Client may generate an CoAP POST request according to procedures specified in IETF RFC 7252 [5] to the Application Client. In the CoAP POST request message, the MSGin5G Client:
a) set the "T" field in the CoAP header to 0 if delivery status report from the recipient is requested, i.e. indicates this message is the type of Confirmable, to ensure the application layer delivery status report;
b) include the Application Client address in an CoAP Option, e.g. if the Application Client address is a URI, include a Uri-Path Option with the value of the URI;
c) set the CoAP Content-Format to "50", i.e. application/json;
d) include the information elements specified in clause 6.4.2.2.1 in the CoAP payload encoded in JSON format as specified in clause A.3.2.3.
A.3.1.4 for sending a message delivery status report to Application Client
In order to send a message delivery status report, the MSGin5G Client may generate an CoAP POST request according to procedures specified in IETF RFC 7252 [5] to the Application Client. In the CoAP POST request message, the MSGin5G Client:
a) set the "T" field in the CoAP header to 0 indicating this message is the type of Confirmable;
b) include the Application Client address in an CoAP Option, e.g. if the Application Client address is a URI, include a Uri-Path Option with the value of the URI;
c) set the CoAP Content-Format to "50", i.e. application/json;
d) include the information elements specified in clause 6.4.2.2.3 in the CoAP payload encoded in JSON format as specified in clause A.3.2.4.
A.3.1.5 for sending a message sending response to Application Client
After receiving a CoAP POST request for sending a message from Application Client, the MSGin5G Client may generate an CoAP 2.05 response according to procedures specified in IETF RFC 7252 [5] to the Application Client. In the response, the MSGin5G Client:
a) include the Application Client address in an CoAP Option, e.g. if the Application Client address is a URI, include a Uri-Path Option with the value of the URI;
b) set the CoAP Content-Format to "50", i.e. application/json; and
c) include the information elements specified in clause 6.4.2.2.5 in the CoAP payload encoded in JSON format as specified in clause A.3.2.5.
A.3.1.6 for sending a message received response to MSGin5G Client
After receiving a CoAP POST request for sending a message from MSGin5G Client, the Application Client may generate an CoAP 2.05 response according to procedures specified in IETF RFC 7252 [5] to the Application Client. In the response, the MSGin5G Client:
a) include the MSGin5G Client address in an CoAP Option, e.g. if the MSGin5G Client address is a URI, include a Uri-Path Option with the value of the URI;
b) set the CoAP Content-Format to "50", i.e. application/json; and
c) include the information elements specified in clause 6.4.2.3.3 in the CoAP payload encoded in JSON format as specified in clause A.3.2.6.
A.3.1.7 Registration Request
The registration request sent by the Application Client of the Constrained UE to the MSGin5G Client of the MSGin5G Gateway UE is based on the CoAP POST request as specified in IETF RFC 7252 [5]. The Application Client of the Constrained UE:
a) shall set the "T" field in the CoAP header to 0 to indicate acknowledge message required;
b) shall include the address of the MSGin5G Gateway UE in the Option header of the CoAP POST request and set the Option header to a corresponding value, e.g. if address of the MSGin5G Gateway UE is a URI, the Uri-Path Option is set to the value of such URI;
c) shall set the "Content-Format" element to "50" to indicate the format of the CoAP payload is "application/json"; and
d) shall include the following information elements in the CoAP payload encoded in JSON format:
1) the "MSGin5G service identifier" element to indicate that this CoAP POST request is used for MSGin5G service;
2) the "Message Type" element to indicate that the CoAP POST request is used for registration;
3) the "Application ID " element to indicate the application client initiating registration; and
4) the "Credential information" element to indicate the credential information of the Constrained UE.
A.3.1.8 Registration Response
The registration response sent by the MSGin5G Client of the MSGin5G Gateway UE to the Application Client of the Constrained UE is based on the CoAP 2.01 (Created) response or CoAP 2.04 (Change) response as specified in IETF RFC 7252 [5]. The Application Client of the Constrained UE:
a) shall include the CoAP "Message ID" element and the "Token" element with the same values with those in the CoAP POST request for registration; and
b) shall include the "Content-Format" element with "50" to indicate the format of the CoAP payload is "application/json". The CoAP payload:
1) shall include the "Registration Result" element to indicate whether the registration is success or failure;
2) shall include the "Registration ID" element allocated by the MSGin5G Client of the MSGin5G Gateway UE if the value of "Registration Result" element is set to true; and
3) shall include the "Failure Reason" element to indicate why the registration request is rejected by the MSGin5G Client of the MSGin5G Gateway UE if the value of "Registration Result" element is set to false.
A.3.1.9 De-registration Request
The de-registration request sent by the Application Client of the Constrained UE to the MSGin5G Client of the MSGin5G Gateway UE is based on the CoAP POST request as specified in IETF RFC 7252 [5]. The Application Client of the Constrained UE:
a) shall set the "T" field in the CoAP header to 0 to indicate acknowledge message required;
b) shall include the address of the MSGin5G Gateway UE in the Option header of the CoAP POST request and set the Option header to a corresponding value, e.g. if address of the MSGin5G Gateway UE is a URI, the Uri-Path Option is set to the value of such URI;
c) shall set the "Content-Format" element to "50" to indicate the format of the CoAP payload is "application/json"; and
d) shall include the following information elements in the CoAP payload encoded in JSON format:
1) the "MSGin5G service identifier" element to indicate that this CoAP POST request is used for MSGin5G service;
2) the "Message Type" element to indicate that the CoAP POST request is used for de-registration; and
3) the "Registration ID" element to indicate which has been allocated by the MSGin5G Gateway UE during the registration procedure.
A.3.1.10 De-registration Response
The de-registration response sent by the MSGin5G Client of the MSGin5G Gateway UE to the Application Client of the Constrained UE is based on the CoAP 2.01 (Created) response or CoAP 2.04 (Change) response as specified in IETF RFC 7252 [5]. The Application Client of the Constrained UE:
a) shall include the CoAP "Message ID" element and the "Token" element with the same values with those in the CoAP POST request for de-registration; and
b) shall include the "Content-Format" element with "50" to indicate the format of the CoAP payload is "application/json". The CoAP payload:
1) shall include the "De-registration Result" element to indicate whether the de-registration is success or failure;
2) shall include the "Registration ID" element allocated by the MSGin5G Client of the MSGin5G Gateway UE if the value of "De-registration Result" element is set to true; and
3) shall include the "Failure Reason" element to indicate why the de-registration request is rejected by the MSGin5G Client of the MSGin5G Gateway UE if the value of "de-registration Result" element is set to false.
A.3.2 JSON Schema
A.3.2.1 for sending a message to MSGin5G Client
The JSON schema for application client sending message is defined below:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "http://www.3gpp.org/MSGin5G/MSGin5G_APP_Message_schema",
"title": "APP Message",
"type": "object",
"properties": {
"msgType": {
"type": "string",
"enum": [
"MESSAGE SENDING REQEUST"
],
"description": " Refer to Message Type, it indicates the usage of this message. The value MESSAGE SENDING REQEUST refers to message sending"
},
"appId": {
"type": "string",
"description": "Refer to Application ID"
},
"msgId": {
"type": "string",
"format": "uuid",
"description": "Refer to Message ID"
},
"isDelivStatReq": {
"type": "boolean",
"default": false,
"description": "Refer to Delivery Status Required"
},
"destAddr": {
"type": "object",
"properties": {
"destAddrType": {
"enum": [
"UE",
"AS",
"GROUP"
],
"description": "the target type"
},
"addr": {
"type": "string",
"description": "the target address"
}
}
},
"payload": {
"type": "string",
"description": "Refer to Payload"
},
},
"required": [
"msgId",
"destAddr",
"payload"
]
}
A.3.2.2 for sending a message delivery report to MSGin5G Client
The JSON schema for application client sending message delivery status report is defined below:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "http://www.3gpp.org/MSGin5G/MSGin5G_APP_Delivery REPORT_schema",
"title": "APP_Delivery REPORT",
"type": "object",
"properties": {
"msgType": {
"type": "string",
"enum": [
"DELIVERY REPORT SENDING REQEUST"
],
"description": " Refer to Message Type, it indicates the usage of this message. The value DELIVERY REPORT SENDING REQEUST refers to message delivery status report sending"
},
"msgId": {
"type": "string",
"format": "uuid",
"description": "Refer to Message ID indicating unique identity of this message delivery report"
},
"reply2msgId": {
"type": "string",
"format": "uuid",
"description": "Refer to Reply-to Message ID indicating which message the delivery status report is for"
},
"deliveryStatus": {
"enum": [
"SUCCESS",
"FAILED"
],
"description": "Refer to delivery status"
}
},
"required": [
"msgId",
"deliveryStatus",
"msgType"
]
}
A.3.2.3 for sending a message to Application Client
The JSON schema for MSGin5G client sending message to Application Client is defined below:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "http://www.3gpp.org/MSGin5G/MSGin5G_Messsage-to-APP_schema",
"title": "Message to APP",
"type": "object",
"properties": {
"msgType": {
"type": "string",
"enum": [
"MESSAGE RECEIVED REQEUST"
],
"description": " Refer to Message Type indicating the usage of this message. The value MESSAGE RECEIVED REQEUST refers to sending message to a application client"
},
"msgId": {
"type": "string",
"format": "uuid",
"description": "Refer to Message ID indicating which message is for"
},
"oriAddr": {
"type": "string",
"description": "Refer to the Originator Address indicating the originating group if the message is a group message"
},
"groupId": {
"type": "string",
"description": "Refer to the Group ID indicating the originating UE or AS"
},
"payload": {
"type": "string",
"description": "Refer to Payload"
},
"isDelivStatReq": {
"type": "boolean",
"default": false,
"description": "Refer to Delivery Status Required"
},
"priority": {
"type": "string",
"enum": [
"HIGH",
"MEDIUM",
"LOW"
],
"default": "MIDDLE",
"description": "Refer to Priority Type"
},
},
"required": [
"msgId",
"msgType",
"payload"
]
}
A.3.2.4 for sending a message delivery report to Application Client
The JSON schema for MSGin5G client sending message delivery status report to Application Client is defined below:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "http://www.3gpp.org/MSGin5G/MSGin5G_Delivery-Report-to-APP schema",
"title": "Delivery report to APP",
"type": "object",
"properties": {
"msgType": {
"type": "string",
"enum": [
"DELIVERY REPORT RECEIVED REQUEST"
],
"description": " Refer to Message Type indicating the usage of this message. The value DELIVERY REPORT RECEIVED REQUEST refers to sending a message delivery status report to Application Client"
},
"msgId": {
"type": "string",
"format": "uuid",
"description": "Refer to Message ID indicating unique identity of this message delivery report"
},
"reply2msgId": {
"type": "string",
"format": "uuid",
"description": "Refer to Reply-to Message ID indicating which message the delivery status report is for"
},
"deliveryStatus": {
"type": "string",
"enum": [
"SUCCESS",
"FAILED"
],
"description": "Refer to delivery status"
}
},
"required": [
"msgId",
"deliveryStatus",
"msgType"
]
}
A.3.2.5 for sending a message sending response to Application Client
The JSON schema for MSGin5G client sending message sending response to Application Client is defined below:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "http://www.3gpp.org/MSGin5G/MSGin5G_Message-Sending-Response schema",
"title": "Delivery message sending response to APP",
"type": "object",
"properties": {
"msgType": {
"type": "string",
"enum": [
"MESSAGE SENDING RESPONSE"
],
"description": " Refer to Message Type indicating the usage of this message. The value MESSAGE SENDING RESPONSE refers to the resonse for the message sending of a Application Client"
},
"failReason": {
"type": "string",
"description": "Refer to the failure reason"
},
"result": {
"type": "string",
"enum": [
"SUCCESS",
"FAILED"
],
"description": "Refer to the result"
}
},
"required": [
"result",
"msgType"
]
}
A.3.2.6 for sending a message received response to MSGin5G Client
The JSON schema for Application client sending message received response to MSGin5G Client is defined below:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "http://www.3gpp.org/MSGin5G/MSGin5G_ Message-Received-Response schema",
"title": "Delivery message received response to MSGin5G Client",
"type": "object",
"properties": {
"msgType": {
"type": "string",
"enum": [
"MESSAGE RECEIVED RESPONSE"
],
"description": " Refer to Message Type indicating the usage of this message. The value MESSAGE RECEIVED RESOPNSE refers to sending a response for receiving a message from MSGin5G Client"
},
"failReason": {
"type": "string",
"description": "Refer to the failure reason"
},
"result": {
"type": "string",
"enum": [
"SUCCESS",
"FAILED"
],
"description": "Refer to the result"
}
},
"required": [
"result",
"msgType"
]
}
A.3.2.7 Registration structure
The schema is based on JSON Schema Draft-07 [8]. For reducing the overhead of the message used in MSGin5G service, the properties are defined as shorten form and the relationships between the properties and elements used in clause A.3.1.7 are described in the description of the properties. The JSON schema of the CoAP POST request for the MSGin5G registration is defined below:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "http://www.3gpp.org/MSGin5G/MSGin5G_Registration_request_schema",
"title": "MSGin5G Registration Request",
"type": "object",
"properties": {
"msgIden": {
"type": "string",
"format": "uri",
"description": "Refer to Service identifier of MSGin5G service"
},
"msgType": {
"type": "string",
"enum": [
"REG"
],
"description": "Refer to the usage of this message. The value REG refers to MSGin5G Registration"
},
"appId": {
"type": "string",
"description": "Refer to Application ID"
},
"credential": {
"type": "string",
"description": "Refer to Credential Information"
}
},
"required": [
"msgId",
"msgType",
"l2ID",
"appID",
"credential"
]
}
The schema is based on JSON Schema Draft-07 [8]. For reducing the overhead of the message used in MSGin5G service, the properties are defined as shorten form and the relationships between the properties and elements used in clause A.3.1.8 are described in the description of the properties. The JSON schema of CoAP 2.01 (Created) response or CoAP 2.04 (Change) response for the MSGin5G registration is defined below:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "http://www.3gpp.org/MSGin5G/MSGin5G_Registration_response_schema",
"title": "MSGin5G Registration Response",
"type": "object",
"properties": {
"result": {
"type": "boolean",
"default": true,
"description": "Refer to Registration result. The value true refers to succcess"
},
"registration ID": {
"type": "string",
"description": "Refer to Regsitration ID"
},
"failure reason": {
"type": "string",
"description": "Refer to Failure Reason"
}
},
"required": [
"result"
]
}
A.3.2.8 De-registration structure
The schema is based on JSON Schema Draft-07 [8]. For reducing the overhead of the message used in MSGin5G service, the properties are defined as shorten form and the relationships between the properties and elements used in clause A.3.1.9 are described in the description of the properties. The JSON schema of the CoAP POST request for the MSGin5G de-registration is defined below:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "http://www.3gpp.org/MSGin5G/MSGin5G_Deregistration_request_schema",
"title": "MSGin5G Deregistration Request",
"type": "object",
"properties": {
"msgIden": {
"type": "string",
"format": "uri",
"description": "Refer to Service identifier of MSGin5G service"
},
"msgType": {
"type": "string",
"enum": [
"DEREG"
],
"description": "Refer to the usage of this message. The value DEREG refers to MSGin5G De-registration"
},
"registrationID": {
"type": "string",
"description": "Refer to Registration ID"
}
},
"required": [
"msgId",
"msgType",
"RegistrationID"
]
}
The schema is based on JSON Schema Draft-07 [8]. For reducing the overhead of the message used in MSGin5G service, the properties are defined as shorten form and the relationships between the properties and elements used in clause A.3.1.10 are described in the description of the properties. The JSON schema of CoAP 2.01 (Created) response or CoAP 2.04 (Change) response for the MSGin5G de-registration is defined below:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "http://www.3gpp.org/MSGin5G/MSGin5G_Deregistration_response_schema",
"title": "MSGin5G Deregistration Response",
"type": "object",
"properties": {
"result": {
"type": "boolean",
"default": true,
"description": "Refer to Registration result. The value true refers to succcess"
},
"registration ID": {
"type": "string",
"description": "Refer to Registration ID"
},
"failure reason": {
"type": "string",
"description": "Refer to Failure Reason"
}
},
"required": [
"result"
]
}
Annex X (Informative):
IANA UDP port registration form
This annex contains information to be provided to IANA for exchange of CoAP protocol messages used between MSGin5G clients acting as a realy on UEs UDP port registration or MSGin5G RelayProtocol (MSGin5GRP). The following information is to be used to register CoAPRP user port number and service name in the "IANA Service Name and Transport Protocol Port Number Registry" and specifically "Service Name and Transport Protocol Port Number Registry". This registration form can be found at: https://www.iana.org/form/ports-services.
|
Assignee Name |
<MCC name> |
|
Assignee E-mail |
<MCC email address> |
|
Contact Person |
<MCC name> |
|
Contact E-mail |
<MCC email address> |
|
Resources required |
Port number and service name |
|
Transport Protocols |
UDP |
|
Service Code |
|
|
Service Name |
MSGin5GRP |
|
Desired Port Number |
|
|
Description |
Message Service within the 5G System (MSGin5G) RelayProtocol (MSGin5GRP) is a 3GPP control protocol used by MSGin5G client acting as a relay hosted on a User Equipment (UE) for when the MSGin5G client resides in a UE, which does not have enough capability to communicate with a MSGin5G Server (i.e. a constrained device). MSGin5GRP provides MSGin5G functionality between MSGin5G clients hosted on UEs communicating using IP using a single physical network segment, separated from Internet and any other IP network. The network segment is wireless network segment and UEs are mobile devices. |
|
Reference |
3GPP TS 24.538 |
|
Defined TXT keys |
N/A |
|
If broadcast/multicast is used, how and what for? |
The MSGin5G supports group and broadcast message delivery for thing-to-thing communication and person-to-thing communication. When performing group calls, the MSGin5G client initiates the group call to an MSGin5G group by sending a group call announcement message based on Service Enabler Architecture Layer for Verticals (SEAL) group management. The group call announcement message is an MSGin5GRP message which is sent as a UDP message to a multicast IP address of the MSGin5G group so that it is ensured that the MSGin5GRP messages sent for the corresponding MSGin5G group are only received by the MSGin5G group’s members. |
|
If UDP is requested, please explain how traffic is limited, and whether the protocol reacts to congestion. |
The number of MSGin5GRP messages that need to be sent between MSGin5GRP clients depends upon the number of members of the MSGin5G group. MSGin5GRP employs a message control mechanism which includes a back-off mechanism to defer transmission of another MSGin5GRP message once an MSGin5GRP message is received. MSGin5GRP controls the number of messages transmitted within a certain, configurable amount of time, thus averting congestion. At maximum a few SLMP messages per second are expected in communication between MSGin5GRP clients. MSGin5GRP does not support any reaction to congestion. |
|
If UDP is requested, please indicate whether the service is solely for the discovery of hosts supporting this protocol. |
MSGin5GRP is not used solely for discovery of hosts supporting this protocol. |
|
Please explain how your protocol supports versioning. |
MSGin5GRP does not support versioning. |
|
If your request is for more than one transport, please explain in detail how the protocol differs over each transport. |
N/A |
|
Please describe how your protocol supports security. Note that presently there is no IETF consensus on when it is appropriate to use a second port for an insecure version of a protocol. |
MSGin5GRP does not support security. MSGin5GRP relies on the security mechanisms of the lower layers. |
|
Please explain why a unique port assignment is necessary as opposed to a port in range (49152-65535) or existing port. |
As a general principle, 3GPP protocols use assigned User Ports, e.g. GTP-C uses UDP port number 2123, GTP-U uses UDP port number 2152, S1AP uses SCTP port number 36412, X2AP uses SCTP port number 36422, WLCP uses 36411. A dynamic port number (i.e. 49152 to 65535) cannot be used for the MSGin5GRP because of the nature of communication on a single physical network segment, separated from Internet and any other IP network. The requirement of MSGin5GRP to continuously listen for incoming messages needs an always active listener port. There is no local server that is administering the use of emphemeral ports in the MSGin5GRP architecture, so there would be no way for one MSGin5GR client acting as a relay to know that a port is already being used by another MSGin5GRP client. |
|
Please explain the state of development of your protocol. |
Protocol standard definition. No implementation exists yet. |
|
If SCTP is requested, is there an existing TCP and/or UDP service name or port number assignment? If yes, provide the existing service name and port number. |
N/A |
|
What specific SCTP capability is used by the application such that a user who has the choice of both TCP (and/or UDP) and SCTP ports for this application would choose SCTP? See RFC 4960 section 7.1. |
N/A |
|
Please provide any other information that would be helpful in understanding how this protocol differs from existing assigned services |
This protocol is between the UEs communicating using IP over a single physical network segment, separated from Internet and any other IP network. MSGin5GRP functionality offered by the MSGin5GRP clients acting as a relay hosted by the UEs is to messaging communication capability in 5GS especially for Massive Internet of Things (MIoT). The need of listening for incoming messages requires an active listener port. This differs from existing protocols in 3GPP where UDP ports have been requested, as those protocols have been either between the UE and network or between network elements. |
Annex C (informative):
Change history
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2021-10 |
CT1#132e |
C1-216109 |
Draft skeleton provided by the rapporteur. |
0.0.0 |
|||
|
2021-10 |
CT1#132e |
Implementing the following p-CR agreed by CT1: Editorial change from the rapporteur. Correction from the rapporteur. |
0.1.0 |
||||
|
2021-11 |
CT1#133e |
Implementing the following p-CR agreed by CT1: Editorial change from the rapporteur. Correction from the rapporteur. |
0.2.0 |
||||
|
2021-12 |
Editorial change from the rapporteur. Correction from the rapporteur. |
0.2.1 |
|||||
|
2022-01 |
CT1#133 BIS-e |
Implementing the following p-CR agreed by CT1: Editorial change from the rapporteur. Correction from the rapporteur. |
0.3.0 |
||||
|
2022-03 |
CT1#134-e |
Implementing the following p-CR agreed by CT1: Editorial change from the rapporteur. Correction from the rapporteur. |
0.4.0 |
||||
|
2022-03 |
CT#95e |
CP-220316 |
TS presented for information |
1.0.0 |
|||
|
2022-04 |
CT1#135-e |
Implementing the following p-CR agreed by CT1: C1-222958, C1-222960, C1-222961, C1-223102, C1-223103, C1-223111, C1-223112, C1-223113, C1-223114, C1-223115, C1-223116, C1-223117 Editorial change from the rapporteur. Correction from the rapporteur. |
1.1.0 |
||||
|
2022-05 |
CT1#136-e |
Implementing the following p-CR agreed by CT1: C1-223644, C1-223646, C1-223647, C1-223650, C1-223651, C1-224040, C1-224041, C1-224042, C1-223854, C1-223855, C1-224051, C1-223857, C1-223860, C1-224161, C1-224165, C1-223864, C1-223867, C1-223868, C1-224167, C1-224172, C1-223873, C1-224173, C1-224175 Editorial change from the rapporteur. Correction from the rapporteur. |
1.2.0 |
||||
|
2022-06 |
CT#96 |
CP-221191 |
TS presented for approval |
2.0.0 |
|||
|
2022-06 |
CT#96 |
TS approved in TSG CT plenary |
17.0.0 |
||||
|
2022-09 |
CT#97e |
CP-222154 |
0001 |
– |
F |
Correct the length of Application ID |
17.1.0 |
|
2022-09 |
CT#97e |
CP-222154 |
0002 |
– |
F |
Remove the redundant IE codec |
17.1.0 |
|
2022-09 |
CT#97e |
CP-222154 |
0003 |
1 |
F |
Add the coding of Credential information IE |
17.1.0 |
|
2022-09 |
CT#97e |
CP-222154 |
0004 |
– |
F |
Adding the reference to TS 23.003 for FQDN |
17.1.0 |
|
2022-09 |
CT#97e |
CP-222154 |
0005 |
1 |
F |
Differentiate the functionalities and procedures between MSGin5G Gateway UE and MSGin5G Relay UE |
17.1.0 |
|
2022-09 |
CT#97e |
CP-222154 |
0006 |
1 |
F |
Correction of Layer-2 ID |
17.1.0 |
|
2022-09 |
CT#97e |
CP-222154 |
0007 |
– |
F |
Adding the reference to RFC 4122 |
17.1.0 |
|
2022-09 |
CT#97e |
CP-222154 |
0008 |
1 |
F |
Clarify how to generate the Recipient UE Service ID/AS Service ID for constrained UE |
17.1.0 |
|
2022-09 |
CT#97e |
CP-222154 |
0009 |
1 |
F |
MSGin5G Client splits the aggregated message |
17.1.0 |
|
2022-09 |
CT#97e |
CP-222154 |
0010 |
1 |
F |
Editorial corrections |
17.1.0 |
|
2022-12 |
CT#98e |
CP-223150 |
0011 |
F |
Correct the term of “Constrained device” to “Constrained UE” |
17.2.0 |
|
|
2022-12 |
CT#98e |
CP-223150 |
0012 |
1 |
F |
Corrections of the L3 message format |
17.2.0 |
|
2022-12 |
CT#98e |
CP-223150 |
0013 |
F |
Add a missing value of the Message Type IE |
17.2.0 |
|
|
2022-12 |
CT#98e |
CP-223150 |
0014 |
F |
Add the IE of Spare half octet |
17.2.0 |
|
|
2022-12 |
CT#98e |
CP-223150 |
0015 |
1 |
F |
Correct the coding of Target Address IE |
17.2.0 |
|
2022-12 |
CT#98e |
CP-223150 |
0016 |
F |
Remove the restriction of the L3 message transport |
17.2.0 |
|
|
2022-12 |
CT#98e |
CP-223150 |
0017 |
F |
Editoral corrections of procedures |
17.2.0 |
|
|
2022-12 |
CT#98e |
CP-223150 |
0018 |
1 |
F |
IANA Registration form for UDP Port number |
17.2.0 |
|
2022-12 |
CT#98e |
CP-223150 |
0021 |
1 |
D |
SEAL terms in 24.538 aligned with 24.546 |
17.2.0 |
|
2022-12 |
CT#98e |
CP-223150 |
0022 |
1 |
F |
Add a missing functionality of the MSGin5G Client |
17.2.0 |
|
2022-12 |
CT#98e |
CP-223150 |
0023 |
1 |
F |
Editoral corrections of procedures |
17.2.0 |