| Interoperability Test Description |
| Identifier: |
TD_COAP_BLOCK_01
|
| Objective: |
Handle GET blockwise transfer for large resource (early negotiation)
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
[BLOCK] 2.2–2.4
|
| Pre-test conditions: |
- Client supports Block2 transfers
- Server supports Block2 transfers
- Server offers a large resource /large
- Client knows /large requires block transfer
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to retrieve resource /large
|
|
2
|
Check
|
Client sends a GET request. The request contains a Block2 option indicating:- NUM = 0;
- M = 0;
- SZX (➔DES_SZX) is the desired block size.
|
|
3
|
Check
|
Server sends 2.05 (Content) response with a Block2 option indicating:- NUM = 0;
- M = 1;
- SZX (➔ACT_SZX) is less than or equal to DES_SZX.
Payload size is 2**(SZX+4) bytes.
|
|
Start of loop
|
|
4
|
Check
|
Client send GET requests for further blocks indicating:- NUM = i where “i” is the block number of the current block;
- M = 0;
- SZX is ACT_SZX.
|
|
5
|
Check
|
Server sends 2.05 (Content) response containing Block2 option indicating:- NUM = i where “i” is the block number used at step 4;
- M = 1;
- SZX is ACT_SZX.
Payload size is 2**(SZX+4) bytes.
|
|
end of loop; final slice:
|
|
6
|
Check
|
Client send GET request for the last block indicating:- NUM = n where “n” is the last block number;
- M = 0;
- SZX is ACT_SZX.
|
|
7
|
Check
|
Server sends 2.05 (Content) response with a Block2 option indicating:- NUM = n where “n” is the block number used at step 6;
- M = 0;
- SZX is ACT_SZX.
Payload size is less than or equal to 2**(SZX+4) bytes.
|
|
8
|
Verify
|
Client displays the received information (no gaps, right order)
|
Notes:
|
Steps 4 and 5 are in a loop.
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_BLOCK_02
|
| Objective: |
Handle GET blockwise transfer for large resource (late negotiation)
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
[BLOCK] 2.2–2.4
|
| Pre-test conditions: |
- Client supports Block2 transfers
- Server supports Block2 transfers
- Server offers a large resource /large
- Client does not know /large requires block transfer
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to retrieve resource /large
|
|
2
|
Check
|
Client sends a GET request not containing a Block2 option
|
|
3
|
Check
|
Server sends 2.05 (Content) response with a Block2 option indicating:- NUM = 0;
- M = 1;
- SZX (➔DES_SZX) is the desired block size.
Payload size is 2**(SZX+4) bytes.
|
|
4
|
Check
|
Client switches to blockwise transfer mode and sends a GET request with a Block2 option indicating:- NUM is the next block number k = (2**(DES_SZX – ACT_SZX));
- M = 0;
- SZX (➔ACT_SZX) is less than or equal to DES_SZX.
|
|
5
|
Check
|
Server sends 2.05 (Content) response with a Block2 option indicating:- NUM = k where “k” is the block number used at step 4;
- M = 1;
- SZX is ACT_SZX.
Payload size is 2**(SZX+4) bytes.
|
|
Start of loop
|
|
6
|
Check
|
Client sends GET request for further blocks indicating:- NUM = i where “i” is the block number of the current block;
- M = 0;
- SZX is ACT_SZX.
|
|
7
|
Check
|
Server sends 2.05 (Content) response with a Block2 option indicating:- NUM = i where “i” is the block number used at step 6;
- M = 1;
- SZX is ACT_SZX.
Payload size is 2**(SZX+4) bytes.
|
|
end of loop; final slice:
|
|
8
|
Check
|
Client send GET request for the last block indicating:- NUM = n where “n” is the last block number;
- M = 0;
- SZX is ACT_SZX.
|
|
9
|
Check
|
Server sends 2.05 (Content) response with a Block2 option indicating:- NUM = n where “n” is the block number used at step 8;
- M = 0;
- SZX is ACT_SZX.
Payload size is less than or equal to 2**(SZX+4) bytes.
|
|
10
|
Verify
|
Client displays the received information
|
Notes:
|
Steps 6 and 7 are in a loop.
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_BLOCK_03
|
| Objective: |
Handle PUT blockwise transfer for large resource
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
[BLOCK] 2.2, 2.3, 2.5
|
| Pre-test conditions: |
- Client supports Block1 transfers
- Server supports Block1 transfers
- Server offers a large updatable resource /large-update
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to update resource /large-update on Server
|
|
2
|
Check
|
Client sends a PUT request containing Block1 option indicating:- NUM = 0;
- M = 1;
- SZX (➔DES_SZX) is the desired block size.
Payload size is 2**(SZX+4) bytes.
|
|
3
|
Check
|
Server sends 2.04 (Changed) or 2.31 (Continue) response with a Block1 option indicating:- NUM = 0;
- M = 0 (stateless, for 2.04) or 1 (atomic, for 2.31);
- SZX (➔ACT_SZX) is less than or equal to DES_SZX.
|
|
Start of loop
|
|
4
|
Check
|
Client sends further requests containing Block1 option indicating:- NUM = i where “i” is the block number of the current block. If the server decreased the SZX parameter in step 3, then the client needs to adapt the block size accordingly and resume the transfer from block number 2**(ACT_SZX – DES_SZX) instead of block 1.
- M = 1;
- SZX is ACT_SZX.
Payload size is 2**(SZX+4) bytes.
|
|
5
|
Check
|
Server sends 2.04 (Changed) or 2.31 (Continue) response with a Block1 option indicating:- NUM = i where “i” is the block number used at step 4;
- M = 0 (stateless, for 2.04) or 1 (atomic, for 2.31);
- SZX is ACT_SZX.
|
|
end of loop; final slice:
|
|
6
|
Check
|
Client send PUT request containing the last block and indicating:- NUM = n where “n” is the last block number;
- M = 0;
- SZX is ACT_SZX.
Payload size is less than or equal to 2**(SZX+4) bytes.
|
|
7
|
Check
|
Server sends 2.04 (Changed) response with a Block1 option indicating:- NUM = n where “n” is the block number used at step 6;
- M = 0;
- SZX is ACT_SZX.
|
|
8
|
Verify
|
Server indicates presence of the complete updated resource /large-update
|
Notes:
|
Steps 4 and 5 are in a loop.
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_BLOCK_04
|
| Objective: |
Handle POST blockwise transfer for creating large resource
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
[BLOCK] 2.2, 2.3, 2.5
|
| Pre-test conditions: |
- Client supports Block1 transfers
- Server supports Block1 transfers
- Server accepts creation of new resources on /large-create
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to create a new resource /large-create on Server
|
|
2
|
Check
|
Client sends a POST request containing Block1 option indicating:- NUM = 0;
- M = 1 (more);
- SZX (➔DES_SZX) is the desired block size.
Payload size is 2**(SZX+4) bytes.
|
|
3
|
Check
|
Server sends 2.31 (Continue) response containing Block1 option indicating:- NUM = 0;
- M = 1 (atomic);
- SZX (➔ACT_SZX) is less or equal to DES_SZX.
|
|
Start of loop
|
|
4
|
Check
|
Client sends further POST requests containing Block1 option indicating:- NUM = i where “i” is the block number of the current block. If the server decreased the SZX parameter in step 3, then the client needs to adapt the block size accordingly and resumes the transfer from block number 2**(DES_SZX - ACT_SZX) instead of block 1.
- M = 1 (more);
- SZX is ACT_SZX.
Payload size is 2**(SZX+4) bytes.
|
|
5
|
Check
|
Server sends 2.31 (Continue) response containing Block1 option indicating:- NUM = i where “i” is the block number used at step 4;
- M = 1 (atomic);
- SZX is ACT_SZX
|
|
end of loop; final slice:
|
|
6
|
Check
|
Client sends POST request containing the last block and indicating:- NUM = n where “n” is the last block number;
- M = 0 (final);
- SZX is ACT_SZX.
Payload size is less than or equal to 2**(SZX+4) bytes.
|
|
7
|
Check
|
Server sends 2.01 (Created) response containing Block1 option indicating:- NUM = n where “n” is the block number used at step 6;
- M = 0 (final);
- SZX is ACT_SZX.
and Location-Path options, e.g. if the new location is "/large-create/PS":- First option value must contain “large-create”
- Second option value is a (single) path segment chosen by the server (PS)
- none of the Location-Path options contain a ‘/’
|
|
8
|
Verify
|
Client displays the response
|
|
9
|
Verify
|
Server indicates presence of the complete new resource, e.g., /large-create/PS
|
|
verify resource creation (optional):
|
|
10
|
Check
|
Client sends GET request to new location (e.g., "/large-create/PS", i.e., using Uri-Path options simply copied from the Location-Path of step 7)
|
|
11
|
Check
|
Server sends 2.05 (Content) response with representation of created resource, potentially making use of the Block2 protocol
|
|
12
|
Verify
|
Client indicates the value of the newly created resource
|
Notes:
|
Steps 4 and 5 are in a loop.
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_BLOCK_05
|
| Objective: |
Handle POST with two-way blockwise transfer
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
[BLOCK] 2.2, 2.3, 2.5
|
| Pre-test conditions: |
- Client supports Block1 and Block2 transfers
- Server supports Block1 and Block2 transfers
- Server accepts large post requests on /large-post
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to send a large represenation to /large-post on Server
|
|
2
|
Check
|
Client sends a POST request containing Block1 option indicating:- NUM = 0;
- M = 1 (more);
- SZX (➔DES_SZX) is the desired block size.
Payload size is 2**(SZX+4) bytes.
|
|
3
|
Check
|
Server sends 2.31 (Continue) response containing Block1 option indicating:- NUM = 0;
- M = 1 (atomic);
- SZX (➔ACT_SZX) is less or equal to DES_SZX.
|
|
Start of loop
|
|
4
|
Check
|
Client sends further POST requests containing Block1 option indicating:- NUM = i where “i” is the block number of the current block. If the server decreased the SZX parameter in step 3, then the client needs to adapt the block size accordingly and resumes the transfer from block number 2**(DES_SZX - ACT_SZX) instead of block 1.
- M = 1 (more);
- SZX is ACT_SZX.
Payload size is 2**(SZX+4) bytes.
|
|
5
|
Check
|
Server sends 2.31 (Continue) response containing Block1 option indicating:- NUM = i where “i” is the block number used at step 4;
- M = 1 (atomic);
- SZX is ACT_SZX
|
|
end of loop; final request slice and first response slice:
|
|
6
|
Check
|
Client sends POST request containing the last block and indicating:- NUM = n where “n” is the last block number;
- M = 0 (final);
- SZX is ACT_SZX.
Payload size is less than or equal to 2**(SZX+4) bytes.
|
|
7
|
Check
|
Server sends 2.04 (Changed) response containing Block1 option indicating:- NUM = n where “n” is the block number used at step 6;
- M = 0 (final);
- SZX is ACT_SZX.
and a Block2 option indicating:- NUM = 0
- M = 1 (more);
- SZX (➔rDES_SZX) is the desired block size.
Payload size is 2**(SZX+4) bytes.
|
|
8
|
Check
|
Client switches to blockwise retrieval of response and sends a POST request, with the same options except for Block1, without payload, with a Block2 option indicating:- NUM is the next block number k = (2**(rDES_SZX – rACT_SZX));
- M = 0;
- SZX (➔rACT_SZX) is less than or equal to rDES_SZX.
|
|
9
|
Check
|
Server sends 2.04 (Changed) response with a Block2 option indicating:- NUM = k where “k” is the block number used at step 8;
- M = 1;
- SZX is rACT_SZX.
Payload size is 2**(SZX+4) bytes.
|
|
Start of retrieval loop
|
|
10
|
Check
|
Client sends a similar POST request for retrieving a further block indicating:- NUM = i where “i” is the block number of the current block;
- M = 0;
- SZX is rACT_SZX.
|
|
11
|
Check
|
Server sends 2.04 (Changed) response with a Block2 option indicating:- NUM = i where “i” is the block number used at step 10;
- M = 1;
- SZX is rACT_SZX.
Payload size is 2**(SZX+4) bytes.
|
|
end of retrieval loop; final slice:
|
|
12
|
Check
|
Client sends another POST request (which will retrieve the last block) indicating:- NUM = n where “n” is the last block number;
- M = 0;
- SZX is rACT_SZX.
|
|
13
|
Check
|
Server sends 2.04 (Changed) response with a Block2 option indicating:- NUM = n where “n” is the block number used at step 12;
- M = 0;
- SZX is rACT_SZX.
Payload size is less than or equal to 2**(SZX+4) bytes.
|
|
14
|
Verify
|
Client displays the response
|
Notes:
|
- Steps 4 and 5 are in a loop.
- Steps 10 and 11 are in a loop.
- There is no initiative change in block-13.
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_BLOCK_06
|
| Objective: |
Handle GET blockwise transfer for large resource (early negotiation, 16 byte block size)
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
[BLOCK] 2.2–2.4
|
| Pre-test conditions: |
- Client supports Block2 transfers
- Server supports Block2 transfers
- Server offers a large resource /large
- Client knows /large requires block transfer
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to retrieve resource /large
|
|
2
|
Check
|
Client sends a GET request. The request contains a Block2 option indicating:- NUM = 0;
- M = 0;
- SZX (➔DES_SZX) is the desired block size.
|
|
3
|
Check
|
Server sends 2.05 (Content) response with a Block2 option indicating:- NUM = 0;
- M = 1;
- SZX (➔ACT_SZX) is less than or equal to DES_SZX.
Payload size is 2**(SZX+4) bytes.
|
|
Start of loop
|
|
4
|
Check
|
Client send GET requests for further blocks indicating:- NUM = i where “i” is the block number of the current block;
- M = 0;
- SZX is ACT_SZX.
|
|
5
|
Check
|
Server sends 2.05 (Content) response containing Block2 option indicating:- NUM = i where “i” is the block number used at step 4;
- M = 1;
- SZX is ACT_SZX.
Payload size is 2**(SZX+4) bytes.
|
|
end of loop; final slice:
|
|
6
|
Check
|
Client send GET request for the last block indicating:- NUM = n where “n” is the last block number;
- M = 0;
- SZX is ACT_SZX.
|
|
7
|
Check
|
Server sends 2.05 (Content) response with a Block2 option indicating:- NUM = n where “n” is the block number used at step 6;
- M = 0;
- SZX is ACT_SZX.
Payload size is less than or equal to 2**(SZX+4) bytes.
|
|
8
|
Verify
|
Client displays the received information (no gaps, right order)
|
Notes:
|
Steps 4 and 5 are in a loop.
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_OBS_01
|
| Objective: |
Handle resource observation with CON messages
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
[OBSERVE] 1.2, 3, 4
|
| Pre-test conditions: |
- Client supports Observe option
- Server supports Observe option
- Server offers an observable resource /obs which changes periodically (e.g. every 5s) which produces confirmable notifications
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to send to the server a confirmable GET request with observe option for resource /obs
|
|
2
|
Check
|
The request sent by client contains:- Type = 0 (CON)
- Code = 1 (GET)
- Token value ➔ t, a value generated by the client
- Observe option = empty
|
|
3
|
Check
|
Server sends the response containing:- Type = 2 (ACK)
- Code = 2.05 (Content)
- Content-format of the resource /obs, ➔ f
- Token value = t, same as one found in the step 2
- Observe option with a sequence number
|
|
After some time elapses, repeatedly:
|
|
4
|
Check
|
Server sends a notification containing:- Type = 0 (CON)
- Code = 2.05 (Content)
- Content-format = f, same as one found in the step 3
- Token value = t, same as one found in the step 3
- Observe option indicating increasing values (sequence number arithmetic modulo 2**24), unless more than 256 seconds elapsed
|
|
5
|
Check
|
Client sends an ACK
|
|
6
|
Verify
|
Client displays the received information
|
Notes:
|
Steps 4-6 are in a loop.
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_OBS_02
|
| Objective: |
Handle resource observation with NON messages
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
[OBSERVE] 1.2, 3, 4
|
| Pre-test conditions: |
- Client supports Observe option
- Server supports Observe option
- Server offers an observable resource /obs-non which changes periodically (e.g. every 5s) which produces non-confirmable notifications
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to send to the server a non-confirmable GET request with observe option for resource /obs-non
|
|
2
|
Check
|
The request sent by client contains:- Type = 1 (NON)
- Code = 1 (GET)
- Token value ➔ t, a value generated by the client
- Observe option = empty
|
|
After some time elapses, repeatedly:
|
|
3
|
Check
|
Server sends a notification containing:- Type = 1 (NON)
- Code = 2.05 (Content)
- Content-format = the same for all notifications
- Token value = t, same as one found in the step 2
- Observe option indicating increasing values (sequence number arithmetic modulo 2**24), unless more than 256 seconds elapsed
|
|
4
|
Verify
|
Client displays the received information
|
Notes:
|
- Steps 3-4 are in a loop.
- We don't run the test long enough to invoke the 24-hour rule in [OBSERVE] 4.5, but in step 4 the server could still occasionally send a confirmable message, which then needs to be acknowledged by the client
- (The request in step 2 could as well be a confirmable request.)
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_OBS_04
|
| Objective: |
Client detection of deregistration (Max-Age)
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
[OBSERVE] 3.3.1 §4
|
| Pre-test conditions: |
- Client supports Observe option
- Server supports Observe option
- Server offers an observable resource /obs which changes periodically (e.g. every 5s) which produces confirmable notifications
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to send to the server a confirmable GET request with observe option for resource /obs
|
|
2
|
Check
|
The request sent by client contains:- Type = 0 (CON)
- Code = 1 (GET)
- Token value ➔ t, a value generated by the client
- Observe option = empty
|
|
3
|
Check
|
Server sends the response containing:- Type = 2 (ACK)
- Code = 2.05 (Content)
- Content-format of the resource /obs, ➔ f
- Token value = t, same as one found in the step 2
- Observe option with a sequence number
|
|
4
|
Check
|
Server sends a notification containing:- Type = 0 (CON)
- Code = 2.05 (Content)
- Content-format = f, same as one found in the step 3
- Token value = t, same as one found in the step 2
- Observe option indicating increasing values (sequence number arithmetic modulo 2**24), unless more than 256 seconds elapsed
|
|
5
|
Verify
|
Client displays the received information
|
|
6
|
Check
|
Client sends an ACK
|
|
forcibly remove the observation relationship from the server
|
|
7
|
Stimulus
|
Server is rebooted or in another way caused to lose its observation state
|
|
8
|
Check
|
Server does not send notifications
|
|
9
|
Verify
|
Client does not display updated information
|
|
Client re-registers
|
|
10
|
Verify
|
After a while (see note) the client internally decides to send another GET request to the server with observe option for resource /obs, using Token t again to confirm the registration
|
|
11
|
Verify
|
Client sends a GET request to the server for resource /obs:- Type = 0 (CON)
- Code = 1 (GET)
- Token value = t, same as one found in the step 2
- Observe option = empty
|
|
12
|
Check
|
Server sends the response containing:- Type = 2 (ACK)
- Code = 2.05 (Content)
- Content-format of the resource /obs, ➔ f
- Token value = t, same as one found in the step 2
- Observe option with a sequence number that is not necessarily increasing
|
|
13
|
Check
|
Server sends a notification containing:- Type = 0 (CON)
- Code = 2.05 (Content)
- Content-format = same as one found in the step 12
- Token value = t, same as one found in the step 2
- Observe option indicating increasing values (sequence number arithmetic modulo 2**24), unless more than 256 seconds elapsed
|
|
14
|
Verify
|
Client displays the received information
|
|
15
|
Check
|
Client sends an ACK
|
Notes:
|
- Steps 4-6 are in a loop.
- Step 7-9 are asynchronous to the loop 4-6.
- Steps 13-15 are in a loop.
- A new registration should be attempted after Max-Age + MAX_LATENCY as recommended by [OBSERVE]. MAX_LATENCY is defined by [COAP] and set to 100 seconds.
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_OBS_05
|
| Objective: |
Server detection of deregistration (client OFF)
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
[OBSERVE] 4.5 item 2 (see also ticket #350)
|
| Pre-test conditions: |
- Client supports Observe option
- Server supports Observe option
- Server offers an observable resource /obs which changes periodically (e.g. every 5s) which produces confirmable notifications
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to send to the server a confirmable GET request with observe option for resource /obs
|
|
2
|
Check
|
The request sent by client contains:- Type = 0 (CON)
- Code = 1 (GET)
- Token value ➔ t, a value generated by the client
- Observe option = empty
|
|
3
|
Check
|
Server sends the response containing:- Type = 2 (ACK)
- Code = 2.05 (Content)
- Content-format of the resource /obs, ➔ f
- Token value = t, same as one found in the step 2
- Observe option with a sequence number
|
|
4
|
Check
|
Server sends a notification containing:- Type = 0 (CON)
- Code = 2.05 (Content)
- Content-format = f, same as one found in the step 3
- Token value = t, same as one found in the step 3
- Observe option indicating increasing values (sequence number arithmetic modulo 2**24), unless more than 256 seconds elapsed
|
|
5
|
Check
|
Client displays the received information
|
|
6
|
Check
|
Client sends an ACK
|
|
Cause a timeout
|
|
7
|
Stimulus
|
Client is switched off
|
|
8
|
Check
|
- Server’s confirmable notifications are not acknowledged
- Server’s retransmissions have an updated Observe option value
|
|
9
|
Verify
|
Server can keep retransmitting the responses for a while, but stops transmitting notifications after a final timeout
|
Notes:
|
- Steps 4-6 are in a loop.
- Step 7-9 are asynchronous to the loop.
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_OBS_06
|
| Objective: |
Server detection of deregistration (explicit RST)
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
[OBSERVE] 4.2 item 2
|
| Pre-test conditions: |
- Client supports Observe option
- Server supports Observe option
- Server offers an observable resource /obs which changes periodically (e.g. every 5s) which produces confirmable notifications
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to send to the server a confirmable GET request with observe option for resource /obs
|
|
2
|
Check
|
The request sent by client contains:- Type = 0 (CON)
- Code = 1 (GET)
- Token value ➔ t, a value generated by the client
- Observe option = empty
|
|
3
|
Check
|
Server sends the response containing:- Type = 2 (ACK)
- Code = 2.05 (Content)
- Content-format of the resource /obs, ➔ f
- Token value = t, same as one found in the step 2
- Observe option with a sequence number
|
|
4
|
Check
|
Server sends a notification containing:- Type = 0 (CON)
- Code = 2.05 (Content)
- Content-format = f, same as one found in the step 3
- Token value = t, same as one found in the step 3
- Observe option indicating increasing values (sequence number arithmetic modulo 2**24), unless more than 256 seconds elapsed
|
|
5
|
Check
|
Client displays the received information
|
|
6
|
Check
|
Client sends an ACK
|
|
Cause an RST
|
|
7
|
Stimulus
|
Client is rebooted
|
|
8
|
Check
|
Server is still sending notifications for the request in step 2 as in step 4
|
|
9
|
Verify
|
Client discards response and does not display information
|
|
10
|
Check
|
Client sends RST to Server
|
|
11
|
Verify
|
Server does not send further response
|
|
12
|
Verify
|
Client does not display further received information
|
Notes:
|
- Steps 4-6 are in a loop.
- Step 7-12 are asynchronous to the loop.
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_OBS_07
|
| Objective: |
Server cleans the observers list on DELETE
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
[OBSERVE] 3.2 §2
|
| Pre-test conditions: |
- Client supports Observe option
- Server supports Observe option
- Server offers an observable resource /obs which changes periodically (e.g. every 5s) which produces confirmable notifications
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to send to the server a confirmable GET request with observe option for resource /obs
|
|
2
|
Check
|
The request sent by client contains:- Type = 0 (CON)
- Code = 1 (GET)
- Token value ➔ t, a value generated by the client
- Observe option = empty
|
|
3
|
Check
|
Server sends the response containing:- Type = 2 (ACK)
- Code = 2.05 (Content)
- Content-format of the resource /obs, ➔ f
- Token value = t, same as one found in the step 2
- Observe option with a sequence number
|
|
4
|
Check
|
Server sends a notification containing:- Type = 0 (CON)
- Code = 2.05 (Content)
- Content-format = f, same as one found in the step 3
- Token value = t, same as one found in the step 3
- Observe option indicating increasing values (sequence number arithmetic modulo 2**24), unless more than 256 seconds elapsed
|
|
5
|
Check
|
Client displays the received information
|
|
6
|
Check
|
Client sends an ACK
|
|
7
|
Stimulus
|
Delete the /obs resource of the server (either locally or by having another CoAP client perform a DELETE request)
|
|
8
|
Check
|
Server sends a notification containing:- Type = 0 (CON)
- Code = 4.04 (Not Found)
- Token value = t, same as one found in the step 2
- No Observe option any more
|
|
9
|
Verify
|
Server does not send further notification
|
|
10
|
Verify
|
Client does not display further received information
|
Notes:
|
- Steps 4-6 are in a loop.
- Step 7-10 are asynchronous to the loop.
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_OBS_08
|
| Objective: |
Server cleans the observers list when observed resource content-format changes
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
[OBSERVE] 4.2 §3
|
| Pre-test conditions: |
- Client supports Observe option
- Server supports Observe option
- Server offers an observable resource /obs which changes periodically (e.g. every 5s) which produces confirmable notifications
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to send to the server a confirmable GET request with observe option for resource /obs
|
|
2
|
Check
|
The request sent by client contains:- Type = 0 (CON)
- Code = 1 (GET)
- Token value ➔ t, a value generated by the client
- Observe option = empty
|
|
3
|
Check
|
Server sends the response containing:- Type = 2 (ACK)
- Code = 2.05 (Content)
- Content-format of the resource /obs, ➔ f
- Token value = t, same as one found in the step 2
- Observe option with a sequence number
|
|
4
|
Check
|
Server sends a notification containing:- Type = 0 (CON)
- Code = 2.05 (Content)
- Content-format = f, same as one found in the step 3
- Token value = t, same as one found in the step 3
- Observe option indicating increasing values (sequence number arithmetic modulo 2**24), unless more than 256 seconds elapsed
|
|
5
|
Check
|
Client displays the received information
|
|
6
|
Check
|
Client sends an ACK
|
|
7
|
Stimulus
|
Update the /obs resource of the server’s resource with a new payload having a different Content-Format (either locally or by having another CoAP client perform a DELETE request)
|
|
8
|
Check
|
Server sends notification containing:- Type = 0 (CON)
- Code = 4.06 (Not Acceptable)
- Token value = t, same as one found in the step 2
- No Observe option any more
|
|
9
|
Verify
|
Server does not send further notifications
|
|
10
|
Verify
|
Client does not display further received information
|
Notes:
|
- Steps 4-6 are in a loop.
- Step 7-10 are asynchronous to the loop.
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_OBS_09
|
| Objective: |
Update of the observed resource
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
[OBSERVE] 4.2 §3
|
| Pre-test conditions: |
- Client supports Observe option
- Server supports Observe option
- Server offers an observable resource /obs which changes periodically (e.g. every 5s) which produces confirmable notifications
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to send to the server a confirmable GET request with observe option for resource /obs
|
|
2
|
Check
|
The request sent by client contains:- Type = 0 (CON)
- Code = 1 (GET)
- Token value ➔ t, a value generated by the client
- Observe option = empty
|
|
3
|
Check
|
Server sends the response containing:- Type = 2 (ACK)
- Code = 2.05 (Content)
- Content-format of the resource /obs, ➔ f
- Token value = t, same as one found in the step 2
- Observe option with a sequence number
|
|
4
|
Check
|
Server sends a notification containing:- Type = 0 (CON)
- Code = 2.05 (Content)
- Content-format = f, same as one found in the step 3
- Token value = t, same as one found in the step 3
- Observe option indicating increasing values (sequence number arithmetic modulo 2**24), unless more than 256 seconds elapsed
|
|
5
|
Check
|
Client displays the received information
|
|
6
|
Check
|
Client sends an ACK
|
|
7
|
Stimulus
|
Update the /obs resource of the server’s resource with a new payload having the same Content-Format (either locally or by having another CoAP client perform a PUT request)
|
|
8
|
Check
|
Server notifications contains:- Type = 0 (CON)
- Code = 2.05 (Content)
- Content-format = f, same as one found in the step 3
- Token value = t, same as one found in the step 2
- Observe option indicating increasing values (sequence number arithmetic modulo 2**24), unless more than 256 seconds elapsed
- Payload = the new value sent at step 7
|
|
9
|
Verify
|
Client displays the new value of /obs sent in step 8
|
|
10
|
Check
|
Client sends an ACK
|
Notes:
|
- Steps 4-6 are in a loop.
- Step 7-9 are asynchronous to the loop 4-6.
- Steps 8-10 are in a loop (the same loop at steps 4-6 but /obs is updated).
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_OBS_10
|
| Objective: |
GET does not cancel resource observation
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
[OBSERVE] 1.2, 3, 4
|
| Pre-test conditions: |
- Client supports Observe option
- Server supports Observe option
- Server offers an observable resource /obs which changes periodically (e.g. every 5s) which produces confirmable notifications
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to send to the server a confirmable GET request with observe option for resource /obs
|
|
2
|
Check
|
The request sent by client contains:- Type = 0 (CON)
- Code = 1 (GET)
- Token value ➔ t, a value generated by the client
- Observe option = empty
|
|
3
|
Check
|
Server sends the response containing:- Type = 2 (ACK)
- Code = 2.05 (Content)
- Content-format of the resource /obs, ➔ f
- Token value = t, same as one found in the step 2
- Observe option with a sequence number
|
|
After some time elapses, repeatedly:
|
|
4
|
Check
|
Server sends a notification containing:- Type = 0 (CON)
- Code = 2.05 (Content)
- Content-format = f, same as one found in the step 3
- Token value = t, same as one found in the step 3
- Observe option indicating increasing values (sequence number arithmetic modulo 2**24), unless more than 256 seconds elapsed
|
|
5
|
Check
|
Client sends an ACK
|
|
6
|
Verify
|
Client displays the received information
|
|
Perform an unrelated GET
|
|
7
|
Stimulus
|
Client is requested to send to the server a confirmable GET request *without* observe option for resource /obs
|
|
8
|
Check
|
The request sent by client contains:- Type = 0 (CON)
- Code = 1 (GET)
- Token value ➔ t2, a value generated by the client ≠ t
- *No* Observe option
|
|
9
|
Check
|
Server sends the response containing:- Type = 2 (ACK)
- Code = 2.05 (Content)
- Content-format of the resource /obs, = f
- Token value = t2, same as one found in the step 8
- *No* Observe option
|
|
After some time elapses, the notifications still arrive:
|
|
10
|
Check
|
Server sends a notification containing:- Type = 0 (CON)
- Code = 2.05 (Content)
- Content-format = f, same as one found in the step 3
- Token value = t, same as one found in the step 3
- Observe option indicating increasing values (sequence number arithmetic modulo 2**24), unless more than 256 seconds elapsed
|
|
11
|
Check
|
Client sends an ACK
|
|
12
|
Verify
|
Client displays the received information
|
Notes:
|
Steps 4-6 and 10-12 are in a loop.
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_OBS_11
|
| Objective: |
Handle resource observation with CON messages (lossy case)
|
| Configuration: |
CoAP_CFG_LOSSY
|
| References: |
[OBSERVE] 1.2, 3, 4
|
| Pre-test conditions: |
- Client supports Observe option
- Server supports Observe option
- Server offers an observable resource /obs which changes periodically (e.g. every 5s) which produces confirmable notifications
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to send to the server a confirmable GET request with observe option for resource /obs
|
|
2
|
Check
|
The request sent by client contains:- Type = 0 (CON)
- Code = 1 (GET)
- Token value ➔ t, a value generated by the client
- Observe option = empty
|
|
3
|
Check
|
Server sends the response containing:- Type = 2 (ACK)
- Code = 2.05 (Content)
- Content-format of the resource /obs, ➔ f
- Token value = t, same as one found in the step 2
- Observe option with a sequence number
|
|
After some time elapses, repeatedly:
|
|
4
|
Check
|
Server sends a notification containing:- Type = 0 (CON)
- Code = 2.05 (Content)
- Content-format = f, same as one found in the step 3
- Token value = t, same as one found in the step 3
- Observe option indicating increasing values (sequence number arithmetic modulo 2**24), unless more than 256 seconds elapsed
|
|
5
|
Check
|
Client sends an ACK
|
|
6
|
Verify
|
Client displays the received information
|
|
7
|
Check
|
Check that, even if the delivery of notifications takes some time due to retransmissions, there are never multiple notifications active at one time.
|
Notes:
|
Steps 4-6 are in a loop.
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_OBS_12
|
| Objective: |
GET with Observe=1 does cancel resource observation
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
- [OBSERVE] 1.2, 3, 4
- IETF 89 WG decision on observation cancellation
|
| Pre-test conditions: |
- Client supports Observe option
- Server supports Observe option
- Server offers an observable resource /obs which changes periodically (e.g. every 5s) which produces confirmable notifications
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to send to the server a confirmable GET request with observe option for resource /obs
|
|
2
|
Check
|
The request sent by client contains:- Type = 0 (CON)
- Code = 1 (GET)
- Token value ➔ t, a value generated by the client
- Observe option = empty
|
|
3
|
Check
|
Server sends the response containing:- Type = 2 (ACK)
- Code = 2.05 (Content)
- Content-format of the resource /obs, ➔ f
- Token value = t, same as one found in the step 2
- Observe option with a sequence number
|
|
After some time elapses, repeatedly:
|
|
4
|
Check
|
Server sends a notification containing:- Type = 0 (CON)
- Code = 2.05 (Content)
- Content-format = f, same as one found in the step 3
- Token value = t, same as one found in the step 3
- Observe option indicating increasing values (sequence number arithmetic modulo 2**24), unless more than 256 seconds elapsed
|
|
5
|
Check
|
Client sends an ACK
|
|
6
|
Verify
|
Client displays the received information
|
|
Perform canceling GET
|
|
7
|
Stimulus
|
Client is requested to send to the server a confirmable GET request with observe option = 1 and token = 1 for resource /obs
|
|
8
|
Check
|
The request sent by client contains:- Type = 0 (CON)
- Code = 1 (GET)
- Token value t
- Observe option = 1
|
|
9
|
Check
|
Server sends the response containing:- Type = 2 (ACK)
- Code = 2.05 (Content)
- Content-format of the resource /obs, = f
- Token value = t, same as one found in the step 8
- *No* Observe option
|
|
After some time elapses, no further notifications arrive.
|
|
10
|
Verify
|
Server does not send further notifications
|
|
11
|
Verify
|
Client does not display further received information
|
Notes:
|
Steps 4-6 are in a loop.
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_OBS_13
|
| Objective: |
Handle observation of large resources (with Block2)
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
- [OBSERVE] 1.2, 3, 4
- [BLOCK] 2.6
|
| Pre-test conditions: |
- Client supports Observe and Block2 options
- Server supports Observe and Block2 options
- Server offers an observable resource /obs-large which changes periodically (e.g. every 5s) which produces confirmable notifications
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to send to the server a confirmable GET request with observe option for resource /obs-large
|
|
2
|
Check
|
The request sent by client contains:- Type = 0 (CON)
- Code = 1 (GET)
- Token value ➔ t, a value generated by the client
- Observe option = empty
|
|
3
|
Check
|
Server sends the response containing:- Type = 2 (ACK)
- Code = 2.05 (Content)
- Content-format of the resource /obs, ➔ f
- Token value = t, same as one found in the step 2
- Observe option with a sequence number
- Block2 option with
- NUM = 0;
- M = 1;
- SZX (➔DES_SZX) is the desired block size.
- Payload size is 2**(SZX+4) bytes.
|
|
4
|
Check
|
Client obtains the rest of the resource representation (cf. TD_COAP_BLOCK_02)
|
|
After some time elapses, repeatedly:
|
|
5
|
Check
|
Server sends a notification containing:- Type = 0 (CON)
- Code = 2.05 (Content)
- Content-format = f, same as one found in the step 3
- Token value = t, same as one found in the step 3
- Observe option indicating increasing values (sequence number arithmetic modulo 2**24), unless more than 256 seconds elapsed
- Block2 option with
- NUM = 0;
- M = 1;
- SZX (➔DES_SZX) is the desired block size.
- Payload size is 2**(SZX+4) bytes.
|
|
6
|
Check
|
Client sends an ACK
|
|
7
|
Check
|
Client obtains the rest of the resource representation (cf. TD_COAP_BLOCK_02)
|
|
8
|
Verify
|
Client displays the received information
|
Notes:
|
Steps 5-8 are in a loop.
|
| Interoperability Test Description |
| Identifier: |
TD_COAP_OBS_14
|
| Objective: |
Handle observation of variable size large resources (with Block2)
|
| Configuration: |
CoAP_CFG_BASIC
|
| References: |
- [OBSERVE] 1.2, 3, 4
- [BLOCK] 2.6
|
| Pre-test conditions: |
- Client supports Observe and Block2 options
- Server supports Observe and Block2 options
- Server offers an observable resource /obs-pumping which changes periodically (e.g. every 5s), with varying sizes some of which require a Block2 option and others that do not, which produces confirmable notifications
|
| Test Sequence: |
Step |
Type |
Description |
|
1
|
Stimulus
|
Client is requested to send to the server a confirmable GET request with observe option for resource /obs-pumping
|
|
2
|
Check
|
The request sent by client contains:- Type = 0 (CON)
- Code = 1 (GET)
- Token value ➔ t, a value generated by the client
- Observe option = empty
|
|
3
|
Check
|
Server sends the response containing:- Type = 2 (ACK)
- Code = 2.05 (Content)
- Content-format of the resource /obs, ➔ f
- Token value = t, same as one found in the step 2
- Observe option with a sequence number
- Potentially, a Block2 option with
- NUM = 0;
- M = 1;
- SZX (➔DES_SZX) is the desired block size.
- If there was a Block2 option, Payload size is 2**(SZX+4) bytes.
|
|
4
|
Check
|
If there was a Block2 option, the client obtains the rest of the resource representation (cf. TD_COAP_BLOCK_02)
|
|
After some time elapses, repeatedly:
|
|
5
|
Check
|
Server sends a notification containing:- Type = 0 (CON)
- Code = 2.05 (Content)
- Content-format = f, same as one found in the step 3
- Token value = t, same as one found in the step 3
- Observe option indicating increasing values (sequence number arithmetic modulo 2**24), unless more than 256 seconds elapsed
- Potentially, a Block2 option with
- NUM = 0;
- M = 1;
- SZX (➔DES_SZX) is the desired block size.
- If there was a Block2 option, Payload size is 2**(SZX+4) bytes.
|
|
6
|
Check
|
Client sends an ACK
|
|
7
|
Check
|
If there was a Block2 option, the client obtains the rest of the resource representation (cf. TD_COAP_BLOCK_02)
|
|
8
|
Verify
|
Client displays the received information
|
Notes:
|
- Steps 5-8 are in a loop.
- continue observing until both the Block2 and the single-payload case (no blockwise transfer) have been observed.
- repeat test until the response to the initial request also has been observed both in Block2 and in single-payload form.
|