The basic principle of HSDPA is time multiplexing (packet scheduling) of multiple flows on a single shared

channel. At any time (in each 2 ms TTI), a single flow is served. The served flow's transport block size
(TBS; ~ instantaneous bit rate) depends on several things, amongst others on its current radio link
quality. The selected TBS will be achieved by combining a chosen modulation scheme (QPSK, 16QAM,
64QAM), coding rate and number of SF16 codes used in parallel. Hence a given user may potentially be
served in a given TTI with all available HSDPA tx power but only use e.g. 2 SF16 codes (out of possibly
more available SF 16 codes), simply because its radio link quality is too poor. Or, if his channel is really
strong, and the codes are not used by R99 calls, it could be served with 15 codes in parallel. The point is
to illustrate that HSDPA's key principle is one-by-one scheduling, where (only) the scheduled flow in
each TTI is assigned one or more SF16 codes. Hence many more HSDPA flows can share the channel
than there are SF16 codes available. There is no direct relation.
Aside from HSDPA key principle of one-by-one scheduling, which generally maximizes multi-user
diversity, code multiplexing is also possible. for instance, if the scheduled flow's buffer currently
contains too few bits to fully utilize the available channel resources, one or more additional flows can be
scheduled in parallel (using a different set of SF16 codes from the same pool) in order to optimize
resource utilization and service quality. The number of code multiplexed flows is limited to the number
of HS-SCCHs that are maintained in parallel. I believe up to four is possible (and should typically suffice).