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.