what does "Link ID" really mean?

The Link ID is similar to a pointer in C.  It is used to reference an existing connection created with the Link/LinkListen function pair between two radios.  The nwk layer uses it to locate the appropriate connInfo_t structure which holds the local and remote port numbers and addresses associated with the link.  This information is held in the sPersistInfo object defined in nwk.c.

Jim Noxon

Thanks a lot for your explaination. I went over the code this afternoon too.

A couple things that i do not understand

1) Rx callback function is in a ISR context: I saw it is declared as regular c function. How the complier knows it should be the ISR context.

2) whats the benefit of the callback function? Cant we use the ISR directly to set the semaphore?

3) Can someone give a rough idea of the NWK layer design? I searched online and there is not too much about the thinking behind this layer's protocal.

4) whats the difference between linkport and replyport in sPersistInfo?

The Rx callback function is merely a function which is called from the ISR if it exists thus it is in ISR context due to point at which it is called.

The purpose of the callback function is to provide you a hook to manage packets directly in the ISR.  Generally it is used to detect if the packet is needed for further processing and also to set a semaphore for your application layer code.  Doing this can eliminate the need to call Receive in the application layer which is somewhat slower as it must look through the entire queue of messages to determine if one is available for the link ID requested.  Another option is to allow you to get involved in filtering nwk layer packets as the call back function is called for all packets received not just those directed to user ports.  This can allow you greater control in management of the network on whole.  The code in the callback function should be kept to a minimum and defer any significant processing to the baseline code.

The network layer is relatively simple.  The API calls manage the mapping of link ID's to physical addresses and ports thus abstracting communications after the link process.  If an access point is involved, it can be used as a hub for directing communications traffic (in this case all links are to the access point) and if there are sleeping nodes the access point can manage storing and forwarding messages between end devices.  In general, all access points and range extenders also provide repeater operation to allow the network to be physically larger than a single radio link can provide.  See the documentation in the documentation folder of your installed SimpliciTI package.

The linkport and replyport objects represent the ports used by the connection setup during the link process.  Note that the port assigned is not necessarily the same number on either end of the link thus the nwk layer must maintain knowledge of which (local) port incoming packets are to be directed and the (remote) port outgoing packets are to be sent to.

Jim Noxon

I need to make a correction to my previous answer.

the call back function is not called unconditionally, it is only called if it has been installed during the call to smpl_Init() and only for packets destined for user ports (i.e. ports numbered higher than 0x1F).

Jim Noxon

The call back function is merely a hook for you to gain access to incoming packets real time, i.e. within the ISR context.

For example, assume your system works with several kinds of packets.  One of these packets may be a high priority packet such as an "Abort Operation" command or such.
  Using the call back function allows you to effectively manage the order in which packets are operated on.  Either immediately or deferred via the normal input queue.

In the range extender, the nwk ports are all operated on in the ISR context so any packet received is re-transmitted automatically in the ISR context.  Therefore there is no application layer code to implement beyond making sure the processor doesn't exit the main function, thus the while(1) infinite loop.

CSMA (Carrier Sense Multiple Access) is implemented via what we term CCA (Clear Channel Assessment) algorithms.  They are similar except that CSMA is a defined carrier access protocol and CCA is merely implementing the test portion of that protocol.  To answer your question of is it CSMA based, effectively yes as the CCA algorithm is applied for re-transmitted packets.

Jim Noxon

SMPL_LinkListen is paired with SMPL_Link as the two functions work in concert with each other on separate ends of a connection being established.  The purpose of these functions is purely to establish the connection and nothing more.  Note that part of establishing the connection is to allocate resources on both ends of the connection so the nwk layer can manage the connection and messages passed through it.

SMPL_Receive is the function which is used to retrieve frames in the input queue (that were placed there from the receive ISR).  Only messages destined for user applications (those links with a port greater than 0x1F).

The procedure is basically as follows for any user packets received...

