Skip to main content

Application Information CableCARD resource

9 replies [Last post]
tgwozdz
Offline
Joined: 2009-06-23

I'm looking at the mpeos pod API, and I found a function called mpeos_podGetAppInfo which is supposed to return the information provided by the Application Information resource of the CableCARD. However, the APDU to request this resource also notifies the CableCARD of various capabilities of the host platform, such as whether scrolling is supported and the HTML profile supported. Is there a way to tell the mpeos layer what capabilities it should be reporting? It seems to me that the capabilities should be the job of the higher layers, and not the mpeos layer to determine.
Similarly, looking at EchoStar's contribution of the MMI interface, I can't seem to find where they ever send this APDU. Also, I can't seem to find how they acquire the Application Information resource. They seem to use it by sending server_query messages to the CableCARD. Did I just miss the place where they acquired the resource? Or maybe its not necessary to do?
Can someone clarify for me?
Thanks!

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
greg80303
Offline
Joined: 2008-07-03

I think we've definitely identified some holes in the OCAP spec and in the stack's MPEOS APIs with regard to host display capabilities. The stack now has a resident MMI handler (thanks to the Echostar contribution) and it seems that each handler could have its own display capabilities. So the stack would send an application_info_req() APDU at startup that conveys the display capabilities of the resident MMI handler. However, an OCAP application can register its own MMI handler to take the place of the resident handler. In this case, the application would need to send its capabilities to the card.
There are some questions about whether or not CableCARDs can accept multiple application_info_req() APDUs. We are beginning to sort this out at CableLabs and will keep the community advised of our progress and any spec changes that come out of the process.
G

tgwozdz
Offline
Joined: 2009-06-23

I have another related question. I'm confused by the existence of the mpeos_podMMIConnect function. The CCIF spec says that it will be the CableCARD that initiates the MMI session with the host. If that's the case, why do we have a Connect() function in the Host? What is this indented to do?
My understanding is that the host is to provide the resource, and the CableCARD then connects to the resource. Could you clarify if this is how this is intended to work? If that's the case, should we be eliminating the mpeos_podMMIConnect function?

tgwozdz
Offline
Joined: 2009-06-23

Hi Greg,
Looking at the CCIF spec, it seems to indicate that the application_info_req() APDU should be sent right after the CableCARD sets up the Application Information session with the Host. I'm assuming this happens below the MPEOS interface, is that right? Does that mean that it is the MPEOS implementation's responsibility to send the application_info_req() APDU to the CableCARD?
Also, looking at the SystemModule.sendAPDU API, it states that it will use the SessionID of the appropriate resource used, based on the APDU tag. That is, whether to use the MMI SessionID or the Application Info SessionID. Currently, the EchoStar contribution always uses the MMI SessionID. However, I wonder if this is the wrong layer to be doing this determination anyway. Before EchoStar's changes, the MMI SessionID wasn't being passed up to the MPE layer at all. The Application Info SessionID isn't being passed up currently either. Would it make more sense for this determination to be handled below the MPEOS layer instead, since it is the one who assigned the SessionIDs to the CableCARD in the first place? It looks like the cablecard.c in the RI_Platform is doing something along these lines already.
Finally, I've discovered one more issue. Currently the MMI handler is the only one sending server_query() APDUs to the CableCARD, and it is the only one receiving replies. However, another module may wish to download the CableCARD Application Info URLs for diagnostics purposes. It may be possible to hook into the current implementation and send a server_query() request through a private API, and then have the response for that transaction routed to this new module. But a problem occurs if there's an OCAP-J MMI handler registered. If the OCAP-J handler sends a server_query() with a specific transaction ID, its possible that this new module will also send a request with the same transaction ID, since the two modules are independent of each other, and have no way of coordinating transaction IDs. In this case, both modules can become confused with the replies (or confuse the CableCARD instead).
To solve this issue, it may be necessary to inspect any APDUs being sent by an OCAP-J handler, strip out the transaction ID and replace it with a unique one from an internal state, then do the reverse with the reply. This seems like a headache to me. A much simpler solution would be to simply remove the functionality that allows OCAP-J applications from registering MMI handlers :). Is that an option we can consider? If not, it may be necessary to extend the API so that OCAP-J handlers either query some source for a new transaction ID, or to give them a method to use to generate the request message (rather than relying on them to generate the actual APDU bytes themselves). What do you think?
Thanks!
Tom

