Ah...frames. I've been avoiding frames for about 6 years, mostly because of this problem. I don't know how current browsers handle the issue, but in the IE4/Netscape4 days, one of them would list the HTTP_REFERER for a frame as the frameset page. The other one would list it as the page that referred to the frameset page.

This made it particularly difficult to get accurate site statistics, and to perform simple tests to see if someone had tried bypassing the frameset page, and to force a reload. In one of the browsers (I think it was IE), this would result in the frameset being redirected to the frameset, and a nasty loop starting. (Even when playing with it in JavaScript, setting it to override the top content, so it'd break out of other frames, I ended up never ending cycles.)

The main reason for frames, originally, was the reduction of bandwidth required for a site. It also helped with reducing the amount of repetitive HTML needed in pages, which should have saved authoring time, but the many flaws in its implementation have reduced any significant savings. These days, you'll probably spend your time better by using SS, templates, CGI, or text-preprocessors to generate the pages to reduce authoring time, and CSS in a shared file to reduce the size of the formatting of frames.

Due to the limitations with frames, I would probably only use them these days if I knew I could control which browsers and users were accessing the site. (which leaves us with administration-only pages, and/or intranet sites).

Now that I've bitched about frames -- solving your problem. I know of only four ways --

passing the info in PATH_INFO or QUERY_STRING, (where the frameset can insert it)

problem: anyone else can set it, too, or link directly to the page, so depending on your reasoning for needing it, it's probably useless.

time-sensitive URLs. (have the frameset add a timestamp in PATH_INFO or QUERY_STRING)

I've never tried it, so I don't know how it might affect bookmarks, or people revisiting the page after the timeout. And of course, someone could reverse engineer the timestamp.

Either of the two above, but use cookies.

Lack of support for people rejecting cookies. Some organizations have policies forbidding their use.

Establishing and tracking individual sessions for each user.

Higher overhead

You'd have to decide for yourself if the advantages of frames outweigh the problems.