1. Receive ISR is activated
2. Packet is retrieved from radio and basic tests are done to validate it is a recognizable SimpliciTI packet and that it is destined for a user application
3. An entry in the receive queue is allocated and the packet is copied to it allowing the radio to receive another message
4. The ISR is exited
5. Time passes...
6. The user requests the received packet via a call to SMPL_Receive
7. If a packet for the link ID passed exists, it is located and copied to the data buffer provided by the user in the call to SMPL_Receive
8. The structure in the receive queue where the packet was being held is released
9. Return from SMPL_Receive

The key to understand is the SMPL_LinkListen and SMPL_Link functions establish the connection and provide a viable handle to the connection in the form of the Link ID.  The Link ID is used to both send and receive messages on the connection it references thus sending and receiving cannot be done until a link is established (except of course for broadcast frames via the UUD Link ID).

The UUD Link ID is effectively a multiple access Link ID which is created during the call to SMPL_Init and is always available without needing to create the link aprori.

Jim Noxon

Can it (?network port) be possible that it transmitted during the Contention free period in the beacon-based system?

If the queue in the network layer has no knowledge of the linkID, but SMPL_receive is looking at the linkID and then get appropriate packket from that buffer. How SMPL_receive can make sure the element in the queue is the related with the linkID? Is there an attribute in the element that is pointing to the linkID?

Also whats the purpose of the nwk layer application?

Also where can I find the really ISR function? I assume that ISR function calls callback in it.

See in the AP example, callback as below. How sCB gets the lid? who is generating the valid lid on the AP? If we linked, how AP identify the subsequent packet are under that linkID given the packet has no info about the linkID?

static uint8_t sCB(linkID_t lid)
{
  if (lid)
  {
    sPeerFrameSem++;
    sBlinky = 0;
  }
  else
  {
    sJoinSem++;
  }

  /* leave frame to be read by application. */
  return 0;
}

The Link ID is associated with an address and port number on this and the remote radio and this association is stored in an array inside a structure.  The structure is declared in nwk.c as

static persistentContext_t sPersistInfo = {CONNTABLEINFO_STRUCTURE_VERSION};

The array inside this structure which which manages the association is declared as

connInfo_t connStruct[SYS_NUM_CONNECTIONS];

The conninfo_t type holds elements of the peer radio address, the local and remote ports to communicate on and some other stuff as well to help manage the link.

When a message is received, the address and port are used to search through the connStruct array to determine the Link ID to associate it with.  When a message is transmitted the search is done with the Link ID to obtain the peer radio address and remote port to send the message to.

The purpose of the nwk layer application is to support the above described operations.  Think of it as the connections manager.

The ISR function which is triggered when a message is received is in the mrfi_radio.c file.

The place where the call back function is called is in the dispatchFrame function located in the nwk_frame.c file.  By the time this function has been entered, the association between the received message and the Link ID it belongs to has already been made allowing the call back function to be called with the destination Link ID passed as the parameter.

Jim Noxon

Thanks a lot. I was reading the smpl_linklisten and got a few questions. The first thing in the function is to set the context, which a semaphore to signal if it is in listen mode or not.

1) whats the purpose of this context? And how the radio can use it to make sure it is only listening?  are linklisten and link only put the linkID into the persistent table and do nothing more?

2)  if it is a link packet, are the radio still put it in the nwk receive or trans buffer? or they just discard it and only put the data into those buffers?

3) how does the radio know the packet is for link listen purose? the simplicityTI overview has a packet breakdown but there is no field to signal that it is for link listen purpose or regular data purpse.

Thank again for the informative answers.

So the port related with link is less than 31? So the stack can only handle (31-x) link port? see for example, if nwk has 5 app ports, so it can only assign link port of 26?

Also the link port and address information is not in persistent table, right?

Or is all the link transactions across all units are through one link port. After link is done, the linkID is assgned and a new port