greg80303
Offline
Joined: 2008-07-03

OK -- I've dug into this a little bit more. I think the spec might be OK as is, but the MPEOS APIs need some work.
1) Single-session resource management.
As you indicated, there is only one session opened to both of these resources for the life of the boot cycle. Regardless of who opens the session (CARD or HOST), I think we should assume that this connection is made upon (or before) mpeos_podInit(). The stack only has one MPEOS API for sending APDUs. This API is shared amongst all the stack modules that can access CARD resources (SAS, MMI, AI, CA). When an APDU is sent, the only way the platform can know where to direct the APDU is via the "sessionID" parameter. It is my opinion, that for "single-session" resources (MMI, AI, CA), the mpeos_PodDatabase should hold these single-session session IDs for use by the upper layers of the stack. The platform can populate these session IDs in the implementation of mpeos_podInit() and the upper stack layers will know what resource they intend to use and pull the appropriate sessionID from the PodDatabase when sending APDUs. The mpeos_podCASConnect() and mpeos_podMMIConnect() should be deleted. We will do a quick internal review of these proposed MPEOS API changes to make sure we have team approval.
2) Host display capabilities
The registered MMI handlers (either resident or OCAP-J application-based) must be able to communicate their display capabilities to the CARD via the application_info_req() APDU. It seem that the EchoStar-contributed resident MMI handler does not perform this communication and we must look into adding this functionality. You should create an IssueTracker issue for this. Obviously, they could not have provided this functionality due to the problems described in 1) (i.e. no access to AI session ID). It is clearly communicated in the SystemModule and SystemModuleRegistrar OCAP APIs, that a registered MMI handler assumes control over BOTH the MMI and AI sessions. The OCAP-J handler is free to send all APDUs described in the CCIF spec (including application_info_req() and server_query()).
3) Interaction between resident and OCAP-J MMI handlers
Once an OCAP application registers its own MMI handler via the SystemModuleRegistrar.registerMMIHandler() API, it assumes total control over both the MMI and AI resources. The resident handler should no longer send or receive any APDUs to/from these resources. If you think the current implementation is not doing this, please create a bug in IssueTracker.
4) application_info_req() APDU
One of the set-top vendors seems to think that CableCARDs do not like to receive the application_info_req() APDU more than once. We do not believe that the CCIF spec prohibits the sending of multiple instances of this APDU. This allows an OCAP-J application to send this APDU when it registers its MMI handler to communicate its own display capabilities.

tgwozdz
Offline
Joined: 2009-06-23

Thanks Greg, that sounds good, but I still have one more question about your point 3.
I agree that once an OCAP-J handler is registered, it completely takes over anything that the resident handler was doing. However, what if the stack also had some other internal application running, say for providing diagnostics info. This app would need to be able to get diagnostics info from the CableCARD, which it does by sending server_query requests through the AI resource to the CableCARD, to get the HTML pages associated with each application.
So in this case, if the OCAP-J handler is registered, and owns the MMI and AI resources, would this new app be prohibited from doing these AI requests? Or should there be some way of allowing sharing of the resource between these two applications?
Thanks for your help!
Tom

greg80303
Offline
Joined: 2008-07-03

My interpretation is that I don't really think the spec allows this "sharing" that you speak of. If the OCAP-J application replaces the resident MMI handler, it must also handle the display of diagnostics URLs from the CableCARD. What do you think?
G

greg80303
Offline
Joined: 2008-07-03

I have been looking into this a bit. We received some information from Echostar about their contribution in this area. They indicate that there may be some issues with the OCAP/CCIF specifications that could use clarification. Specifically, most CableCARDs expect the application_info_req APDU to be sent only once by the host. This means that only one set of MMI display capabilities are sent to the card. However, since OCAP allows applications to register their own MMI handlers to supplant the resident handler, could the new handler have different display capabilities from the resident handler?
I'm back in the office tomorrow. Steve and I will discuss this a little more and post our comments here.
G

khendry
Offline
Joined: 2004-08-13

We still haven't seen that promised update from CableLabs as far as I can tell. We are eagerly awaiting a response of some sort.

smaynard
Offline
Joined: 2009-01-27

I will discuss internally with Greg et. al. and respond. Greg is currently out of the office so the response may not occur until Monday 12/06